Die Idee von #NoEstimates

Eine Einführung in #NoEstimates

Die vermutlich kontroverseste unter den agilen Bewegungen feierte vor kurzem einen runden Geburtstag: #NoEstimates wurde 10 Jahre alt. Lange nachdem sie in den Jahren 2011 und 2012 durch eine Reihe von Blogartikeln und Konferenzvorträgen ins Leben gerufen wurde, ist sie noch immer weit vom Mainstream entfernt und wird dort auch wegen des für viele Manager provozierenden Namens in absehbarer Zeit nicht ankommen. Da #NoEstimates (auf Deutsch: #KeineAufwandsschätzungen) aber viele leidenschaftliche Anhänger und Verfechter kennt, ist davon auszugehen, dass die Bewegung in ihrer Nische noch lange weiterbestehen wird, zumal auch andere Bereiche die Idee inzwischen aufgegriffen haben.

#NoEstimates als Antwort auf WAG

Um die Idee von #NoEstimates zu verstehen, muss man sich eines bewusst machen: trotz ihres Namens wendet sich die Bewegung nicht explizit gegen jegliche Aufwandsschätzungen. Sie adressiert Vorhaben, die sich so unvorhersehbar entwickeln, dass nützliche Schätzungen durch wildes Herumraten substituiert werden. Woody Zuill, einer der Vordenker von #NoEstimates bezeichnete das im November 2011 in seinem Artikel “Estimate a Game of Chess”¹ als “Wild Ass Guessing” (WAG), was inhaltlich deckungsgleich mit “wildem Herumraten” ist.

In der gelebten Praxis von Organisationen gibt es immer wieder Vorhaben, in denen Rahmenbedingungen vorliegen, die eine realistische Schätzung nahezu unmöglich machen. Ein Beispiel ist die Entwicklung eines neuartigen Online-Produkts, bei dem die intensiv genutzten neuen Features kontinuierlich weiterentwickelt, die weniger genutzten hingegen später ausgebaut werden sollen. Ein anderes ist die Reparatur eines uralten Systems mit hunderten von noch unentdeckten Bugs.²

Jeder Versuch diese oder ähnliche Projekte mit Aufwandsschätzungen zu versehen, endet lediglich in einem Haufen Datenmüll, da die Wissensgrundlage, auf der die Aufwandsschätzungen stattfindet, ständig wegbricht und sich in veränderter Form neu bildet. Verhindern lässt sich das nicht, schließlich lassen sich weder die Nutzungsintensität eines noch nicht gebauten Features, noch der Reparaturaufwand eines noch nicht genau analysierten Bugs voraussagen. Und derartige Beispiele gibt es viele.

Aufwandsschätzungen als Antipattern

Es ist aber nicht nur so, dass Aufwandsschätzungen in den beschriebenen Beispielen keinen Mehrwert bringen, sie können sogar schädliche Auswirkungen haben. Am offensichtlichsten dadurch, dass die für sie aufgewendete Zeit nicht mehr in die Umsetzung fließen kann, aber auch durch zunehmenden Verwaltungsaufwand – verfehlte Schätzungen führen in vielen Organisationen zu Korrekturversuchen in Form von noch mehr Schätzungen, Planung und Reporting, was nochmal mehr Arbeitszeit bindet.

Selbst das wird in vielen Firmen noch gesteigert durch die Art des Umgangs mit nicht zutreffenden Schätzungen (und zwar auch dann, wenn es sich um eigentlich unschätzbare Sachverhalte handelt). Dort, wo jeder, der sich “verschätzt” öffentlich bloßgestellt wird oder Karrierenachteile erfährt, entstehen oft unnötig hohe “Schutz-Schätzungen”. Oftmals lässt sich auch beobachten, dass Mehraufwände in Form von Bug Backlogs oder technischen Schulden in die Zukunft verschoben werden, wo sie in den unpassendsten Momenten akut auftreten.

Am Ende verkehrt sich die Auswirkung der Aufwandsschätzungen in das Gegenteil des gewünschten: statt Arbeitsprozesse und Planungen

• strukturierter,
• stabiler und
• berechenbarer zu machen,

werden sie

• bürokratischer,
• fehleranfälliger und
• unberechenbarer.

Dieses Phänomen (die Destabilisierung eines Systems durch Erzwingung von Aufwandsschätzungen an unpassenden Stellen) nennt Vasco Duarte, einer der anderen #NoEstimates-Vordenker “Borrowed Fragility”.³

Zielführender ist es in einem solchen Szenario, einfach so lange weiterzuarbeiten, bis das Ziel erreicht ist, etwa bis zur Marktsättigung oder -positionierung (im Fall einer volatilen Produktentwicklung) oder bis alle wesentlichen Bugs und Performance-Probleme der kritischen Systeme behoben sind (im Fall der Reparaturarbeiten am Altsystem). Natürlich nur im Rahmen eines verfügbaren Budgets, das aber bis zur Zielerreichung (oder bis zur Re-Priorisierung) immer wieder verlängert werden kann.

#NoEstimates im Kleinen wie im Großen?

Wichtig bei diesem aus klassischer Management-Sicht beunruhigenden Bild ist, dass es die Zustände auf globaler Ebene beschreibt, es geht also um ganze Projekte oder Produkte. Auf der Umsetzungsebene, wo die Arbeitspakete viel kleiner heruntergebrochen sind, stellt sich die Frage erneut – sind wenigstens hier Aufwandsschätzungen möglich? Die Antwort: Ja, aber (im Rahmen von #NoEstimates) anders als man zunächst denken würde.

Das Problem der Abschätzung tritt auch auf der operativen Ebene auf. Selbst bei relativ kleinen Arbeitspaketen lässt sich nicht zuverlässig schätzen, wie viel Zeit sie in der Umsetzung benötigen werden, auch dann nicht, wenn sie so weit heruntergebrochen werden, dass sie (vermutlich) in Sprints, Wochen oder Monate passen. Ob es am Ende fünf Tage dauern wird, vier oder sieben, lässt sich nicht seriös sagen, auch hier ist die Unklarheit zu groß.

Was sich bei derartig kleinen Aufgaben aber (für nicht alle, aber die meisten Fälle) sagen lässt, ist lediglich, ob sie überhaupt in einen Sprint oder Monat passen. In der Regel sind die Arbeitspakete auf dieser Ebene nur einige Tage in der Umsetzung, bei einem Lieferzyklus von 14 bis 20 Arbeitstagen kann man also ziemlich sicher sein, dass die Fertigstellung rechtzeitig erfolgt, und sogar noch Zeit für weitere Arbeiten übriglässt. Diese Erkenntnis wurde im Januar 2012 von Vasco Duarte in #NoEstimates eingebracht.⁴

Der Schlüssel zu mehr Planbarkeit liegt in einer leichten Einschränkung der Grundidee: statt gar keine Schätzungen zu machen, gibt es lediglich keine Schätzungen unterhalb einer bestimmten Granularität. Wie im letzten Absatz beschrieben, kann das bedeuten, dass das Umsetzungsteam nur gefragt wird, ob eine Aufgabe überhaupt in einen Sprint passt. Für die sich daraus ergebenden drei Möglichkeiten

• Ja,
• Nein und
• keine Ahnung

gibt es sogar eigene Planning Poker-Karten.⁵

Die Planbarkeit ergibt sich aus den an dieser Stelle doch möglichen Erfahrungswerten. Bei einem gleichbleibenden Umsetzungsteam und einer gleichbleibenden Technologie liegen zwei stabilisierende Faktoren vor, die bei verschiedenen Projekten oder Produkten in der Regel fehlen, sodass die durchschnittliche Menge, der in den letzten Sprints geschafften Arbeitspakete (der Durchsatz, bzw. Throughput) in der Regel auch dem entspricht, was im nächsten realistisch machbar ist.

Als Nebeneffekt ist diese Variante der (Nicht-)Schätzung und Planung auch weniger manipulierbar als andere. Während Teams häufig unter Druck gesetzt werden, ihre Stunden- oder Story-Point-Schätzungen “optimistischer” zu gestalten, ist das bei dieser gröberen Schätzung im geringeren Maße möglich. Und der Durchschnittswert der in der Vergangenheit fertiggestellten Arbeit, ist nicht manipulierbar, wenn man keine offensichtliche “Geschichtsfälschung” begehen will.

Fazit

Ohne stabile Wissensgrundlage ist es kontraproduktiv, Aufwandsschätzungen durchzuführen. Die Idee von #NoEstimates adressiert Vorhaben, in denen Aufwandsschätzungen keinen Mehrwert bringen und stattdessen das Potenzial haben, Schaden anzurichten, weshalb man sie besser ganz lassen sollte. 

Interessanterweise findet sich der Ansatz, ohne Aufwandsschätzungen zu agieren und Planungen auf dem Durchsatz der jüngeren Vergangenheit basieren zu lassen, mittlerweile auch fernab von #NoEstimates wieder, unter anderem bei

• Ron Jeffries, einem Mit-Erfinder von Extreme Programming,⁶
• bei Troy Magennis, einem der bekanntesten Vertreter von agilem Forecasting⁷ und
• sogar bei SAFe.⁸

In gewisser Weise hat es #NoEstimates doch in den (agilen) Mainstream geschafft, wenn auch ohne ihre provozierende Benennung. Letztendlich ist diese aber auch weniger wichtig als die Idee dahinter, sodass das ein akzeptabler Preis sein dürfte.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Natürlich gibt es noch eine andere, destruktive Art von “No Estimates”, bei der es sich um die grundlegende Verweigerung aller Aufwandsschätzungen handelt, also auch dann, wenn sie möglich oder sinnvoll wären. Zur Abgrenzung davon erfolgt die Schreibweise seit 2012 in einem Wort und mit Hashtag.

[1] Estimation is Easy and Useful: Estimate a game of Chess
[2] No Estimate Approach For End-Of-Life Legacy Support
[3] Borrowed Fragility
[4] Story Points Considered Harmful – Or why the future of estimation is really in our past…
[5] Planning Poker Karten
[6] Some Thoughts on Estimation
[7] Story Point Velocity or Throughput Forecasting – Does it matter?
[8] SAFe: Estimating Work

Felix Stein veröffentlicht regelmäßig Beiträge in dem zurecht sehr bekannten und beliebten Blog On Lean and Agility. Definitiv mehr als einen Besuch wert!

Felix Stein hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.