Mike sieht es kritisch, dass in einigen Veröffentlichungen der Eindruck erweckt wird, als ob agile Methoden nur für ein einzelnes kleines Team auf einer einsamen Insel funktionieren würden. Die Beschränkung auf die Beschreibung der Kernkonzepte sei zwar ein guter Ansatz, um die Grundlagen/Konzept zu erklären. Die Wirklichkeit sehe jedoch anderst aus und dies dürfe in Artikeln und Büchern über die agilen Methoden nicht mehr vernachlässigt werden.

Zudem vertritt er die Meinung, dass Agile sehr gut skaliert und deshalb sollte auch mehr darüber veröffentlicht werden.

Beispiel für Skalierbarkeit
Er spricht über ein Projekt mit 700 Personen und wie dieses mit agilen Methoden durchgeführt werden kann.

Zunächst ist es wichtig das übergeordnete Ziel (Vision) durch einen “Chief-Product-Owner” definieren zu lassen. Diese wird dann über eine Hierarchie von Product Ownern in die Teams getragen. Wichtig: Die POs managen das Projekt nicht sondern sind dafür zuständig die Ziele zu formulieren.

Die Teams sind ebenfalls hierarchisch strukturiert, die Koordination der Teams erfolgt durch diese selbst: “… but teams coordinate their work in ways their determine …”.

Mike fasst nochmals zusammen, was nötig ist, damit Teams funktionieren können:

• Geld / Money (Salary, Infrastructure)
• Unterstüzung / Moral Support (Feedback, removing impediments)
• Ziel / Guidance (Vision)

Schätzungen
Im zeiten Teil spricht er Über Abschätzungen und weist darauf hin, dass es für Teams wichtig ist zunächst in relativen Größen zu schätzen. Erst in einem weiteren Schritt können diese Schätzungen dann auf Dauer und Aufwand umgelegt werden.

Seht euch das Video einfach selbst an …

| View | Upload your own

Alles kein Hexenwerk. Wenn es mit einem Team einmal erfolgreich durchgeführt wurde, dann sind die Grundregeln allen bekannt. Problematische ist es, genau zu definiert, was abgeschätzt werden soll.

Ja, da sind wir wieder bei mir. Ich als Product Owner muss also wieder einmal ganz besonders dolle überlegen, weil ich sonst etwas bestelle (und bezahlen muss) was ich gar nicht will …

Eine Methode für das schnelle erste Abschätzen ganzer Backlogs habe ich ja vor kurzem bereits vorgestellt. Einen ganzen Vortrag zum Agile Estimation gibts hier.

Stories werden zueinander in Beziehung gesetzt und in kurzer Zeit (d.h. es müssen schnell Entscheidungen getroffen werden) nach Größe geordnet. Es werden dann Cluster gebildet (Vorschlag: Fibonacci-Zahlen) und die Stories entsprechend ihrem Cluster gesized.

So sollte man auch die Stories in größeren Backlogs in relativ kurzer Zeit alle abgeschätzt haben.

Diese grobe Schätz kann als Grundlage für eine Releaseplanung dienen und dann für die Sprintplanung verfeinert werden.

Leider ist mein Problem als Product Owner meist, dass es verdammt schwierig ist eine gute Story zu schreiben. Eine gut geschriebene Story dann abzuschätzen ist vergleichsweise einfach, soweit keine Risiken hinsichtlich Technologie oder Zulieferungen bestehen.

Sehr interessant ist der zweite Teil, in dem Mike auf eine Studie der Simula Research Labs hinweist (ab ca. der 11. Minute), die die Beeinflussung von Schätzungen durch eigentlich irrelevante Informationen untersucht. Beispielsweise können zusätzliche Informationen (“Der Kunde glaubt, dass es X Tage dauert.”) die Schätzung um Größenordnungen beeinflussen. Ähnliches gilt auch dann, wenn auf Termine hingewiesen wird (“Wir müssen wissen, OB DAS bis Ende des Jahres gemacht werden kann.”).

Interessanterweise waren die beeinflussten Teams stets der Meinung, dass sie in keinster Weise durch die zusätzlichen Informationen beeinflusst wurden.

Der erste Teil des Vortrags ist hier zu finden: http://www.youtube.com/watch?v=fb9Rzyi8b90.

In Scrum werden vom “Product Owner” (PO) die Wünsche (Features/Funktionen) an die zu entwickelnde Lösung in einem “Product Backlog” gesammelt. Diese Wünsche werden durch das “Scrum-Team” hinsichtlich Umsetzungsaufwand bzw. der zu erwartenden Komplexität in einem “Estimation-Meeting” bewertet. Im “Sprint-Planning” wird dann entschieden, welche Wünsche im nächsten Sprint umgesetzt werden sollen. Üblicherweise wünscht sich der PO so viele Dinge, dass die verfügbare Entwicklungszeit in einem Sprint genau ausreicht, um die Wünsche umzusetzen.

Für Abschätzungen in Scrum wird üblicherweise empfohlen nicht in Personentagen sondern in sogenannten “Scrum Sizes” zu schätzen, um Fehler im Schätzverhalten der beteiligten Personen zu reduzieren.

Eine große Herausforderung hierbei ist es, festzustellen, wie viele Wünsche (bewertet mit Sizes/Komplexität/Story Points) in X Tagen umgesetzt werden können. Es ist demnach eine Verbindung zwischen Size/Story Point und Personentag zu ermitteln.

Ich habe mittlerweile verschiedene Ansätze hierfür kennengelernt, ich möchte in den kommenden Sprints grob wie folgt vorgehen und dann die Ergebnisse bewerten:

1. Verplanbare Team PTs =  Arbeitstage (Fehlzeiten abgerechnet) – administrative Tätigkeiten – Scrum Prozesskosten – weiterer Verpflichtungen
2. Sizebare Tage (PT) = Verplanbare Team PTs – gedeckelte Support-Stories (bewertet in PT)
3. Size Faktor = Sizebare Tage / Summe Sizes (Story Points) der Stories einer Iteration

Nach einigen Sprints sollte sich der Size Faktor stabilisiert haben (evtl. Mittelwert über die n letzten Sprints legen): Die Planung wird erleichtert, da jetzt besser zu bewerten ist, ob die Summe Sizes Stories auch in der Vergangenheit in die sizebaren Tage “gepasst hätte”.

Da ich (leider) mit Multi-Projekt-Scrum leben muss, wird diese Planung relativ schnell aufwändig, vorallem wenn man eine ausreichend belastbare Aussage über die Auslastung des Scrum-Teams in den nächsten N Sprints treffen soll. Andererseits ist eine solche Planung auch beliebig ungenau, d.h. sie kann nur ein Indikator sein. Es ist deshalb stets darauf zu achten “angemessen” in Excel-Turnerei zu investieren, um nicht “Muda” zu produzieren :-)