NoEstimates – Kunden ohne Schätzungen glücklich machen

NoEstimates?

Immer häufiger liest man von einer neuen Bewegung, die allerdings nirgends so richtig erklärt wird. Das liegt augenscheinlich daran, dass es eine emergente Strömung ohne formale Organisation ist. Der wohl präsenteste Verfechter von NoEstimates ist Woody Zuill. In seinem Blog und seinen Vorträgen vertritt er radikal die Ansicht, dass keine Zeitschätzungen von Entwicklerteams gemacht werden sollten. Allerdings wirkt seine extreme Position in Verbindung mit den selbstgemalten Einhörnern auf seinen Slides und dem Leitsatz „I like to imagine wonderful“ etwas weltfremd. Aus der Sicht eines Dienstleisters wirken die Vorschläge eher praxisfern, fehlendes Kundenvertrauen einfach durch Finden besserer Kunden zu lösen. Eine weitere Prämisse ist, dass ein Team in der Lage sein sollte, so schnell Wert für den Kunden zu liefern, dass dieser nicht mehr den Drang verspürt, nach Schätzungen zu fragen. Woodys finnischer Sparringspartner Vasco Duarte vertritt in seinem Buch realitätsnähere Ansichten und gibt praktische Ansätze, wie die negativen Aspekte des Schätzens reduziert werden können.

Darüber hinaus gibt es eine ganze Reihe von Stimmen, die sich der Bewegung anschließen, allerdings liefert auch hier niemand fertige Lösungen. Das kann bedeuten, dass noch keine existieren, oder dass diejenigen, die erfolgreiche Erfahrungen haben, diese als taktischen Wettbewerbsvorteil zurückhalten.

Schätzungen im Dienste der Softwareentwicklung

Kunden möchten Entscheidungen auf Basis des zu erwartenden Aufwands treffen. Dienstleister werden beschäftigt, wo die eigenen Kernkompetenzen nicht hinreichen. Daher ist das subjektive Gefühl, die komplexe Problemdomäne zu beherrschen besser, wenn der Experte eine Schätzung zur Verfügung stellt, als wenn der Kunde selbst den Business Value bestimmen muss. In Folge braucht ein Dienstleister die Schätzungen, um Kunden zu gewinnen, besonders Neukunden. Der Fokus der Entscheidungen liegt dabei dann allerdings nicht auf Qualität und Wert, sondern auf Aufwand und Kosten. Ist die Entscheidung dann getroffen, wird die Abarbeitung in Folge ebenfalls auf die Schätzung ausgerichtet und nicht darauf, den größtmöglichen Wert zu schaffen.

Damit ergibt sich eine paradoxe Situation – Schätzungen werden per se vom Kunden angezweifelt und als Verhandlungsmasse betrachtet, dadurch verlieren die ehrlicheren, genaueren Schätzungen – entweder kann nicht nachgegeben werden, oder aber das Endergebnis ist nicht haltbar. Schlechte Erfahrungen auf Seiten des Dienstleisters führen damit zu vorsichtigeren Schätzungen, sogar die für Schätzungen selbst verwendete Zeit steigt dadurch an, da sich der Programmierer im vorab festlegen muss, wie lang er für eine Aufgabe braucht. Ergibt sich allerdings ein Auftrag, der mit mehr als ausreichend Puffer versehen ist, schlägt Parkinsons Law zu – praktisch jede Aufgabe dehnt sich auf die eine oder andere Art aus bis die zur Verfügung stehende Zeit ausgeschöpft wird.

Auch wenn die Schätzung nicht pauschal angezweifelt wird, gibt es verschiedene Muster, die dafür sorgen, dass ein Zeit- und Kostenplan nicht gehalten werden kann: Scope oder Feature Creep, also nachgeschobene Erweiterungen der Aufgabe, sowie Marktentwicklung in der Businessdomäne verfälschen die vorab geschätzten Arbeitspakete.

Durch die resultierende niedrige Qualität werden Schätzungen von Kritikern auch gern als Zeitverschwendung oder Ersatzhandlung (Yak-Shaving) betrachtet. Besonders im Dienstleistungsbereich kann es durchaus vorkommen, dass der Aufwand für Schätzungen an den tatsächlichen Umsetzungsaufwand herankommt oder ihn sogar übersteigt. Nicht ganz zu Unrecht möchten viele Teams deshalb die Zeit, die in Schätzungen investiert werden muss, viel lieber dafür verwenden, die eigentlichen Probleme anzugehen.

Andererseits sind Schätzungen auch ein Aufhänger für die Erforschung der Domäne: Unbekannte werden so erkannt, Risiken identifiziert und das beteiligte Team erhält kollektiv Wissen über die Problemstellungen. Durch die gemeinsame Arbeit am Thema kann man auch die Einzelnen Teammitglieder motivieren und verhindern, dass einzelne abgehängt werden, oder das restliche Team abhängen. Wird das sinnvoll in die Projektarbeit integriert und dem Auftraggeber gegenüber gut erklärt, sinkt auch die Erwartung, dass Schätzungen als vorbereitende Maßnahme nicht in der abgerechneten Zeit zu erledigen sind.

Hat man auf diese Weise über Schätzungen das Risikomanagement und die grobe Marschrichtung unter Dach und Fach gebracht, kann man Abweichungen vom erwarteten Ergebnis nutzen, um Fehler im Prozess aufzudecken, anstatt über Schuld und Verantwortlichkeit zu streiten.

Ein Teil dessen, was einen Programmierexperten von einem Anfänger unterscheidet ist, dass der Experte recht genau weiß, wie lang er für eine bestimmte, gut definierte Aufgabe benötigt. Regelmäßiges Schätzen hilft also auch jedem einzelnen.

Die NoEstimates-Befürworter plädieren für eine Orientierung rein am Business-Value, also dem Wert für den Kunden. Um allerdings sinnvoll beurteilen zu können, welches von zwei Features den höheren Wert bringt, muss die Größe der Aufwände für eine Umsetzung in bestimmten Grenzen vergleichbar sein.

NoEstimates in der praktischen Anwendung

Auch in der Technik kann bestehendes nur bis zu einem gewissen Punkt verbessert werden. Ist das Potential ausgeschöpft, hilft nur ein Paradigmenwechsel, um den nächsten Sprung zur Verbesserung auszulösen. Leider gibt es noch wenig praktische Erfahrungsberichte, wie NoEstimates in der Praxis sinnvoll eingesetzt werden kann.

• Es wird ständig Wert in Form von erledigter Arbeit geliefert. Releasezyklen müssen daher klein werden. Sprints sind hier eher nicht geeignet, Overheads beim Release schlagen teurer zu Buche als bei klassischem Scrum
• Alle Arbeitspakete müssen möglichst klein gestaltet werden, da ständig Wert geliefert werden soll. Optimalerweise kann ein Paket an einem Arbeitstag fertiggestellt werden, damit täglich geliefert werden kann.
• Um die unvermeidbaren Größenunterschiede darzustellen, werden die Pakete in (wenigen) Shirtgrößen quantifiziert. Die Extremform besteht dabei in 3 Kategorien: 1 (Story wird umgesetzt), TFB (Story ist zu groß und muss gesplittet werden) und NFC (Story ist nicht klar genug um geschätzt zu werden)
• Alle Beteiligten, insbesondere auch der Kunde, müssen mit im Boot sein. Das heißt hier, dass der Kunde nicht unerhebliche Aufwände investieren muss, den Wert von Features zu bestimmen.
• Das Backlog der umzusetzenden Aufgaben muss permanent priorisiert sein. Es wird immer am wichtigsten Feature gearbeitet, solange bis das erledigt ist, oder bis es nicht mehr länger das wichtigste ist.

NoEstimates steht also eigentlich nicht für „keine Schätzungen“, sondern für eine Konzentration auf wesentliche Teile – nämlich der Entscheidung ob eine Aufgabe bereits bearbeitet werden kann oder nicht. Alles weitere folgt dann aus dem erwarteten Wert. Wir sind gespannt, ob sich NoEstimates durchsetzen kann. Und natürlich sind wir an praktischen Erfahrungen unserer Leser interessiert.