Embrace your CFD!
Geschichten von Menschen und Metriken
Cumulative Flow Diagram, Lead Times & Co — was sagt der gesunde Messverstand?
Vor nicht allzu langer Zeit saß ich in einer Runde von Scrum Mastern. Gemeinsam haben wir uns Cumulative Flow Diagram, Lead Time Run Chart und Lead Time Distribution Chart verschiedener Teams angesehen und darüber gesprochen, welche Hypothesen anhand der Diagramme formuliert werden könnten.
Beinahe wäre der Termin entspannt verlaufen, bis ein Scrum Master empört aufstand und aus voller Überzeugung sagte:
„So etwas ist nur für schlechte Scrum Master! Ich kenne mein Team! Ich brauche das nicht!“
Und da war er auch schon aus dem Raum verschwunden.
Ist die Auswertung agiler Metriken tatsächlich etwas, das im Gegensatz zu Bauchgefühl und guter Teamkenntnis steht?
Für mich ein klares „Nein!“. Gerade die Kombination aus beidem wird benötigt, um das Maximum an Verbesserungspotential zu entdecken.
Schließlich geht es in der agilen Welt um Geschwindigkeit. Es geht um die kontinuierliche Auslieferung (wertvoller Software), in einem gleichmäßigen Tempo, in regelmäßigen Abständen und dabei soll die kürzeste Zeitspanne bevorzugt werden. Diese Geschwindigkeit erreiche ich unter anderem durch die Nutzung agiler Instrumente und deren gemeinsamer Analyse mit dem Team. Die analytische Perspektive hilft mir dabei, das eigene Bauchgefühl zu unterstützen, zu quantifizieren oder auch zu hinterfragen. Es hilft mir bei der Interpretation der Daten und dem Ableiten von Verbesserungsmaßnahmen, deren Wirksamkeit ich wiederum durch Metriken validieren kann.
Bei dem Thema Metriken geht es eben nicht darum, alles in Zahlen auszudrücken und mich blind auf diese zu verlassen. Vielmehr geht es darum, eine weitere Perspektive auf das Projektgeschehen zu erlangen.
Nehmen wir beispielsweise das Cumulative Flow Diagramm, welches mir hilft, die Entwicklung meines Prozesses zu verstehen. Ich erkenne, ob Engpässe vorhanden sind und auch, an welcher Stelle des Prozesses sich diese bemerkbar machen.
Ohne gute Teamkenntnis werde ich dort nicht viel mehr als Linien sehen und im besten Fall ein paar Hypothesen aufstellen können. Validieren kann ich diese aber nur, wenn ich gemeinsam mit dem Team auf Ursachenforschung gehe, Maßnahmen zur Verbesserung definiere und diese retrospektiv nach deren Erfolg beurteile. Diesen sehe ich wiederum im CFD. Genauso kann ich wiederkehrende Muster erkennen und analysieren, um für die Zukunft zu lernen. Diese Wiederholungen können bekannt und geplant sein, wie die Weihnachtspause. Andere muss ich genauer unter die Lupe nehmen.
Selbiges gilt für die Betrachtung der Lead Time im Lead Time Run Chart. Wie lange dauert es, bis Features fertiggestellt werden? Wie stabil ist mein Prozess? Ich höre dann oft: „Wir arbeiten in 2 Wochen Sprints, daher beträgt unsere Lead Time natürlich 14 Tage.“ Der dazugehörige Run Chart sieht dann folgendermaßen aus:
Bei der Auswertung sehen wir Ausreißer von 200 Tagen und mehr. Möglicherweise sind diese Langläufer bereits bekannt und im Einzelfall womöglich auch die Ursache für deren Jahresurlaub im Backlog. Spannend wird es, sobald Features regelmäßig länger brauchen. Und das ungeplant. Womöglich eine fehlende Testumgebung? Oder eine Abhängigkeit zu einem anderen Team? Spezialwissen eines einzelnen Teammitglieds? Dabei hilft mir dieser Überblick über Langläufer nicht nur bei der Weiterentwicklung innerhalb Teams, sondern dient nebenbei noch als Argumentationsgrundlage gegenüber externen Entscheidungsträgern.
Umgekehrt werde ich gerade im Konzernumfeld immer wieder gefragt, welche „agilen KPIs“ es aus Managementsicht gäbe jenseits von Story Points. Auch als Führungskraft interessieren mich Metriken hinsichtlich Prozessentwicklung und Liefersicherheit. Und zwar keine Metriken zu einzelnen Teammitgliedern, sondern solche, die das Team oder mehrere Teams als Ganzes berücksichtigen. Einerseits helfen diese dabei Lieferprognosen und — zusagen zu tätigen, andererseits liefern sie auch Hinweise, wo ich als Führungskraft besser unterstützen kann.
Das Schöne ist, dass ein Cumulative Flow Diagram nicht zwingend gut oder schlecht ist (außer die Linien gehen nach unten oder kreuzen sich. Das ist dann nicht nur schlecht, sondern auch falsch. Und genaugenommen ist es dann auch kein CFD mehr). Oder vergleichbar mit anderen Teams. Dieser Chart ist genauso individuell wie das Team selbst. Ob die Entwicklungen gut oder schlecht sind kann nur das Team mit Blick auf die geplante Entwicklung des Prozesses gemeinsam herausfinden.
Natürlich gibt es darüber hinaus viele weitere Mess- und Steuerungsinstrumente, welche nicht nur die Prozessperspektive beleuchten, sondern beispielsweise auch den Kundennutzen und Business Value in all seinen Facetten.
Was ich damit sagen möchte: Entscheidet euch nicht zwischen Bauchgefühl und Zahlen. Kombiniert doch eure gute Teamkenntnis mit der Auswertung agiler Metriken sowie einer sinnvollen regelmäßigen Retrospektive. Und natürlich gesundem Mess- ähh…Menschenverstand. Das macht aus euch keinen schlechten Scrum Master, sondern einen noch besseren.
“The only way to win is to learn faster than anyone else” (Eric Ries)
Embrace your CFD!
Eure Eva
PS: Liebe Agile Coaches und Scrum Master da draußen — versucht doch einmal eure Wirksamkeit messbar zu machen.
