Das Bauchgefühl des Entwicklungsteams kann ein wichtiger Indikator für Engpässe im Entwicklungsprozess sein.
Esther Derby und Diana Larsen beschreiben in ihrem Buch Agile Retrospectives: Making Good Teams Great
Je nach Team wurden verschiedene Aspekte bewertet:
- Teamwork
- Sprint Deliverable Quality
- Product Quality
- Product Vision
Bei der Benotung habe ich mich an den im Buch vorgegebenen Beispiel für Teamwork orientiert. Hier z.B. meine Formulierungen für Product Vision und Product Quality:
Product Vision
1 = The vision is brilliant and directs to amazing success.
2 = I believe following the vision will lead to success. It motivates me.
3 = The vision is clear and understandable, but it doesn’t help much.
4 = To me the vision is not plausible. It doesn’t encourage me at all.
5 = I don’t know the product vision or I think following it is a complete waste of time.
Product Quality
1 = I think we have a perfect product! It is absolutely flawless.
2 = I am fully satisfied with the quality of our product.
3 = I’m fairly satisfied. Overall the quality is nothing to be ashamed of.
4 = We didn’t ignore quality, but it was not enough.
5 = I’m unhappy and dissatisfied. I lie awake at night because of our poor product quality.
Das Team hat anonym abgestimmt, den Durchschnitt berechnet und in ein Diagramm eingetragen, in dem man den bisherigen Verlauf sehen konnte. Anschließend wurde darüber reflektiert, insbesondere bei großen Ausschlägen oder wenn das Ergebnis überraschend ausfiel. Der Product Owner durfte mit abstimmen. Ich als ScrumMaster habe nicht mitgestimmt.
Mit der Zeit entstanden Verlaufskurven wie die folgende:
Die Abstimmung und das Diagramm dienten in vielen Fällen als Katalysator für Diskussionen: Schlechte Werte oder Tendenzen nach unten bildeten einen guten Ausgangspunkt für die Frage nach dem Warum. Oft hat die Diskussion Gründe aufgezeigt, die nicht offensichtlich waren. So hatte zum Beispiel ein starkes Absinken der Product Quality und Sprint Deliverable Quality (Sprint F) keine Ursache in technischen Veränderungen, sondern in verstärkter Analyse. Weniger überraschend war, dass die Qualität des Sprint-Deliverables stärker schwankt als die Qualität des Produkts insgesamt. Zum Teil waren die Tendenzen dort sogar gegenläufig (Sprint C), wenn z.B. nicht alle für den Sprint geplanten Stories umgesetzt werden konnten, aber ein unangenehmer Performance-Bug entfernt werden konnte. Die Messung der Product Vision zeigte, wann diese wieder aufgefrischt werden muss, wenn das Team sie im Tagesgeschäft mit der Zeit aus dem Blick verloren hat. Wichtig ist aber auch die Ergebnisse nicht überzuinterpretieren. Je nachdem wer gerade anwesend ist und je nach Tagesstimmung schwanken die Ergebnisse.
Insgesamt halte ich das Histogram für ein nützliches Mittel um ein objektiviertes Gefühl für verschiedene Aspekte des Entwicklungsprozesses zu bekommen. Mehr als vier Bereiche würde ich dabei nicht gleichzeitig betrachten, damit die Methode leichtgewichtig bleibt.
Im Buch wird empfohlen die Messungen nur alle paar Iterationen durchzuführen. Es ist richtig, dass sich mit der Zeit ein gewisser Ermüdungseffekt einstellt. Ich fand es allerdings wertvoll jeden Sprint einen Messwert zu haben, um Trendwenden zeitnah mitzubekommen.Wenn man feststellt, dass die Werte konvergieren bzw. kaum noch neue Erkenntnisse produzieren, sollte man die betrachteten Bereiche variieren.
Agile Product Development 