Montag, 28. Mai 2018

Datengetriebene Retrospektiven

FS
Bild: Pexels / Lukas - CC0 1.0
Nachdem ich in der letzten Woche von Klaus Leopold in dessen unverwechselbarer Art mit Zahlen bombardiert wurde möchte ich dieses Thema auch hier aufgreifen. Agile Vorgehensweisen nehmen für sich in Anspruch, dass sie empirisch basiert und datengetrieben sind, und die naheliegendste Verwendung der erhobenen Zahlen ist ihre Nutzung als Teil des ständigen Verbesserungsprozesses. Ein guter Moment dafür sind die Retrospektiven, in denen die Metriken gemeinsam analysiert werden können. Erfahrungsgemäss bieten sich dann je nach Art der Metrik unterschiedliche Massnahmen an.

Cycle Time

Die Zeit zwischen dem Beginn einer Umsetzung und deren Ende, wobei am Ende ein Produktinkrement stehen sollte das jederzeit live gehen könnte. Im Sinn der Agilität sollte diese Zeit möglichst kurz sein, sollte das Team sie als zu lang empfinden können Massnahmen beschlossen werden um das zu beschleunigen. Dazu gehören z.B. das Kleinerschneiden von Anforderungen oder das Automatisieren von Tests.

Lead Time

Entspricht der Zeit zwischen dem ersten Aufkommen einer Anforderung und dem Ende der Umsetzung (also Cycle Time plus vorgelagerte Prozesse), was bedeutet, dass häufig andere Teams oder Abteilungen beteiligt sind. Auch diese Zeitspanne sollte so kurz wie möglich sein, zu den möglichen Verbesserungsmassnahmen gehören die Harmonisierung von Übergaben zwischen den Phasen oder die Verbesserung der Kommunikation zwischen den Teams und Abteilungen.

Throughput

Eine der häufigsten und einfachsten Metriken: erfasst wird die Zahl der vervollständigten Arbeitspakete pro Zeiteinheit (z.B. pro Monat). Da diese Zahl durch eine Vielzahl von Faktoren beeinflusst werden kann gibt es keine Verbesserungsmassnahmen die naheliegender sind als andere, hier kommt es auf den Einzelfall an.

Velocity

Im agilen Kontext wird dieser Begriff vor allem von Scrum Teams benutzt (obwohl er kein offizieller Teil von Scrum ist). Unter ihm wird die Summe der Story Points aus allen im letzten Sprint fertiggestellten User Stories verstanden. Da Story Points keine exakte Schätzung sind und ggf. nicht alle Items im Sprint so geschätzt werden ist diese Zahl mit Vorsicht zu behandeln, sie kann aber die Ausgangsbasis für eine Problemanalyse sein.

Work in Progress

Die Menge verschiedener Aufgaben an denen ein Team gleichzeitig arbeitet. Das mit zu viel paralleler Arbeit verbundene Multitasking führt in der Regel zu Konzentrationsverlust und höherer Cylcle Time, umgekehrt kann bei Arbeitsprozessen die sich über mehrere Phasen erstrecken zu wenig Arbeit in einer Phase dazu führen, dass die nachgelagerten Phasen leerlaufen. Die Gegenmassnahmen sind Ober- oder Untergrenzen, die so genannten Work in Progress-Limits oder WIP-Limits.

WIP-Age

Eine Ableitung der Lead Time. Konkret geht es darum, wie hoch die bisherige Lead Time der Aufgaben ist, die im aktuellen Moment, bzw. im aktuellen Sprint bearbeitet werden. Ist diese Wert zu hoch, die Cycle Time innerhalb der Umsetzungsphase aber niedrig, kann das bedeuten, dass in den vorgelagerten Prozessschritten Staus bestehen weil dort zu viel vorgearbeitet wird. Um das zu beheben kann es Sinn machen WIP-Limits einzuführen die über alle Phasen harmonisiert sind und dabei auch die jeweiligen unterschiedlichen Cycle Times berücksichtigen.

Blocked Days/Hours

Sowohl hohe Lead Times und Cycle Times als auch hohes WIP-Age können darauf zurückgehen, dass Arbeiten unterbrochen werden müssen um auf Zulieferungen oder Abnahmen zu warten, die von Personen ausserhalb des Teams vorgenommen werden. Ist die Anzahl der dadurch entstehenden Verzögerungstage oder -stunden zu hoch kann das dadurch ausgeglichen werden, dass das Team diese Arbeiten selbst erledigt (und das ggf. erlernt).

Bug Rate/Incident Rate

Eher unschöne Metriken, da sie die Folge von früher gemachten Fehlern und Versäumnissen sind. Dementsprechend sollten Verbesserungen am besten auf die Qualitätsaspekte der Produktentwicklung abzielen, etwa auf Testabdeckung und Code Reviews.

Bugfix Time

Auch das ist klar, je länger es dauert Bugs zu beheben desto mehr Probleme treten auf, und das sowohl bei der Systemstabilität als auch bei der Nutzerzufriedenheit. Die Bugfix Time als Sonderfall der Lead Time oder Cycle Time ist daher von besonderer Bedeutung. Die beste Gegenmassnahme ist eine Zero Bug-Policy.

---

Voraussetzung für all das ist natürlich, dass die jeweiligen Metriken permanent erhoben werden, entweder digital durch die jeweiligen Tools oder von Hand. Das ist zwar ein gewisser Aufwand, allerdings einer der sich definitiv lohnt.
Powered by Blogger.