Forecasting: Gewisse Wahrscheinlichkeit statt trügerischer Sicherheit
Kunden und Manager wünschen sich von Vorhersagen 100-prozentige Sicherheit. Mit Erfahrungen aus der Vergangenheit wird dabei in die Zukunft geschätzt. Forecasting arbeitet mit Wahrscheinlichkeiten, die sich aus aktuellen Daten ableiten. Der Vorteil: Die Prognosen sind realitätsnah und brauchen viel weniger Zeit als Schätzungen.
Wahrscheinlich kann man Wissensarbeitern keine schlimmere Frage stellen als: "Wann wird es fertig sein?" Aus betriebswirtschaftlicher Sicht hat diese Frage ihre Berechtigung, denn ohne zeitliche Anhaltspunkte über den Output eines Arbeitssystems lässt sich ein Unternehmen nur schwer steuern. Dabei wird gerne ein Faktum übersehen, an dem sich nie etwas ändert, ob man nun mit Kanban, Scrum, klassischem Projektmanagement oder welcher Methode auch immer arbeitet. Nassim Nicholas Taleb beschreibt das in seinem Buch "Antifragilität" sehr schön anhand der Wahrnehmung eines Truthahns [1]:
"Ein Truthahn wird tausend Tage lang von einem Metzger gefüttert; jeden Tag verkündet der Truthahn seinem Analysestab ‚mit wachsender statistischer Zuversicht’, dass Metzger Truthähnen wohlgesonnen sind. Der Metzger wird den Truthahn weiterfüttern, und zwar bis kurz vor Thanksgiving. Dann kommt der Tag, an dem es gar nicht schön ist, ein Truthahn zu sein. Der Metzger wartet mit seiner Überraschung auf – und das ausgerechnet im Moment größtmöglicher Sicherheit bezüglich der Aussage, dass der Metzger Truthähne mag, dass im Leben des Truthahns ‚alles seinen ruhigen Gang geht’ und völlig vorhersehbar ist."
Das Leben bietet keine 100-prozentige Sicherheit vor Situationen, die alles bisher Bekannte auf den Kopf stellen. Wenn es aber um das Fertigstellen von Produkten und Projekten geht, die in der Wissensarbeit nicht nur nie gleich verlaufen, sondern auch hochvariablen Einflüssen unterliegen, wollen wir mit 100-prozentiger Sicherheit wissen, wann es fertig sein wird. Noch dazu will man anhand des Wissensstands von heute und gestern erfahren, was in der Zukunft eintreten könnte. Das bisher Passierte wird als Konstante betrachtet und linear fortgeschrieben, das spiegelt sich in Schätzungen als Prognoseansatz wider. Problematisch ist am Schätzen: In Anbetracht eines mageren Grades an Genauigkeit nimmt es viel Zeit in Anspruch. Und jeder hasst es, zu schätzen, weil jeder weiß, wie unsicher es ist.
Dass uns das Schätzen schwerfällt, liegt in erster Linie an unserer eingeschränkten Sicht auf die Durchlaufzeit von Arbeiten: Diese besteht nämlich wegen diverser Abhängigkeiten großteils aus Wartezeiten, geschätzt wird aber nur die reine Arbeitszeit. Weil man ahnt, dass etwas schiefgehen könnte, werden 100 oder 200 Prozent aufgeschlagen. Sind voneinander und von externen Beteiligten abhängige Teams in ein Projekt involviert, werden die Schätzungen einfach addiert – dadurch wird die gesamte Schätzung aber nicht genauer. Darüber hinaus gibt es am Weg zum fertigen Produkt tausende Störfaktoren, die sich auf die Durchlaufzeit auswirken: Urlaube, Krankheiten, Veränderungen im Team, Gesetzesänderungen, Reorganisationen, instabiler Work in Progress, mehr Mitarbeiter, besserer Kaffee – das alles bestimmt den Lauf einer Arbeit und man hat kaum Einfluss darauf.
Sobald es Daten gibt, kann man einen Forecast erstellen.
Verabschieden wir uns also von dem Gedanken, dass wir mit 100-prozentiger Sicherheit sagen können, wann etwas fertig wird. Ist es daher sinnlos, überhaupt Vorhersagen zu treffen? Nein, es gibt sehr wohl Mechanismen, die Prognosen möglich machen. Wir müssen uns lediglich daran gewöhnen, statt mit absoluten Sicherheiten mit Wahrscheinlichkeiten zu operieren. Schätzungen sind dann nur noch nötig, solange es keine realen Daten gibt. Sobald es Daten gibt, kann man stattdessen einen Forecast erstellen. Zwei Varianten – das Single Item Forecasting und das kontinuierliche Durchsatz-Forecasting – will ich hier vorstellen. Dabei beziehe ich mich exemplarisch auf die Arbeit in und mit Kanban-Systemen [2], die Prinzipien des Forecastings sind aber in allen Arbeitssystemen anwendbar, die Messdaten generieren.
Wissensarbeit: Ein Fall für Forecasts
Bekanntermaßen schätzen Meteorologen das Wetter der kommenden Tage nicht. Das Wetter ergibt sich aus einem Zusammenspiel verschiedenster Faktoren und daher versuchen Meteorologen durch Beobachtung, die Zusammenhänge und Auswirkungen vergangener und aktueller Phänomene zu erfassen, zu interpretieren und daraus Modelle zu bilden. Meteorologie ist eine durch und durch empirische Wissenschaft, die nur wenige Fragen durch Laborbedingungen beantworten kann. Je nachdem, wie die laufenden Messungen einzelner Faktoren wie Luftdruck, Wolkendichte, Strömungen etc. ausgeprägt sind, ergibt sich eine Wahrscheinlichkeit für das Eintreten bestimmter Wetterlagen. Tritt zum Beispiel die Wettervorhersage "Mit 70 Prozent Wahrscheinlichkeit wird es ab dem frühen Nachmittag regnen" nicht ein, wird analysiert, warum das so ist – es wird eine Lernschleife eingelegt. Die Modelle werden also mit jeder neuen Beobachtung adaptiert und ihre Ergebnisse werden ständig aktualisiert.
Das Beispiel der Wettervorhersage verwende ich präventiv. Denn ich höre immer wieder das Argument: "Ja, Forecasting funktioniert, wenn man in einem Produktionsbetrieb arbeitet oder immer das Gleiche macht. Wissensarbeit ist hochvariabel und da klappt das nicht." Das Wetter ist wohl eine der dynamischsten Erscheinungen – jede geringste Schwankung an einem Ende der Welt hat Einfluss auf die Wetterentwicklung am anderen Ende der Welt (Schmetterlingseffekt [3]). Dennoch sind die Wettermodelle so weit gediehen, dass Prognosen mit relativ hoher Wahrscheinlichkeit eintreffen. Wenn es beim Wetter funktioniert, warum sollte das Forecasting also in der Wissensarbeit nicht funktionieren?
Wenn man mit dem Vorhaben (Projekt, Produkt etc.) beginnt, für das man einen Forecast machen will, liefern die Modelle zunächst unsichere Ergebnisse. Mit jeder Messung und jeder Verfeinerung erhält man aber genauere Resultate. Das ist übrigens kein Charakteristikum, das ausschließlich auf Forecasts zutrifft. Es ist auch möglich, Schätzungen immer genauer werden zu lassen, nur wird dieses Faktum häufig negiert. Stattdessen hält man krampfhaft an einem Plan fest, der schon lange nicht mehr die Realität widerspiegelt, weil er auf Daten aus der Vergangenheit basiert. "Das werden wir schon noch schaffen", höre ich dann oft, aber das Wunder trifft nur selten ein. Vor allem am Anfang, wenn es keine Daten gibt, braucht man Mut zu Annahmen, Wahrscheinlichkeiten und Bandbreiten. Vielleicht ist der Anteil von Arbeits- und Wartezeiten bereits aus Messungen bekannt, vielleicht muss man sich aber zunächst auf Aussagen verlassen, so wie ich oder andere Autoren sie treffen. Wie auch immer: Wichtig ist, deutlich zu machen, worauf sich die Annahmen stützen. Und ja, möglicherweise muss man zu Beginn mit Schätzungen arbeiten, die dann schrittweise durch reale Daten verifiziert und ersetzt werden. Oder wie Nobelpreisträger Richard Feynman den ersten Schritt zur wissenschaftlichen Erkenntnis formuliert hat [4]: "First we guess it." Dabei muss man sich auf das Wissen der Menschen verlassen, die die eigentliche Arbeit machen. Es sollte aber das Ziel sein, diese Menschen so schnell wie möglich in Ruhe arbeiten zu lassen, statt sie mit ständigen Schätzungen von der Arbeit abzuhalten.
Vorhersagen mit harter Währung
Ob geschätzt oder auf Daten basierend: Ausschlaggebend ist, dass man mit Einheiten aus der realen Welt arbeitet – Euro, Minuten, Anzahl etc. Agile Managementframeworks bringen eigene Metriken ins Spiel, an denen sich der Fortschritt der Arbeit und die Produktivität eines Teams ablesen lassen. Dagegen ist grundsätzlich nichts einzuwenden, sofern Storypoints und Velocity als teaminterne Orientierungspunkte verwendet werden, um Verbesserungspotenziale zu identifizieren.
Unter Agilität verstehe ich unter anderem, die Sprache des Kunden zu sprechen.
Der Forecasting-Spezialist Dan Vacanti bringt aber einen interessanten Punkt auf: Das Agile Manifest betont die Zusammenarbeit mit dem Kunden [5]. Gleichzeitig wird der Kunde gezwungen mit Metriken zu hantieren, die zum Beispiel in der Welt eines CFO kein Äquivalent haben, denn er rechnet in Zeit und Geld. Als Argument für agile Metriken wird für meinen Geschmack zu oft das Thema Komplexität ins Spiel gebracht und man erfindet sogar eine eigene Algebra, um diese Komplexität in den Griff zu bekommen. Ich finde: Wir sollten damit aufhören Komplexität als Ausrede für Dinge zu verwenden, die wir entweder nicht verstehen oder nicht besser können. Unter Agilität verstehe ich unter anderem, die Sprache des Kunden zu sprechen. Zeit, Anzahl der Features im Release, Euro: Diesen Maßzahlen müssen wir uns stellen, denn damit können Kunden etwas anfangen.
Voraussetzungen für das Forecasting
Forecasts sind nur möglich, wenn man sich laufend mit dem Zustand eines Arbeitssystems auseinandersetzt. Ich will hier drei Parameter hervorheben, die kontinuierliches Feedback über den Zustand geben und anhand derer man klare Entscheidungen treffen kann. In erster Linie geben diese drei Metriken Aufschluss darüber, ob die Arbeit in einem System tatsächlich im Fluss ist. "Im Fluss" bedeutet, dass Arbeitseinheiten möglichst zügig und ohne Reibungsverluste die Sequenz von Aktivitäten durchlaufen, aus denen sich der Weg der Wertgenerierung zusammensetzt.
- Work in Progress (WIP): Wie groß ist die Arbeitsmenge im System?
- Durchlaufzeit: Wie lange brauchen Arbeitseinheiten, bis sie fertig sind?
- Durchsatz: Wie viele Arbeitseinheiten werden in einem bestimmten Zeitraum fertig?
Work in Progress
Wenn ich mit den Beteiligten in einem Unternehmen ein Kanban-System entworfen habe und es anschließend in Betrieb nehme, empfehle ich, sofort den Work in Progress zu messen – noch bevor wir uns mit der Durchlaufzeit oder mit dem Durchsatz beschäftigen. Warum? Der Work in Progress ist der beste Indikator dafür, wie stabil ein System ist. Fehlende Stabilität ist nämlich im Großteil der Fälle das vordringlichste Problem, gleichzeitig ist Stabilität (und damit die Vorhersagbarkeit eines Systems) die Voraussetzung für das Forecasting. Damit sich ein System stabilisieren kann bzw. stabil bleibt, muss der Work in Progress limitiert werden, denn er beeinflusst auch die Durchlaufzeit und den Durchsatz von Arbeitseinheiten. "Work" ist als eine Einheit zu verstehen, die für den Kunden Wert generiert, wenn sie fertig ist – es werden für die Messung also nicht die einzelnen Tasks (Teile einer Arbeitseinheit) betrachtet. "In Progress" bedeutet so viel wie "in Ausführung befindlich". Daher muss geklärt werden, wann sich eine Arbeit überhaupt in Ausführung befindet und das setzt voraus, dass die Grenzen eines Arbeitssystems definiert wurden. In einem Kanban-System ist dieser klar umgrenzte Bereich ab dem Punkt der Zusage limitiert.
Durchlaufzeit
Das Messen der Durchlaufzeit ist wichtig, um die Frage "Wann wird es fertig?" beantworten zu können. Wurde der Work in Progress limitiert, ist die Durchlaufzeit sehr leicht zu messen: Die Durchlaufzeit gibt an, wie lange sich eine Arbeit in Ausführung befunden hat. Daher ist es so wichtig, im Vorfeld die Grenzen des Ausführungsbereichs festzulegen. Es geht also nicht um Aufwand oder aktive Arbeitszeit, sondern um die gesamte Zeitspanne, die eine Arbeit in der Ausführung verbracht hat, inklusive Wartezeiten. Da man bei einem Forecast auf ein Datum hinarbeitet, sollten Kalendertage als Basis herangezogen werden. Sind historische Daten auf Basis von Arbeitstagen vorhanden, sollten sie in Kalendertage umgerechnet werden. Tipps dazu gibt es von Troy Magennis [6].
Durchsatz
Der Durchsatz ist die Anzahl der Arbeiten, die pro Zeiteinheit den limitierten "in Progress"-Bereich verlassen, weil sie abgeschlossen sind – zum Beispiel drei Storys pro Tag, acht Features pro Woche, vier Projekte pro Monat. Der Durchsatz beantwortet also die Frage: "Wie viel werde ich bis zu einem bestimmten Datum oder bis zum nächsten Release bekommen?" Wenn wir Abb.1 betrachten, entspricht der Durchsatz der Abflugsrate des Systems, während analog dazu die Ankunftsrate zeigt, wie viele Arbeiten pro Zeiteinheit in das System gelangen. Ankunfts- und Abflugsrate sollten gleich sein, da sich bei einem Ungleichgewicht entweder die Arbeit staut oder das System leerläuft.
Messdaten gewinnen
WIP, Durchlaufzeit und Durchsatz sind in einem flussbasierten System nicht nur die wichtigsten Metriken, sie sind auch sehr einfach zu messen. Man braucht dafür lediglich Zeitstempel. Immer wenn ein Ticket in einen bestimmten Bereich bzw. in eine Aktivität (auf dem Kanban-Board sind das die einzelnen Spalten) gelangt, wird auf dem Ticket ein Zeitstempel, also das Datum vermerkt. Welche Zeiträume ergeben sich nun zwischen diesen Zeitstempeln?
Den ersten Zeitstempel bekommt ein Ticket, wenn es als Idee im Optionenpool abgelegt wird (s. Abb.2). Im Optionenpool befinden sich geplante Arbeiten, die noch nicht begonnen wurden und vielleicht auch noch verworfen werden. Den Zeitraum zwischen dem Eintreffen im Optionenpool und dem Übergang in die tatsächliche Ausführung (committeter Bereich) bezeichne ich als "initiale Wartezeit". Wenn mit der Arbeit an einer Arbeitseinheit begonnen wird und es somit in die Ausführung gelangt, erhält das Ticket den nächsten Zeitstempel. Die Zeitspanne zwischen diesem Bereich und dem Zeitpunkt des generierten Werts ist die "Ausführungszeit". Zusammen ergeben diese beiden Zeitspannen die Time-to-Market einer Option. Wenn die Unternehmen, mit denen ich arbeite, mit Kanban bzw. mit Metriken noch ganz am Anfang stehen, beginne ich mit dieser simpelsten Variante der Messung.
Single Item Forecast: Forecast für eine Arbeitseinheit
Sehen wir uns zunächst an, wie sich die Frage "Wann wird eine Arbeit fertig?" beantworten lässt. Es geht also darum, einen Forecast zur Durchlaufzeit einer Arbeit zu erstellen, und dazu empfiehlt es sich, im ersten Schritt die Messpunkte zu definieren. Die Durchlaufzeit kann für den gesamten Zeitraum zwischen dem Start einer Arbeit und deren tatsächlichem Abschluss (z. B. die Abnahme durch den Kunden) gemessen werden, natürlich ist aber auch die Dauer des Übergangs einer Arbeit zwischen zwei Aktivitäten als Durchlaufzeit zu bezeichnen. De facto ergibt sich für jedes Unternehmen eine andere Definition, man muss herausfinden, was im jeweiligen Kontext sinnvoll ist. Will man prognostizieren, wie lange es braucht, bis eine Arbeit aus dem Optionenpool bearbeitet wird? Dann wird die Durchlaufzeit auch die Wartezeit einer Arbeit zwischen dem Optionenpool und dem Beginn der Ausführung umfassen. Bevor man mit dem Messen beginnt, sollte in einem Kanban-System also definiert werden, wie sich die Durchlaufzeiten zusammensetzen und diese Definitionen sollten für alle jederzeit einsehbar sein.
Wichtig ist: Die Durchlaufzeit wird für jedes Ticket berechnet. Ein Ticket repräsentiert eine wertgenerierende Arbeitseinheit (also zum Beispiel ein Feature – im Gegensatz zum Task, das für sich alleine keinen Kundenwert generiert). Wenn Sie die Start- und Stopp-Punkte für Ihre individuell definierte Durchlaufzeit festgelegt haben, ist die Messung sehr einfach:
(Stopp – Start) + 1 = Durchlaufzeit
Was machen Sie nun mit diesen Durchlaufzeiten? Zunächst "sammeln" Sie diese Durchlaufzeiten und stellen Sie grafisch dar. Das funktioniert sehr gut mit einem Streudiagramm (Scatterplot) [7]. Sehen wir uns dazu das Beispiel in Abb.3 an. Die x-Achse ist ein Zeitstrahl, der den gewählten Zeiträumen entsprechend eingeteilt wird, in diesem Fall sind es Tage. Auf der y-Achse wird in diesem Beispiel die berechnete Durchlaufzeit pro Ticket in Tagen eingetragen. Wie wird das Streudiagramm erstellt?
Stellen wir uns folgende Situation auf einem Kanban-Board vor: In der "Done"-Spalte (= Wert generiert) hängt ein Ticket, das am 6.9. in den Optionenpool aufgenommen, am 11.9. in die Ausführung weitergezogen und am 11.9. als "Done" abgeschlossen wurde. Stopp-Datum minus Start-Datum + 1 ergibt also eine Durchlaufzeit von einem Tag, am Zeitstrahl wird daher am 11.9. ein Punkt bei der Durchlaufzeit "1 Tag" gemacht. Ein weiteres Ticket wurde am 3.9. begonnen und am 10.9. abgeschlossen (Durchlaufzeit: 8 Tage), ein anderes gelangte am 7.9. in die Ausführung und wurde ebenfalls am 10.9. abgeschlossen (Durchlaufzeit: 4 Tage). Für diese beiden Tickets werden am 10.9. auf der y-Achse also Punkte bei der Durchlaufzeit acht und vier Tage vermerkt usw.
Wenn das Streudiagramm über einen längeren Zeitraum konsequent mit Daten gefüttert wird, ergibt sich irgendwann eine Darstellung wie in Abb.4. Das Streudiagramm zeigt, dass die Durchlaufzeiten hochvariabel sind: Manche Arbeiten werden innerhalb eines Tages fertig, andere brauchen 30 Tage. Wie kann man trotz dieser hohen Variabilität vorhersagen, wann eine neu begonnene Arbeit fertig wird? Dazu ist es notwendig, im Streudiagramm sogenannte Quantile einzuzeichnen.
Terminzusagen anhand von Quantilen
Für Terminzusagen sollte nie der Durchschnitt verwendet werden, das ergibt sich schon durch die Definition des Durchschnitts. Wer den Durchschnitt für einen Forecast verwendet (genauer gesagt den Median), wird in 50 Prozent der Fälle den Termin nicht einhalten – man könnte also gleich eine Münze werfen [8].
Will man Aussagen treffen, die mit einer höheren Wahrscheinlichkeit als 50 Prozent eintreffen, sollte man daher in Quantilen denken. Quantile sind Lagemaße bzw. Schwellenwerte, d. h. ein bestimmter Anteil der Werte ist kleiner als das Quantil, der Rest ist größer. Will man zum Beispiel Aussagen mit einer 80-prozentigen Eintrittswahrscheinlichkeit treffen, würde das übersetzt lauten: In acht von zehn Fällen wird der Termin eingehalten. Um zum Beispiel das 85-Prozent-Quantil in einem Streudiagramm zu bestimmen, müssen wir eine horizontale Linie auf der x-Achse finden, unter der 85 Prozent der Messpunkte liegen. In Abb.4 findet man diese Linie bei einer Durchlaufzeit von 11 Tagen: 85 Prozent der Durchlaufzeiten liegen unter 11 Tagen, 15 Prozent liegen darüber.
Quantile sind eine hervorragende Unterstützung in der Kommunikation mit dem Kunden. Wenn ein Kunde fragt, wann eine neue Arbeitseinheit fertiggestellt wird, kann man in diesem Fall mit einer Sicherheit von 85 Prozent sagen: "Innerhalb von 11 Tagen". Wenn dieser Grad an Sicherheit nicht groß genug ist und stattdessen eine Sicherheit von 95 Prozent gefragt ist, muss eben das 95-Prozent-Quantil kommuniziert werden, das im Beispiel von Abb.4 bei 17 Tagen liegt. Ich empfehle, je nach Grad der Sicherheit das Quantil und die Durchlaufzeit am Kanban-Board sichtbar zu machen. Somit sehen alle Stakeholder die aktuelle Leistung des Systems. Diesen Leistungsindikator nennt man Service Level Agreement (SLA) oder Dienstgütevereinbarung. Service Level Agreements werden häufig so vereinbart: Ein Manager öffnet eine Datei namens SLA.txt und schreibt dort seine Wunschvorstellungen hinein, wann welche Arbeitstypen fertig werden sollen. Man muss sich dann nicht wundern, wenn das SLA verletzt wird. Ein Service Level Agreement muss immer die aktuelle Leistungsfähigkeit des Systems repräsentieren und nicht einen unerfüllbaren Wunsch. Zusätzlich ist die Entwicklung des SLA im Zeitverlauf ein guter Feedback-Mechanismus für das Kanban-System – wird die Leistung des Systems besser, schlechter oder bleibt sie gleich?
Forecast für mehrere Arbeiten: Kontinuierliches Durchsatz-Forecasting
Nun gelangt meistens nicht nur eine Arbeit in ein System, sondern gleich mehrere. Dann lautet die Frage zum Beispiel: "Wann sind diese 20 Features fertig oder wie viele Features schafft ihr in den nächsten fünf Wochen?" Wie kann man einen Forecast für diesen Fall erstellen?
Die Realität erlaubt immer genauere Aussagen über die Fertigstellung. Diese Realität fließt in ein kontinuierliches Forecasting ein, das zum begleitenden Instrument der Umsetzungsarbeit wird. Mit den Ergebnissen lässt sich eine tatsachenbasierte Diskussion darüber führen, an welchem Punkt man im Prozess gerade steht und welche Maßnahmen gegebenenfalls ergriffen werden müssen. Das bedeutet auch, dass sehr früh deutlich wird, ob ein Projekt die Möglichkeiten übersteigt und abgebrochen werden muss.
In dieser Situation steckten auch neun Scrum-Teams, in deren Backlog im Rahmen einer Produktentwicklung 297 Storys lagerten. Ein mittlerweile in die Jahre gekommenes Produkt sollte durch eine neue Technologie ersetzt werden und der Product Owner hatte sich offensichtlich eingehend Gedanken darüber gemacht, wie das Produkt umzusetzen sei. Natürlich lautete seine Frage nun: "Wie lange dauert das noch?" Basierend auf bisherigen Performance-Daten der Teams, wurde ein erster Forecast erstellt, der prognostizierte, dass die 297 Storys in 38 Wochen abgearbeitet sein würden. Forecasting ist keine einmalige Angelegenheit, daher machten wir uns daran, dieses Projekt mit einem kontinuierlichen Forecast zu begleiten. Wanderte eine Story aus dem Optionenpool in die "Next"-Spalte am Board der Teams (Zeitpunkt des Commitments), bekam sie einen Start-Zeitstempel und einen Stopp-Zeitstempel erhielt sie, wenn sie abgeschlossen wurde. Mit diesen beiden Zeitstempeln konnte der wöchentliche Durchsatz des Kanban-Arbeitssystems berechnet werden.
Der Durchsatz ist die Anzahl der Tickets, die innerhalb eines bestimmten Zeitraums in der "Done"-Spalte landen. Die Messung ist sehr einfach: Bei einem Wochenrhythmus zählt man am Ende der Woche einfach durch, wie viele Arbeitseinheiten in dieser Kalenderwoche fertiggestellt wurden. Das Ergebnis wird wiederum in einem Chart eingetragen – die y-Achse umfasst die Anzahl der Arbeitseinheiten, die x-Achse ist ein Zeitstrahl. Wird zum Beispiel im Rahmen eines Projekts ein fixes Backlog abgearbeitet, kann man auch das im Chart eintragen und dann verfolgen, ob und in welchem Umfang sich das Backlog im Zeitablauf verkleinert (Burn-up-Chart). Im Beispiel der 297 Storys wurde in den ersten Wochen die Zahl der fertigen Storys gezählt und kumuliert in einem Burn-up-Chart eingetragen (s. Abb.5, dicke schwarze Linie links unten).
Ganz oben im Burn-up-Chart ist eine horizontale Linie zu sehen, die die Entwicklung des Backlogs im Laufe der Zeit anzeigt. Wir waren mit 297 Storys gestartet und wie sich ablesen lässt, hat sich in den ersten drei Wochen auch nichts daran geändert. In Woche vier springt das Backlog plötzlich auf 300 Storys, in Woche fünf sogar auf 304. Offensichtlich wurden neue Storys ins Backlog gestellt und das bedeutete, dass der bisherige Forecast nun nicht mehr zutraf. Ich sehe in Unternehmen oft, dass bei solchen Brüchen die zukünftige Entwicklung des Backlogs einfach anhand des durchschnittlichen Durchsatzes prognostiziert wird, unter der Annahme, dass das Backlog konstant bleibt. Im konkreten Beispiel würden also durchschnittlich 6,4 Storys pro Woche abgearbeitet werden und nach etwa 47 Wochen wäre das Backlog leer. Allerdings: Der Durchschnitt ist nur ein mögliches Resultat, es gibt noch viele andere.
Da wir bereits Durchsatzdaten aus den ersten fünf Wochen hatten (wie in Abb.5 eingezeichnet), konnten wir eine Min-Max-Rechnung anstellen: Würden wir das Maximum von 15 Storys pro Woche schaffen, wäre das Backlog in Woche 24 abgearbeitet gewesen. Würden wir hingegen nur das bisherige Minimum von zwei Storys pro Woche schaffen, wäre das neue System erst in Woche 141 fertig gewesen. In diesem Raum zwischen Minimum und Maximum gab es viele verschiedene Kombinationen. Eine lineare Projektion des Durchschnitts würde also sehr wahrscheinlich nichts darüber aussagen, wann das Projekt tatsächlich abgeschlossen sein würde. Daher war es angebracht, anhand des realen Durchsatzes der ersten fünf Wochen, mit Hilfe von Excel eine Monte-Carlo-Simulation durchzuführen (Abb.6).
Was ist eine Monte-Carlo-Simulation?
Zwischen Minimum und Maximum eines bekannten Zahlenbereichs gibt es Ergebnisse, die wahrscheinlicher sind als andere. Eine Monte-Carlo-Simulation führt für ein definiertes Modell anhand von Zufallszahlen innerhalb dieses möglichen Zahlenbereichs mehrere Simulationsdurchgänge durch und berechnet die Ergebnisse. So kann die Verteilung möglicher Resultate und deren Eintrittshäufigkeit ermittelt werden [9].
Unter der Annahme (die wir für alle explizit machten), dass das Backlog von nun an konstant bleiben würde, ergab die Simulation, dass vom gegenwärtigen Zeitpunkt aus betrachtet die schnellste Fertigstellung mindestens 33 Wochen und die langsamste Variante maximal 66 Wochen dauern würde.
Am wahrscheinlichsten schien bei einem schnellen Blick auf das Histogramm die Fertigstellung in 45 bis 55 Wochen. Da wir es genauer wissen wollten, setzten wir Quantile. Im konkreten Fall wollten wir im Forecast eine Wahrscheinlichkeit von 85 Prozent haben und diese lag bei etwa 52 Wochen: Mit einer Wahrscheinlichkeit von 85 Prozent würde das Backlog nach 52 Wochen abgearbeitet sein. Was konnten wir nun aus diesem Forecast ablesen?
Beim ersten Forecast waren die Teams zu dem Schluss gekommen, dass sie 38 Wochen brauchen würden, um das Backlog abzuarbeiten. Zwischen diesem ursprünglichen Forecast und der aktuellen Performance klaffte eine ziemliche Lücke, denn nun lagen auch noch mehr User Storys im Backlog als zu Beginn (304 statt 297). Zwar machten diese sieben Storys das Kraut nicht fett, aber Tatsache war, dass nach den ursprünglich prognostizierten 38 Wochen noch 84 User Storys fehlen würden, um das Projekt abschließen zu können. Der wichtigste Schritt war nun, diese Daten (vorwurfsfrei) zu diskutieren, zu interpretieren und zu überlegen, welche Maßnahmen gesetzt werden sollten:
- Stoppen wir das Projekt?
- Brauchen wir zusätzliche Mitarbeiter?
- Nehmen wir es in Kauf?
- Informieren wir den Kunden?
- Es ist momentan so, aber es kann sich ändern. Die Teams mussten sich erst warmlaufen und man sieht die Steigerung von Woche zu Woche. Wir beobachten die Entwicklung noch drei bis vier Wochen und sehen es uns dann wieder an.
Die Forecasts wurden jede Woche mit den neuen Daten aktualisiert. Nach zehn Wochen trafen wir uns wieder in einer größeren Runde, um zu diskutieren, wie sich die Lage entwickelt hatte und ob besondere Maßnahmen notwendig waren. Das Backlog war tatsächlich konstant bei 304 User Storys geblieben und auch der Durchsatz hatte sich auf einem höheren Niveau eingependelt:
Woche 6: 13
Woche 7: 6
Woche 8: 12
Woche 9: 8
Woche 10: 9
Wir wiederholten die Monte-Carlo-Simulation, um über etwaige Maßnahmen entscheiden zu können (Abb.7). Minimum und Maximum lagen nun bei 30 und 52 Wochen. Mit einer 85-prozentigen Wahrscheinlichkeit würde das Projekt in 41 Wochen abgeschlossen sein. Das klang schon viel besser als noch vor fünf Wochen. Zwar hatte der ursprüngliche Forecast 38 Wochen prognostiziert, aber das war kein Grund, nervös zu werden. Nach den aktuellen Messungen würden dann noch 26 Storys abzuarbeiten sein und das war zu verkraften. Die Interpretation fiel dieses Mal eindeutig aus: Die Unsicherheit wird kleiner und das Resultat wahrscheinlicher – wir kommen dem Ziel näher.
Fazit
Antworten auf die Frage "Wann ist es fertig?" sind also keine einmaligen, in Stein gemeißelten Aussagen, sondern kontinuierliche Annäherungen. Beim Blick in die Zukunft gibt es immer mehr als ein Resultat, daher ist es absurd, Durchschnitte in die Zukunft zu prognostizieren und sich auf ein einziges Ergebnis festzulegen. Natürlich, Kunden reagieren wahrscheinlich erstaunt, wenn man ihnen auf die Fertig-Frage die Verteilung aller möglichen Fertigstellungstermine vorlegt. Daher ist es im Rahmen des Forecastings wichtig, die Frage zu stellen:
"Mit welcher Wahrscheinlichkeit können wir gut leben?"
- N. N. Taleb, 2012: Antifragilität. Anleitung für eine Welt, die wir nicht verstehen. Albrecht Knaus Verlag
- K. Leopold, S. Kaltenecker, 2013: Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen. 2. Aufl. Hanser Verlag
- Wikipedia: Schmetterlingseffekt
- Wikiquote: Richard Feynman: The Character of Physical Law (1965)
- Das Agile Manifest
- Troy Magennis – focusedobjective.com: Calendar Days vs Work Days (Storing and using cycle time data)
- D. Vacanti, 2015: Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vacanti, Inc.
- S. L. Savage, 2012: The Flaw of Averages. Why We Underestimate Risk in the Face of Uncertainty. Wiley
- Wikipedia: Monte-Carlo-Simulation
Vorlagen für Monte-Carlo-Simulationen
