Agile Planung und Vorhersagen

Nachdem ich mich in meinem Beitrag „Was ist anders bei agiler Planung“ mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, „Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?“ Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte – zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine „genaue“ Vorhersage ist daher unmöglich, bei einer „verbindlichen“ Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was „geschafft wird“, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: „So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein“. Genügen einem diese 80% nicht, muss man es eben höher priorisieren – auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte „versprechen“. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Verteilung der Velocity

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche „Termine und Umfang stehen fest“, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit „durchsetzungstarkem Management“ verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

2 Gedanken zu „Agile Planung und Vorhersagen

  1. Erst mal super, dass dein Feed jetzt die kompletten Artikel enthält!

    Eine Anmerkung zum aktuellen Artikel. Du schreibst „…dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen…“
    Ich denke man muss da je nach Team sehr vorsichtig sein. Manche Teams reagieren auf eine zu volle Featurschlange mit Beschleunigung durch schlechtere Qualität. Bei solchen Teams – wieviele sind das? – darf man nicht mehr verplanen als man *guten Gewissens* versprechen kann. Slack benutzt man dann am besten zum Abzahlen der technischen Schulden. Hat man auch dann immer noch Zeit, kann man ja nachplanen, d.h. in Absprache mit dem Kunden neue Stories nachschieben.

  2. Hallo Johannes,

    Du sprichst da ein wichtiges Problem an; ich schätze die Quote liegt gerade am Anfang tritt es bei mindestens bei 50% der Teams auf. Allerdings muss man sehr vorsichtig sein, wie man dieses Problem addressiert. Die von Dir vorgeschlagene Lösung funktioniert zwar, hat aber zwei sehr gewichtige Nachteile:

    1. Man kann die statistischen Verfahren nicht mehr einsetzen, weil sich dann der Mittelwert der Velocity immer weiter nach unten verschiebt. Man kappt sozusagen die Rückkopplungsschleife und muss mit „gutem Gewissen“ arbeiten. Das ist zwar kein Ausschlusskriterium für diese Lösung, aber aus meiner Sicht ein gewichtiger Nachteil
    2. Das Team wird dadurch zu einem gewissen Teil entmündigt. Wer immer die Entscheidung trifft, so zu arbeiten, unterstellt dem Team, dass es von sich aus nicht in der Lage ist, unter Druck qualitativ saubere Software zu liefern. Die Diagnose mag richtig ober falsch sein, die Reaktion erschwert aber die Selbstorganisation eher, als dass sie dieses grundsätzliche Problem angehen würde. Aufgrund dieser Überlegung würde ich Deinen Vorschlag als Dauerlösung nicht empfehlen, höchstens als Interimslösung, um Zeit zu gewinnen, das eigentliche Problem anzugehen.

    Ich sehe noch mindestens zwei Alternativen, die meines Erachtens nicht so stark in das Selbstbestimmungsrecht des Teams eingreifen.

    Zum einen könnte man das Planungsverfahren um eine weitere Kanbantechnik erweitern. Tritt das von Dir beschriebene Problem auf, so führt das ja meistens dazu, dass neue Funktionalität sehr schnell entwickelt werden, aber lange im anschließenden manuellen explorativen Test hängen, weil immer wieder neue Fehler entdeckt werden. Das führt dazu, dass sich „realisierte“ Karten vor oder im Test stauen. Nun kann man gemäß Kanban die maximale Länge dieser Warteschlange begrenzen, z.B. auf 10 oder 20 Punkte. Ist die Warteschlange so weit gefüllt, werden keine neuen Features mehr angefangen, sondern nur noch Fehler behoben und Designschulden abgetragen. Das senkt auch automatisch die Velocity und ist daher ein selbstregulierendes System. Allerdings springt es natürlich nur auf Schlampereien an, die unmittelbar zu mehr Fehlern führen, nicht auf langfristige Designprobleme.

    Alternativ (oder ergänzend) könnte man auch das Team in dieses Problem hineinlaufen lassen und versuchen, die Folgen durch andere Metriken transparent zu machen, wie Durchlaufzeit pro Feature (zu lang wegen Fehlern), Designmetriken etc. Das würde dem Umstand Rechnung tragen, dass hier möglicherweise zu einseitig auf die Velocity gestarrt wird und eine „Metrikverzerrung“ stattgefunden hat: Die Metrik hat die Realität angepasst, nicht umgekehrt. Aber auch dieser Ansatz ist zweischneidig, weil man den Teufel (Metrikverzerrung) mit dem Belzebub (noch mehr Metriken) austreibt. Also auch das nur eine Übergangslösung, zumal Designmetriken mehr als fragwürdig sind.

    Es bleibt der Versuch einer Ursachenanalyse (Root Cause Analysis), um das eigentliche Problem hinter dem Verhalten des Teams zu finden und zu beheben. Das wird erfahrungsgemäß kaum auf Anhieb klappen, deshalb kommt man meistens um die Teillösungen nicht drum rum. Aber ich denke, hier lohnt sich Geduld.

Kommentare sind geschlossen.