To guess or not to guess – Meine Meinung zu „No Estimates“

Egal, ob es um den pünktlichen Abschluss eines Softwareprojektes oder um die Kosten geht, es gibt viele Situationen, in denen Schätzungen abgegeben werden. Ich denke, man sollte Entscheidungen in Softwareprojekten nicht basierend auf Schätzungen treffen. Welche Alternativen es gibt, erkläre ich euch.

Werden wir pünktlich liefern?

Das ist eine der Schlüsselfragen, die einem Entwicklerteam zu Beginn und während eines Projektes immer wieder gestellt wird. Und diese Frage ist der Hauptgrund, weshalb viele Menschen glauben, schätzen zu müssen. Fragwürdig daran ist, dass man eine verlässliche Vorhersage erhalten möchte, indem Schätzungen aufgrund von Vermutungen abgeben werden. Wir wissen alle oder zumindest vermuten wir, dass diese Zahlen in der Regel frei ausgedacht sind. Bestenfalls basieren sie auf Erfahrungen mit ähnlichen, aber niemals identischen Projekten. Fakt ist meistens, dass man die aktuelle Lösung bislang noch nicht kennt oder nicht versteht. Man versucht sich zu beruhigen, indem man die Schätzungen als „educated guess“ oder als „quick and dirty“ bezeichnet. Das Ganze nur, um rechtfertigen zu können, dass man aufgrund von Vermutungen wichtige Entscheidungen trifft.

Software zu entwickeln ist naturgemäss unvorhersehbar und nicht repetitiv. Wenn Software entwickelt wird, können Developer ihre Arbeit nicht einfach in immer gleiche, sich wiederholende Einheiten runterbrechen, so wie es etwa beim Zusammenbau eines Stuhls der Fall ist. Anders als beim Stuhl ist das genaue Endprodukt bei Software unbekannt. Ein „Software-Fertigungsteil“ ist nicht identisch zum nächsten. Softwareentwicklung ist ein kreativer sowie variabler Prozess und Lösungen zeigen sich oft erst während der Entwicklung. Deshalb ist es auch sehr schwierig, den Scope eines Entwicklungsprojekts exakt zu fixieren. Wenn man akzeptiert, dass der Scope variabel sein muss, um „emergent design“ und sich ändernde Anforderungen zu berücksichtigen, dann muss auch akzeptiert werden, dass das „Lieferdatum“ ebenfalls eine Variable ist. Es wird versucht, diese zu erreichen, während der bekannte Scope „on time“ und „on budget“ geliefert wird.

Basieren „on time“ und „on budget“ auf Schätzungen, dann sollte es stimmen, dass es länger dauern kann als ursprünglich geschätzt, um die Software zu entwickeln. Allerdings kann die Fertigstellung auch schneller erfolgen oder eben im Rahmen der Schätzung bleiben.

Letzen Endes muss man sich jedoch fragen, ob die Korrektheit einer Schätzung wirklich relevant war. Hat unsere Schätzung irgendeinen positiven oder negativen Einfluss auf die Qualität der Entwicklung oder auf ihren ROI?

Die Vision ist entscheidend

Um Software zu entwickeln, braucht man eine klare Vision und ein gemeinsames Verständnis davon, wie Erfolg aussehen soll. Wenn ein Softwareprojekt beginnt, werden zunächst gut durchdachte High-Level-Ziele benötigt. Details, wie diese Ziele erreicht werden, sind erstmal zweitrangig. In einer klassisch iterativen Vorgehensweise können dann „just-in-time“ Entscheidungen getroffen werden, wie das Produkt in der nächsten Iteration verbessert werden kann (Backlog grooming).

Ich unterstelle nun folgendes: Der Versuch, aufgrund von Schätzungen vorherzusagen, wie lange es dauern wird, Software zu entwickeln, um die High-Level-Ziele zu erreichen, ist ein fragwürdiger Ansatz. Man möchte doch, dass die Lösungen und die Architektur während der Entwicklung entstehen. Man möchte doch Änderungen in den Anforderungen, während sich das Produkt entwickelt, um dem Kunden einen Vorteil zu bieten. Diese Flexibilität lässt sich per Definition nicht im Vorfeld fixieren. Dies sind Schlüsselelemente aus dem agilen Manifest und ich glaube, dass sie elementar sind für einen wirklich agilen Ansatz in der Softwareentwicklung.

Entferne die Unbekannten

Anstatt sich auf die Genauigkeit von Schätzungen für Vorhersagen zu verlassen, kann man auch versuchen die unbekannten Kosten und Due Dates zu eliminieren, indem man sie explizit macht. Der Product Owner kann zum Beispiel das Due Date anhand einer konkreten budgetären oder zeitlichen Beschränkung festlegen. Zum Beispiel: Drei Tage vor Weihnachten ist für eine Weihnachts-App eine konkrete zeitliche Beschränkung. Ebenso eine Aussage wie: „Wir haben Betrag X, lasst uns damit das bestmögliche Ergebnis erzielen.“

Innerhalb dieser Grenzen kann das Team Lieferzeitpunkte definieren – beispielsweise am Ende eines Sprints. Damit wird die notwendige Fokussierung auf iterative Produktentwicklung erzielt. Gleichzeitig besteht die Möglichkeit, früher und/oder billiger zu liefern. Dieser Ansatz ist ebenfalls nützlich, wenn keine konkreten budgetären oder zeitlichen Grenzen existieren. Die Notwendigkeit für explizit benannte Zwischenreleases nimmt ab, je reifer ein Team im Umgang mit Continous-Delivery-Methoden ist.

„Sprint velocity“ zu schätzen ist Verschwendung (waste)

Eine Lösung bereits zu Beginn vorzugeben (was notwendig ist um eine Schätzung zur Dauer zu geben) oder für jeden Sprint vorherzusagen (so werden viele Story Points oder Stories erledigt) scheint mir wenig sinnvoll. Teams sollten sich einfach nur dazu verpflichten, das bestmögliche Produkt innerhalb einer gegebenen Zeit und zu einem gegebenen Budget zu entwickeln. Wenn man schätzt und dabei die „Velocity“ zur Planung nutzt, trifft man eine Annahme, wie viel innerhalb einer gegebenen Periode geschafft werden kann. Damit diese Information nützlich ist, muss man bereits wissen was insgesamt geschafft werden soll. Das heißt, es muss also ein vollständig geschätztes Product Backlog zur Verfügung stehen. Ich glaube, es ist keine zu abwegige Unterstellung, dass die gesamte Zeit, die benötigt wird, um Backlog Items zu schätzen, die dann gar nicht entwickelt werden, als „waste“ im Sinne von Lean betrachtet werden kann.

Aber was ist mit der Zeit die verwendet wird, um Backlog Items zu schätzen, die tatsächlich entwickelt werden? Um diese Frage zu beantworten, stelle ich eine weitere Frage: Kennt ihr einen Product Owner, der jemals aufgrund geringerer Story Points (geschätzte Kosten) eine Story höher priorisiert hat als eine andere? Wenn die Antwort auf diese Frage „Nein“ ist, dann schliesse ich daraus, dass das gesamte Schätzen in diesem Kontext „waste“ war. Denn keine Entscheidung wurde basierend auf der Schätzung getroffen. Stattdessen hat der Product Owner einfach die Story mit dem höchsten Nutzen priorisiert.

Wenn die Antwort allerdings „Ja“ ist, dann wurden Kostenschätzungen als Grundlage für Entscheidungen herangezogen, die eigentlich aufgrund eines Nutzens hätten getroffen werden müssen. Das Backlog im Vorfeld zu schätzen und dann den Lieferzeitpunkt auf der „Velocity“ basierend zu planen, ist ein auf Kosten basierender Ansatz.

Ausprobieren, nicht schätzen

Ich glaube, dass eine iterative (agile) Entwicklung auf Entscheidungen hinsichtlich des Kunden-und/oder Businessnutzen beruht, die Empirie über Schätzungen stellen. Die Kosten in einem solchen Szenario sollen fixiert werden, indem man ein Team konstant hält und den Zeitrahmen (häufige, vorhersehbare Lieferzeitpunkte anstelle von „Deadlines“) explizit macht. Wenn man die Kosten und Lieferzeitpunkte kennt, hat man Sicherheit. Diese Sicherheit erlaubt es, bei der Entwicklung Spielraum für ein agiles Mindset zu haben. Im Übrigen ist ein fester Lieferzeitpunkt nicht gleichbedeutend damit, dass man an diesem Punkt aufhört das Produkt weiterzuentwickeln. Es kann sein, dass man zu diesem Zeitpunkt bereits fertig ist oder sich entscheidet, weiter daran zu arbeiten. Wichtig ist nur, dass man kontinuierlich Go- sowie No-Go-Entscheidungen trifft und zwar basierend auf dem realisierten oder dem potenziellen Nutzen dessen, was gerade entwickelt wird. Nicht auf Basis der geschätzten Kosten einer spezifischen Lösung.

Wie viele Stories oder Punkte je Sprint geliefert werden, ist unwichtig, wenn das Team in der Lage ist, möglichst schnell Weiterentwicklungen und Verbesserungen am Produkt an den Nutzer zu liefern. Dies ist in meinen Augen der Grund, weshalb Softwareprojekte und ganze Unternehmen versuchen, ein agiles Mindset an den Tag zu legen.

So lange man jedoch weiter den Zwang sieht zu schätzen, wird man vermutlich immer ein wenig zurückgehalten in dem Streben, dem Kunden wirklich herausragende Software zu liefern.