TL; DR: Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg
Viele Menschen lehnen die Schätzung von Arbeitspaketen ab, da Schätzungen angeblich Tür und Tor für den Missbrauch von Metriken wie Velocity durch die Manager öffnen und Taylorismus, Mikromanagement und exzessives Reporting durch die Hintertür wieder einführen. Für die Befürworter von #noestimates stehen Schätzungen im Widerspruch zu grundlegenden Ideen der agilen Produktentwicklung wie Selbstmanagement, Ergebnisorientierung oder dem Ausstieg aus der Feature Factory.
Ich möchte einen anderen, weniger ideologischen Ansatz vorschlagen: Schätzungen sind auf Teamebene nützlich, lassen Sie einfach die Zahlen weg. Warum? Die Schätzung von Arbeitsaufgaben ist ein schneller Weg für ein Scrum-Team, um herauszufinden, ob alle Teammitglieder das gleiche Verständnis über das Warum, das Was und das Wie der anstehenden Arbeit haben. Die resultierenden Zahlen sind jedoch ein reiner Nebeneffekt, der aber wahrscheinlich immer noch zur Information des Teams nützlich ist. (In der Tat sind die Ergebnisse der Schätzungen nicht dazu gedacht, über die Teamebene hinaus verwendet zu werden.)
Übrigens, genauso wie man nicht „nicht kommunizieren“ kann, bin ich davon überzeugt, dass Menschen immer „schätzen“, ob sie nun darüber reden oder nicht.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter "Food for Agile Thought" anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
Schätzungen, die zum Mikromanagement führen und das Erbe des Taylorismus
In der Regel besteht die Befürchtung, dass, sobald ein Produkt- oder Scrum-Team mit Schätzungen beginnt, die Ergebnisse vom Management normalisiert und mit denen anderer Teams verglichen werden und auf lange Sicht gegen sie verwendet werden, indem beispielsweise eine verbindliche Produktivität für einen Sprint festgelegt wird. Darüber hinaus wird die jetzt festgelegte „Velocity“ des Teams dazu verwendet, die Leistung des Teams mit anderen Teams in der Organisation zu vergleichen. Diese Zweckentfremdung einer internen Team-Kennzahl kann auch dazu führen, dass Teams gegeneinander ausgespielt werden, was zu einem wettbewerbsintensiveren und weniger kooperativen Umfeld führt.
Mit anderen Worten: Die Schätzung von Arbeitspaketen führt geradewegs zurück zum industriellen Gedankengut von Herrn Taylor und seinen Anhängern. Leider ist diese Ideologie der Notwendigkeit, die Organisation vor ihren Mitarbeitern zu schützen, von denen die Manager erwarten, dass sie eine ruhige Kugel schieben, sobald sie nicht direkt beaufsichtigt werden, unvereinbar mit der Idee, komplexe Probleme zu lösen und eine lernende Organisation zu werden. (Wenn Sie Ihr Verständnis für die Vorläufer von Taylors „wissenschaftlichem Managementsystem“ vertiefen möchten, empfehle ich Ihnen die Lektüre von Caitlin Rosenthals "Accounting for Slavery").
Von Schätzungen über Velocity bis zur Einhaltung von Fristen
“It’s Difficult to Make Predictions, Especially About the Future.”
Eine typische Argumentation gegen Schätzungen im Team lautet: Schätzungen sind per Definition nicht exakt, da niemand die Zukunft vorhersagen kann. Auf der Grundlage zuvor aggregierter Daten (siehe Velocity) verwenden Manager und Stakeholder diese Zahlen jedoch, um ein Scrum-Team dazu zu bringen, Zusagen in Bezug auf Umfang und Verfügbarkeit von neuen Funktionen abzugeben. Auf diese Weise ignorieren sie jedoch wesentliche Grundsätze der Arbeit in einem komplexen Umfeld, wie z. B. das Selbstmanagement des Teams und das Vertrauen darauf, dass das Team sein Bestes tun wird, um einen Mehrwert für die Kunden zu schaffen.
Dieser Gedankengang mag zwar eine berechtigte Sorge sein, ist aber eher ein Zeichen für die Dysfunktionalität der betreffenden Organisation als für die innewohnende Problematik von Schätzungen an sich. Die Konsequenz sollte daher nicht sein, das Schätzen an sich zu verwerfen, sondern den Mangel an Vertrauen zu beheben, der sich in einem solchen agilen Anti-Muster widerspiegelt.
Ein erfolgreicher Weg zur Schaffung von Vertrauen zwischen Management und Stakeholdern auf der einen Seite und Scrum-Teams auf der anderen Seite ist die regelmäßige Lieferung wertvoller Inkremente. Um dieses Niveau zu erreichen, müssen alle Teammitglieder verstehen, warum das Team an etwas arbeitet, was geliefert werden soll und wie die Entwickler es technisch umzusetzen beabsichtigen.
Dieser Ansatz beginnt lange vor der Schätzung der Product-Backlog-Einträge am Ende des Verfeinerungsprozesses. Im Gegenteil: Dieser bezieht alle Teammitglieder in den Produktfindungsprozess ein, der neue Arbeit für das Product Backlog identifiziert. Es geht um Zusammenarbeit, Einbindung und darum, jedem eine Stimme im Prozess zu geben. Wenn dieser Teamwork-Ansatz zum Standard wird, dann ist die Schätzung der Arbeitselemente nur die letzte Bestätigung dafür, dass alle Teammitglieder sich über das Warum, das Was und das Wie einig sind. (Ist dies nicht der Fall, musst das Scrum Team die entsprechenden Product-Backlog-Einträge weiter verfeinern; offensichtlich sind sich die Teammitglieder noch nicht einig.)
Mit einem einfachen Planungspoker kann das Team daher das Risiko der Komplexität mindern, die anstehenden Arbeiten besser vorbereiten und die Wahrscheinlichkeit der Erreichung des Sprintziels erhöhen. Diese Leistung schafft Vertrauen unter Managern und Stakeholdern. In diesem Szenario braucht niemand Zahlen. Also lasst sie einfach weg.
Schlussfolgerung
Macht nicht einen technischen Vorgang — hier: die Erstellung von Schätzungen für Arbeitspakete — zum Sündenbock für die Dysfunktionalität einer Organisation. Die Hauptursache für Letzteres ist mangelndes Vertrauen, das man nicht nur auf Teamebene angehen kann. Bemühen Sie sich stattdessen um einen ganzheitlichen, integrativen Produktentwicklungsprozess. Übrigens, ich bin davon überzeugt, dass Menschen immer „schätzen“ werden, ggf. im Unterbewusstsein, ob sie nun darüber reden oder nicht.
Nutzt Ihr Scrum-Team Schätzungen für Ihre Arbeit? Bitte teilen Sie uns Ihre Erfahrungen in den Kommentaren mit.
📖 Weitere Artikel
27 Product Backlog Anti-Patterns
20 Sprint Planning Anti-Patterns
Scrum First Principles — Mit Elon Musk zum Scrum Guide
Die Meta-Retrospektive — Wie man Kunden und Interessenvertreter einbindet
Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12
Download the Scrum Anti-Patterns Guide for free.
✋ Nicht versäumen: Lernen Sie mehr über Scrum in der 11.000-köpfigen „Hands-on Agile“ Slack-Community
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.