Auch letztens habe ich von einem in Agilität erfahrenen Menschen gehört, dass er den Kunden erzählt habe, dass man ja gar nicht sagen könne, wann man „fertig“ sei. Das ginge, wenn man agil arbeitet, ja nicht.
Innerlich bin ich (mal wieder) vom Stuhl gefallen! Und warum ich diese Aussage für falsch und auch für schädlich halte, möchte ich hier etwas genauer ausführen.
klassisch – agil
Das Versprechen des klassischen Vorgehens in der Softwareentwicklung ist ja, dass man das erhält, was man einmal abgesprochen hat. Und das in der vereinbarten Zeit, für das vereinbarte Geld in der gewünschten Qualität. Ja, wir wissen, dass dieses Versprechen kaum zu halten ist und sich u.a. deshalb agile Haltungen entwickelt haben. Aber dieser Anspruch steht nun mal im Raum und an dem müssen wir uns nun mal messen lassen.
Wenn nun also unternehmerische Maßnahmen darauf abzielen beispielsweise Geld/Personal einzusparen, schneller, besser mehr zu produzieren, dann sind viele Menschen in Entscheiderpositionen geneigt auf dieses Versprechen zurückzugreifen. Insbesondere, wenn es um die Frage geht: Wann seid ihr denn fertig? Und es ist imho ein Armutszeugnis, dass es immer noch Aussagen gibt, die verneinen, dass dies in einem agilen, iterativen, empirischen Vorgehen nicht möglich sei. Das ist in so fern schädlich, als Entscheider dann (natürlich) dazu neigen, den Versprechen klassischen Vorgehens zu folgen.
Ich behaupte: Vorhersagen im agilen Kontext sind möglich und ich versuche das nun darzustellen.
agile Vorhersagbarkeit
Ok, ich gebe zu, eine kleine Voraussetzung muss ich annehmen, um zu sinnvollen Ergebnissen zu kommen. Eine kleine: Und das ist die Annahme, dass es in jedem Produkt, in jedem Team Arbeitseinheiten, Epics, Stories, Aufgaben, ToDos usw. gibt, deren Reporting und Controlling sich lohnen könnte. Der Einfachheit halber beziehe ich mich in diesem Text mal auf Epics, wie sie landläufig genutzt werden, d.h. als umgangssprachlich angelehnte Beschreibung eines größeren zusammenhängenden Funktionszusammenhangs.
In einem empirischen Prozess können wir (hoffentlich) aus der Kenntnis der Vergangenheit Aussagen für die Zukunft treffen. Dazu müssen wir aber im Hier und Jetzt unsere Arbeit messen. In unserem Fall also die Frage: Was ist mit unseren Epics? Wie viele haben wir in einem bestimmten Zeitraum abgeschlossen, wie viele sind dazu gekommen?
Haben wir diese Werte über einen gewissen Zeitraum aufgenommen und stellen diese grafisch dar, so ergibt sich hoffentlich eine abfallende Kurve, die uns annehmen lässt, dass wir irgendwann fertig werden.
Und natürlich kann so eine Kurve auch mal ansteigen, wenn Epics neu gebildet, gewünscht bzw. gefunden werden. In einem agilen Prozess ist das eher die Regel als die Ausnahme.
Diese Kurve scheint ein bisschen so auszusehen wie ein klassischer Burn-Down Chart; ist es aber nicht. In einem Burn-Down Chart wird die Bearbeitung von Story Points betrachtet. Hier befinden wir uns auf einer deutlich höheren Flugebene (z.B. Epics oder noch höher).
Warum ich gar nicht so viel von einem Tracking auf niedriger Flugebene (z.B. im Rahmen von Velocity auf Sprintebene) halte, habe ich hier schon mal beschrieben.
Eine einfache Ausgleichsgerade, die man durch diesen Graph legt, kann eine gute Prognose für den Fertigstellungszeitpunkt liefern.
Einschränkungen
Was bei diesen Annahmen nicht beachtet wird, ist, dass in einem agilen Setting durchaus gewünscht ist, dass immer neue Ideen, Anregungen, weitere Funktionen aufgenommen werden. D.h. ein „fertig“ im eigentlichen Sinne gibt es u.U. gar nicht, sondern eher ein „gut genug“. Wahrscheinlich ist dies aber eher auf der Ebene der Stories der Fall und weniger auf Epic-Ebene (aber ausgeschlossen ist das natürlich nicht …)
Meine Annahme geht also davon aus, dass zwar durchaus Epics während der Entwicklung neu hinzu kommen können, aber am Ende alle großen Funktionsgruppen bearbeitet/abgearbeitet sein sollen. D.h. heißt nicht, dass das Backlog dann leer ist.
Ich hoffe, dass diese Hinweise helfen können, ob meine Ausführungen hier für ein bestimmtes Szenario relevant sein können, oder nicht.
Das magische Dreieck
Nein, mit Magie hat das weniger zu tun als mit Projektmanagement oder Wirtschaftlichkeit. Wie auch immer besagt dieses Bild (vereinfacht), dass die drei sich z.T. widerstrebenden Ziele bei der Softwareentwicklung Qualität, Zeit und Kosten sind. Man möchte also in möglichst kurzer Zeit, mit möglichst niedrigen Kosten eine maximale Qualität erzielen.
In aller Regel haben unsere Kunden/Auftraggeber eine recht klare Vorstellung von der Zeit und den Kosten. Die Frage „bis wann“ etwas gebraucht wird und welche Gelder investiert werden sollen, kann recht gut beantwortet werden.
Qualität ist oftmals recht schwammig definiert. Qualitätssicherung ist oft vereinfacht die Suche nach Fehlern. Oder die höchst genaue Umsetzung vorgegebener Anforderungen ohne sie zu hinterfragen. All das (und einiges mehr) ist nicht sehr hilfreich.
Ein einfacher (und auch fundamental wichtiger) Ansatz, um sich der Qualität zu nähern, ist der Begriff „Wert“. Eine Software ist dann von hoher Qualität, wenn sie einen hohen Wert für den Kunden liefert/darstellt. Auch ein agiles Prinzip spricht davon, den Kunden durch die Lieferung wertvoller Software zufrieden zu stellen. Das ist genauso einfach gesagt, wie schwierig umzusetzen.
Also, da wir kaum bis keinen Einfluss auf die Kosten und die Zeit haben, ist der einzige Einfluss auf die Qualität, den Wert (s.o.) der Software. Und da wir natürlich kein minderwertiges Produkt erstellen wollen, suchen wir stetig nach dem MVP, in unserem Fall dem Minimum Valuable Product. Mit dem Fokus auf dem kleinsten, den Wertvorstellungen des Kunden entsprechenden, Produkt.
Und wenn man sich den Burn-Down Chart der Epics oben anschaut, dann macht er natürlich nur Sinn, wenn wir auch dabei über das MVP sprechen.
Controlling und Lieferfähigkeit
Fassen wir doch einfach die vorherigen Gedanken und Ausführungen zusammen!
Wir spiegeln dazu den Epic „burn-down“ Chart von oben und machen ihn zu einem „burn-up“ Chart (blau). Andere Darstellung, gleiche Aussage.
Dazu tragen wir die bis zu einem Zeitpunkt verbrauchten Kosten auf. Das ist eigentlich nicht so schwierig; das sind im Wesentlichen Personalkosten, Werkzeuge (Rechner, Server, Software, IDE …), Raumkosten usw., wobei die Personalkosten den Löwenanteil stellen dürften. Wenn wir der Einfachheit halber von einem stabilen Team ausgehen, dann ist das eine Gerade über der Zeit. Und unser Chart hat sich verändert …
Interpretation des Charts
Liegt die Kurve der fertig gestellten Epics unterhalb der Kostenkurve, so liegt man augenscheinlich zurück (siehe oben). In dem Chart scheint es zum Ende steil(er) sich der Kostenkurve anzunähern, was man eher aus einem klassischen Vorgehen kennen mag, wenn es zum Ende „eng wird“ und alle noch mal „Gas geben“.
Ja, oftmals lässt sich das Ziel damit noch erreichen, in einem agilen Umfeld ist das nicht wirklich wünschenswert („sustainable pace“) … Dies ist dann von der agilen Führung im Team oder anderer Abteilung sinnvoll zu berücksichtigen (was den Rahmen des Artikels weit sprengen würde).
Wenn sich die Kosten nicht linear darstellen, so lassen sich die Produktsituationen über der Zeit herauslesen. Budgetaufstockungen und -einschränkungen.
So kann eine Aufstockung der Epics / eine Veränderung des MVPs natürlich zu einer Erweiterung des Budgets im Rahmen von Verhandlungen führen. (Siehe Bild)
Interessant wird es, wenn die beiden Kurven sich schneiden.
Wenn die Fertigstellungskurve die Budgetkurve schneidet, ist das ein Zeichen für Gesprächsbedarf: Wird mehr Wert geliefert als Budget abgerufen wird, ist ggf. das Produkt falsch finanziert. Ergibt sich da die Möglichkeit das MVP zu verändern/erweitern? Ist das Produkt unterfinanziert? Usw. usf.
Ähnliche Fragestellungen ergeben sich, wenn sich die Kurven in die andere Richtung schneiden. Wie auch immer ist das eine außergewöhnliche Situation, die mit den zugehörigen Instanzen, Stakeholdern des Produktes besprochen werden sollte.
Fazit
Natürlich ist das kein umfassendes Controlling und auch muss man darauf achten, agile Werte und Prinzipien einzuhalten. Deshalb könnte es sinnvoll sein, nicht jede Woche, sondern vielleicht nicht öfter als einmal im Quartal drauf zu schauen und nicht bis auf Story-Ebene heruntergehen.
Download
Das Ganze gibt es natürlich auch in Excel und kann hier heruntergeladen werden. Wenn man mit den Daten ein bisschen rumspielt, erkennt man recht schnell, wie alles zusammenhängt.
Ich würde mich sehr über ein Feedback freuen. Nur, weil wir das erfolgreich einsetzen, muss es nicht sinnvoll für eine andere Situation sein …
- Wie macht ihr ein „agiles Controlling“?
- Wie stellt ihr fest, ob ihr noch auf Kurs seid?
- Wie könnt ihr einen „Fertig“-Termin kommunizieren?
