Im Nachgang zu "Der Umgang mit Schätzungen" und "Gut, schlecht, falsch, richtig, Fehler und Irrtum" gab es interessante Kommentare und Diskussionen. Die Ergebnisse daraus finde ich so wertvoll, dass sich dafür gleich ein neuer Beitrag lohnt.
Die zentralen Punkte im Nachgang waren:
Einerseits braucht die Rolle des PO und auch einige Menschen (einige Teammitglieder ebenso wie PO & Management oft) mindestens relative oder absolute Schätzungen, wenn nicht sogar (am liebsten) Prognosen, die Sicherheit und Planbarkeit versprechen. Es meist aber nur scheinbar und unzuverlässig schaffen, richtig? Was ist Deine Lieblingslösung: Nicht zu schätzen, keine Zeitangabe zu machen?
Ich habe keine Lieblingslösung. Gut ist, was ein vorliegendes Problem löst.
Und zugegeben, das ist etwas geflunkert. Eigentlich versuche ich meist, den Schätzzwang zu vermeiden. In vielen Fällen scheint mir die Frage nach Schätzungen ein Reflex oder eine alte Gewohnheit zu sein und damit potenziell Zeitverschwendung.
Die große Frage ist: Wozu soll geschätzt werden?
Nehmen wir für die weiteren Ausführungen an, wir bewegen uns in einem Scrum-Umfeld. Grundsätzlich plant Scrum bereits auf drei Ebenen:
So viel zur Planbarkeit. (Ein Scrum-Maximalist könnte jetzt übrigens sagen, dass es in Scrum keine Schätzungen gibt.) Wer also braucht eine Schätzung?
Betrachten wir zuerst die Developer. Ein guter Grund kann sein, dass die Devs für sich eine Einschätzung brauchen, ob ein Product Backlog Item klein genug ist, um in einem Sprint komplett erledigt zu werden. Ein in der Realität leider oft beobachtbare Ursache ist jedoch, dass sie ein Gefühl für Sicherheit bekommen wollen. In diesem Fall fehlt die wichtige psychologische Sicherheit, auch Fehler machen zu können. Diese Devs sind vermutlich gebrannte Kinder, die zu oft hören mussten: "Warum habt ihr das nicht erreicht?" Und eines der schlechtesten Sprintziele ist übrigens "Wir müssen alle Items im Sprint Backlog abarbeiten."
Wie sieht es für Scrum Master aus? Diese können Schätzung bzw. die im Nachgang ermittelbare Velocity (ein Scrum-Maximalist könnte jetzt übrigens sagen, dass es in Scrum keine Velocity gibt) als Indikator nutzen, um mögliche Teamprobleme zu entdecken. Ansonsten sind Schätzungen für Scrum Master zweitrangig. Sehr viel wichtiger als das Ergebnis ist die Diskussion im Vorfeld. Individuals and interactions over processes and tools, anyone?
Bleibt die Product Ownerin. Sie kann Schätzungen nutzen, um eine Go-/ No-Go-Entscheidung für einen geplanten Teil des Produkts zu treffen. Die geschätzten Kosten im Vergleich zum erwarteten Wert bilden hierfür die Grundlage. Ebenfalls können grobe Schätzungen herangezogen werden, um eine Indikation einer Zeitlinie abzugeben.
Auch ein fixes Veröffentlichungsdatum kann ein wichtiger Grund sein. Steht z. B. eine wichtige Messe an, gibt es am Lieferzeitpunkt wenig zu rütteln. Wie ein Kommentar es schön zusammenfasst:
Die wichtigste Frage (aus dem Gedankenspiel) ist doch die: „Wann müssen wir los, damit wir rechtzeitig zur Kaffeezeit am Platz sind?“. Irgendwann musst du ja losfahren, um anzukommen, und das möchtest du idealerweise, wenn noch Kuchen da ist. Du kommst um eine Abschätzung doch eigentlich gar nicht herum. Nur ob du diese als fixe Wahrheit an alle kommunizierst, scheint mir variabel zu sein.
Nur irgendwer scheint diese Kontroll-Illusion zu brauchen. Damit komme ich wieder zum Kernproblem, das ich hier gerne noch einmal wiederhole: Schätzungen sind immer falsch. Sie sind unscharfe Daten. Mit unscharfen Daten kann ich Indikationen abgeben, aber keine Sicherheit verkaufen.
Das ist auch der Grund, warum Produkt-Roadmaps mit Zeitangaben eine schlechte Idee sind. Sobald irgendwo ein Datum steht, entsteht die Erwartungshaltung einer Verbindlichkeit. Das macht eine Roadmap zu einem Projektplan.
Meine Hypothese: Das "Wozu-Schätzungen-Spiel" führt schnell zur Erkenntnis, dass wir eigentlich von Projektmanagement reden und nicht von agiler Produktentwicklung.
Die beiden müssen sich nicht ausschließen und sind mit ihren unterschiedlichen Zielen trotzdem verschiedene Punkte auf einem Kontinuum.
Und die Unterscheidung der beiden zeigt, wo sich eine Organisation auf dem Weg zur Agilität derzeit befindet.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.