Agile Missverständnisse: NoEstimates – Schätzungen schaden.

Wer schätzt, verliert. Entweder man hat genug Buffer mit drin und es ist zu aufwändig, oder er fehlt und es klappt nicht pünktlich. Externe Abhängigkeiten werden auf rauen Annahmen geplant, von denen man sich zwar wirklich wünscht, dass sie zutreffen würden, aber in Wahrheit selbst nicht daran glaubt. Und kurz vor dem Launch kommen dann die Überraschungen, mit denen man zwar gerechnet hat, jetzt aber keine Zeit mehr hat, mit ihnen umzugehen.

NoEstimates

Also lieber nicht schätzen, sondern auf Business Value und Durchfluss optimieren. Wenn ich zu jedem Zeitpunkt das Nützlichste mache und meine Strecke auf dem Weg dazu kontinuierlich verbessere – was könnte ich mehr als Beitrag leisten?

Und überhaupt: Meine Schätzungen stimmen ja in Wahrheit eh nicht. Das kann wahlweise nur in verschwendeter Zeit – wenn der Buffer zu groß war – oder in schlechter Qualität – wenn der Buffer zu klein war – resultieren. Also lassen wir es einfach weg.

Aber damit verliert man nicht nur die Probleme, sondern auch die nützlichen Eigenschaften von Schätzungen. Wie finde ich als Team heraus, ob unser gemeinsames Bild von der anstehenden Arbeit hinreichend ist? Welche Informationen müssen wir zusammenbringen, um diese Story gut zu erfüllen?

Die unknown Unknowns

Diese offensichtliche Frage hat keine einfache Antwort, denn sie enthält ein unknown-Unknows-Problem. Konkret geht es um das relevante Wissen, das die Kollegen haben und das ich brauche, aber nicht habe. Ich kann danach nicht fragen – denn ich weiß ja nicht, was ich nicht weiß. Und der Kollege kann es auch nicht aus sich heraus liefern, denn er weiß wiederum nicht, was ich nicht weiß, aber wissen sollte.

Wie kommt man aus diesem Dilemma heraus? Na, dann muss eben jeder alles erzählen, was er weiß. Aber das dauert nicht nur Wochen, sondern es ist auch unvollständig … denn ich weiß selbst nicht, was ich weiß, es ist mir nicht bewußt, welches Wissen ich tatsächlich über das Produkt habe.

Wie komme ich aus dieser Zwickmühle? Wie bringe ich die Kollegen dazu, mir die relevanten Teile zu liefern, die mir von ihrem Wissen fehlen?

Agile Missverständnisse

Ihr habt Interesse an agilen Missverständnissen und anderen Anti-Pattern? Die passende App dazu findet ihr im Google Play Store:

Jetzt bei Google Play

Schätzungen = Hashing

Wir Informatiker haben für solche Probleme – wie stelle ich die Differenz von zwei Mengen, die sehr gross sind, mit einfachen Mitteln fest – eine schöne Lösung. Wir verwenden Hashing-Funktionen, wie sha512sum und Verwandtschaft.

Schätzungen sind so eine Hashing-Funktion. Sie beziehen mein gesamtes Wissen über das Produkt ein, weil sie auf diesem basieren. Und nicht nur das, sie enthalten sogar meine Intuition und mein Erfahrungswissen.

Als Hashwert bekomme ich die vermutete Zeit, den vermuteten „Effort“. Und wenn der Hashwert, also mein erwarteter Aufwand, kleiner ist? Dann habe ich aus einem unknown Unknown ein known Unknown gemacht, denn jetzt weiß ich, wonach ich fragen muss. „Wie kommst Du auf die 10 idealen Tage? Was ist die Basis für die 20 Story Points?“. Und ich komme in eine Diskussion, in der ich erfahre was mein Kollege weiß, ich aber nicht. Und umgekehrt.

tl;dr

Schätzungen sind ein wunderbares Werkzeug, um auf effiziente und effektive Art gemeinsames Verständnis, gemeinsame Bilder und gemeinsame Erwartungen zu erzeugen. Und dieses gemeinsame mentale Modell ist deutlich mehr wert als die pure Schätzung selbst. Es erlaubt mir nicht nur Alignment, sondern mehr Kontextwissen in der Arbeit und mehr Rücksicht auf die Seiteneffekte. Und ja, vielleicht spare ich damit sogar so viel Zeit, dass ich den Buffer am Ende gar nicht brauche.

Unsere Serie Agile Missverständnisse


Für neue Blogupdates anmelden:


4 Gedanken zu “Agile Missverständnisse: NoEstimates – Schätzungen schaden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.