Notizen zum Scrumtisch am 31.8.

2 August 2008 mhaecker

Ich habe beim letzten Scrumtisch einfach immer etwas mitgeschrieben was mich interessiert hat. Hauptsächlich Stichworte und Zitate. Natürlich bin ich gespannt auf Feedback - schließlich ist das nur was ich davon mitgenommen habe.

By

mhaecker

On

2 August 2008

In

Rate

• Follow us on Twitter
• Our Facebook page
• Agilo Google Group
• Blog RSS Feed

Ich habe beim letzten Scrumtisch einfach immer etwas mitgeschrieben was mich interessiert hat. Hauptsächlich Stichworte und Zitate. Natürlich bin ich gespannt auf Feedback - schließlich ist das nur was ich davon mitgenommen habe.

• Controlling von Scrum-Projekten
  • Featureheft / Pflichtenheft
    • Bisher hatten wir einen Prozess mit Anträgen um Änderungen zu minimieren.
    • Jetzt gibt es so viele Änderungen
  • "Der Erfolg gibt ihm Recht"
    • Bisher sieht es gut aus
  • Geschäftsführung spricht dauernd dazwischen
    • Nein, war doch der Product-Owner
  • Zerlegung in kleine Plan-Teile lässt sehen wo man falsch geplant hat und erlaubt korrekturen
    • Aber man verliert leicht den Überblick über das Projektziel
    • Problem Kontrollverlust
  • Produktives Team messen
  • Aber mehr release planung machen
    • Generelle Planung für große Subsysteme
    • Dann pro Sprint genauere Planung
    • Velocity messen und dann abschätzen wie es aussieht
  • Kontrollverlust: "Ich habe das Projekt nicht mehr in der hand, muss aber trotzdem den Fortschritt verantworten".
  • Veränderung der Institutionslandschaft
  • Es hat die Verabredung gefehlt was man zurückmeldet
  • Also wieder: Wie implementiert man es
    • Eine Stelle anfangen, dann von da aus sternförmig ausbreiten
  • Prioritäten kommen vom Vertrieb: Und einer muss es dann den Anderen beibringen (die auch dachten dass sie eigentlich das sagen haben - schließlich wurden sie ja auch gefragt -> Konflikt)
    • Eine Lösung: Business Value Game spielen
      • New Features: Bringt es Kunden
      • Retainement: Hält es Kunden
      • Upselling: Können wir es an bestehende Kunden verkaufen
      • Efficiently: Spart es?
    • Dadurch gibt's weniger ad-hoc Planung
      • Wenn man doch was machen will, dann muss man mit den anderen Sprechen
  • Frage nach: Wo steh ich? Muss man anders stellen. Nicht im vergleich zum Plan, sondern wie viele Features hab ich schon
• Interne gegen externe Requirements
  • "Es gibt immer eine Kundenanforderung die wichtiger ist!"
  • Wir entwickeln unsere eigenen Werkzeuge, die wir mit dem anderen zusammen Planen
  • Vor dem Release ist jede kleine Feature-Wunsch des Kunden das wichtigste
  • Hilfreich: Für Vergleiche die gleiche Skala wählen: Kundenfeature == Geld, Operational Efficiency == Geld
    • Wir hängen Geld an jedes Feature. Mit 3-10 Kundengruppen bewerten wir wie viel es ihnen wert ist. 50 cent, 50 euro, kauf ich das Produkt deswegen.
    • Jedes team hat einen Stundenpreis, daran wird gemessen wie viel etwas Spart
    • Aber wir müssen maintenance Einsparung schätzen
      • Vergleichen mit anderen Projekten -> Historisch schätzen
  • Das Team muss sagen was sie machen müssen, damit sie verantwortlich sein können für ihr comitment
    • Was das Team sagt das es an Refactoring machen muss zieht man dann direkt von der vorhandenen Zeit ab
    • Aber wenn das Team dann Qualität um der Qualitäts Willen macht?
      • Dann vermindert sich die Velocity und man muss das Problem offen klären. (Das ist aber selten)
  • Wir haben das Problem, dass wir unsere Refactorins schlechter vorbereiten können [als normale Feature Requests], weil wir sie immer am Ende des Sprints vorbereiten müssen -> da haben wir aber immer wenig Zeit.
    • Erstens: Man muss dem Team vertrauen
      • Aber man kann den Business-Value den man pro Sprint erhält bewerten
      • Wenn Bugs reinkommen muss man sie trotzdem fixen: 22% jeden Sprint dafür zurück
        • Wenn man die Qualität steigern kann, dass es nur noch 10% kostet -> dann lohnt es sich
      • Das Produkt ist ein Team-Baby -> sonst kriegt man kein echtes Comittment
      • "Wie würde sich jemand wie wir entscheiden?" als Entscheidungsgrundlage vs. "Was hätte ich am liebsten".
  • Wir sind neun Leite in drei teams (oder doch drei teams a 10 leute?)
    • Wieso behandelt ihr das nicht als ein Team, das gemeinsam plant?
    • Wir wollen die aber schon getrennt betrachten?
      • Wenn ein team schneller ist als ein anderes, und nicht klar ist wer was macht, kann man nicht planen.
    • Mit drei Repräsentaten aus neun machen wir gute Schätzungen
    • Schätzung etc kann schnell gehen: Alle features in 4 Stunden
  • Bei uns werfen immer wieder leute die extremkarten [beim Business Value Game], damit sie sich reden hören können
    • Vielleicht doch jemanden benennen?
  • Am Anfang dachten wir: Toll, wir können jeden Sprint die Kapazitäten zwischen den Teams shiften. Das war eine schlechte Idee
  • Also: Jedes Team muss zu seiner eigenen Velocity antworten geben
    • Wir behandeln die Velocity als faktor, der aus den "Feature-Points" eine Zeitabschätzung macht
  • Jeder Entwickler bei uns darf in alle technischen komponenten reingreifen
    • Funktionale Bereiche sind ungleich technischen Bereiche, "Funktionale Bereiche gehen typischerweise durch den ganzen Stack"
  • Jeder sagt: Das kann ich, das kann ich so schnell machen
    • Wenn man sagt: Das macht ihr, dann können die leute nicht wählen -> kein Comittment
    • Die Prioritäten geben die top 10 her, die werden dann bearbeitet - aber wer was macht wählt er selber.
    • Die Stories sind schon Priorisiert, aber die Teams müssen trotzdem wählen was sie machen wollen
    • Es ist mehr Verantwortung beim Product-Owner

• Share this:
• Digg
• StumbleUpon
• Facebook
• BuzzUp!
• LinkedIn