Macht: Wenn Autorität die Zeremonie an sich reißt

Jede agile Zeremonie setzt gleiche Voraussetzungen voraus. Macht entsteht dann, wenn diese nicht gegeben sind.

Planning Poker wirkt dem Anker-Effekt nur dann entgegen, wenn niemand am Tisch die Karten außer Kraft setzen kann. Eine Retrospektive ist nur dann sicher, wenn Ehrlichkeit keine Nachteile mit sich bringt. Die Velocity ist nur dann eine Prognose, wenn niemand oberhalb des Teams diese bewertet. Entfernen Sie diese Annahmen – fügen Sie einen Manager hinzu, der Beförderungen genehmigt, eine Kennzahl, die nach oben weitergegeben wird, eine Schätzung, die zu einem Versprechen erstarrt – und die Zeremonie bleibt nicht nur hinter den Erwartungen zurück. Sie kehrt sich um. Sie beginnt, gegen die Menschen zu wirken, für die sie geschaffen wurde. Dieses Kapitel nennt die drei deutlichsten Wege, auf denen dies geschieht, denn sie zu benennen ist der erste Schritt, um sie abzulehnen.

Die Geschwindigkeitsratsche

Beginnen wir mit dem schlagkräftigsten Argument überhaupt: Die Person, die die Story-Points erfunden hat, hat sich davon distanziert. „Ich sage gerne, dass ich Story-Points vielleicht erfunden habe, und falls ja, tut es mir jetzt leid“, schrieb Ron Jeffries im Jahr 2019 – und konkret: „Ich halte es für schädlich, Teams anhand der Qualität ihrer Schätzungen oder ihrer Velocity zu vergleichen.“ Wenn der Erfinder einer Maßeinheit Ihnen mitteilt, dass diese dazu genutzt wird, Teams zu schaden, verlagert sich die Beweislast auf jeden, der sie weiterhin als Bewertungsmaßstab verwendet.

Die Velocity-Ratchet ist der Mechanismus, durch den dieser Schaden entsteht. Die Velocity ist als interne Selbstkalibrierung eines Teams gedacht – als gleitender Durchschnitt der abgeschlossenen Punkte, anhand dessen prognostiziert wird, wie lange die Bearbeitung des Backlogs dauern wird. Sobald sie jedoch als Produktivitätsziel den Raum verlässt, wird sie zu einer Ratsche: Der Wert des letzten Sprints ist die Untergrenze für diesen Sprint, und die einzige zulässige Bewegungsrichtung ist nach oben. Teams sind nicht dumm, also reagieren sie auf die einzige Weise, die der Anreiz zulässt – sie blähen die Werte auf. Eine Story, die im letzten Quartal eine 3 war, ist in diesem Quartal eine 5; die Zahl steigt, und nichts wird dadurch schneller ausgeliefert. Selbst Mike Cohn, die Autorität in Sachen „Pro-Points“, räumt diesen Mechanismus ein: Der geringste Hinweis darauf, dass Velocities verglichen werden, führt zu einer allmählichen, beständigen Aufblähung der Punktzahlen.

Die stichhaltigste Grundlage dafür, „Velocity“ auf den richtigen Kurs zu halten, ist DORA. Ein Jahrzehnt der Forschung darüber, welche Faktoren die Leistung bei der Softwarebereitstellung vorhersagen, ergab vier Kennzahlen – Bereitstellungshäufigkeit, Durchlaufzeit, Fehlerquote bei Änderungen und Wiederherstellungszeit – und die Velocity gehört bewusst nicht dazu, da Story-Punkte nicht teamübergreifend vergleichbar sind und den Aufwand messen, nicht den gelieferten Wert. Die Regel ist also einfach und vertretbar: Prognostizieren Sie mit der Velocity, bewerten Sie niemals anhand dieser Zahl. Wenn jemand außerhalb des Teams fragt: „Ist Ihre Velocity gut?“, liegt die Lösung vor der Zahl selbst – die ehrliche Antwort lautet: „Was versuchen Sie eigentlich zu messen?“ Unser Kapitel Velocity zeigt, wie man dabei ehrlich bleibt, und Velocity und Kapazitätsplanung erläutert, wie man sie für den einzigen Zweck einsetzt, für den sie geeignet ist.

Schätzungswäsche

Die zweite Verzerrung ist subtiler, da sie den Anschein von Verantwortlichkeit erweckt. Schätzungswäsche ist die stillschweigende Umwandlung einer Schätzung – einer Vermutung, die auf der geringsten Informationsgrundlage getroffen wird, die Ihnen jemals zur Verfügung stehen wird – in eine Verpflichtung, an die das Team dann gebunden wird, als hätte es einen Vertrag unterzeichnet. Die Vermutung fließt in die Planungssitzung ein; daraus ergibt sich eine Frist; und wenn die Frist überschritten wird, liegt die Schuld beim Entwickler, der „seine Schätzung verfehlt“ hat.

Die Praktiker beschreiben den gesamten „Waschzyklus“ von sich aus, ohne dazu aufgefordert zu werden: Schätzungen werden wie von Zauberhand zu verbindlichen Zusagen, und wenn Sie die Zahl nicht erreichen, sind Sie selbst schuld. Schätzungen werden verworfen – „das kann nicht stimmen, machen Sie es noch einmal“ –, bis das Team eine Zahl nennt, die den Termin einhält; ab diesem Zeitpunkt ist die Planung eine Farce mit einer vorbestimmten Antwort. Es gibt sogar eine aufschlussreiche Asymmetrie in der Sprache: Sagt man „Das wird zehn Tage dauern“, wird ein Manager nachhaken: „Sind Sie sicher, dass es nicht neun sein können?“; sagt man „Das sind zehn Punkte“, wird aus Gründen, die niemand so recht begründen kann, derselbe Instinkt nicht ausgelöst. Story-Punkte waren teilweise als Schutzschild gegen genau diesen Druck gedacht – und die „Schätzungswäsche“ ist der Druck, der dieses Schutzschild durchbricht, indem die Punkte direkt wieder in einen Termin umgerechnet werden.

Die maßgebliche Korrektur stammt von Mike Cohn und ist älter als unsere Wortschöpfung: Schätzung und Verpflichtung trennen. Eine Schätzung ist eine Wahrscheinlichkeitsverteilung; eine Verpflichtung ist eine Entscheidung des Teams darüber, was es mit Sicherheit liefern kann. Halten Sie diese beiden Aspekte bewusst voneinander getrennt. Prognostizieren Sie eine Bandbreite und benennen Sie die ihr zugrunde liegenden Annahmen. Achten Sie dabei auf den Fall der Kumulierung – wenn Umfang, Zeit und Kosten alle im Voraus festgelegt sind und die Arbeit lediglich in zweiwöchige Sprints verpackt wird, haben Sie kein agiles Verfahren mit Schätzungen, sondern Wasserfall in Verkleidung. Dave West von Forrester nannte dies „Water-Scrum-Fall“, und die „Schätzungwäsche“ ist dessen Herzstück. Unser Kapitel Story-Punkte vs. Stunden erläutert, warum die Umrechnung der Fehlermodus ist und nicht die Lösung.

Feedback-Banking

Die dritte Verzerrung ist die gravierendste, da sie selbst die harmloseste Zeremonie zu einer Belastung macht. Feedback-Banking bedeutet, dass ehrliche Rückmeldungen aus der Retrospektive gesammelt und später stillschweigend gegen Sie verwendet werden – bei einer Leistungsbeurteilung, einer Bonusberechnung oder einem vertraulichen Gespräch über die „Passung“. Die Retrospektive wird als sicherer Raum für Offenheit verkauft. „Feedback-Banking“ ist die Erkenntnis, dass Offenheit ein Fälligkeitsdatum hat.

Die Erfahrungsberichte sind konkret und treffen ins Schwarze. Ein Ingenieur beschrieb, wie sein Feedback aus früheren Jahren bei einer jährlichen Beurteilung wieder auftauchte – als Beweis dafür, dass er sich „zu viel beschwert“. Ein anderer brachte den Mechanismus auf den Punkt: Die Geschäftsleitung sammelt alle Beschwerden, um sie bei Ihrer jährlichen Bonusbeurteilung gegen Sie zu verwenden. Dieser abschreckende Effekt erfordert nicht einmal böse Absicht – die Person, die über Beförderungen entscheidet, muss im Raum kein einziges Wort sagen. Allein ihre Anwesenheit reicht aus, um ehrliche Rückmeldungen zu verwässern und allen zu vermitteln, dass es klüger ist, Zufriedenheit vorzutäuschen. Unser Kapitel Warum Retrospektiven scheitern befasst sich mit der Gestaltung der Sitzung, damit Ehrlichkeit keine karrierebezogenen Nachteile mehr mit sich bringt.

An dieser Stelle hört die Sicherheitsliteratur auf, nur mit den Händen zu wedeln. Amy Edmondsons Arbeit zur psychologischen Sicherheit sowie Googles Projekt Aristoteles – eine zweijährige Studie mit 180 Teams – ergaben, dass die psychologische Sicherheit der stärkste der fünf identifizierten Faktoren ist – jener, auf dem die anderen vier beruhen. Ein Team, das erfahren hat, dass sein Feedback „auf Eis gelegt“ wird, verfügt per Definition über keine psychologische Sicherheit, und eine Retrospektive, die so tut, als wäre dies nicht der Fall, ist reines Theater, das mit einem rechtlichen Risiko verbunden ist. Der Scrum Guide definiert die Retrospektive als einen Prozess, in dem das Team sich selbst überprüft – warum also sitzt der Manager im Raum und macht sich Notizen?

Verlassen Sie sich nicht auf einen Helden

In dieser Lösung verbirgt sich ein Fehlermodus. Diese Verzerrungen werden in der Regel unterdrückt, weil eine Führungskraft – ein Teamleiter oder ein EM mit Rückgrat – das Team persönlich abschirmt: Sie weigert sich, die Velocity nach oben weiterzugeben, formuliert Schätzungen als Prognosen um und sorgt dafür, dass der Inhalt des Retrospektive im Raum bleibt. Das funktioniert, aber nur solange diese Person im Amt bleibt. Ein Schutzschild ist kein System. Wenn die Ehrlichkeit Ihrer Zeremonien von der Bereitschaft eines einzelnen Managers abhängt, den Druck auf sich zu nehmen, haben Sie keine sicheren Zeremonien – Sie haben lediglich vorübergehend wohlwollende Zeremonien, und das Theater geht weiter, sobald diese Person das Unternehmen verlässt.

Das ist der Unterschied zwischen „Macht“ als Fehlermodus und „Macht“ als feststehendes Konstrukt. Das Kapitel Psychologische Sicherheit befasst sich mit dem Aufbau von Offenheit, die nicht davon abhängt, wer im Raum anwesend ist, und die Grundregel behandelt die Norm, die dafür sorgt, dass diese Offenheit Bestand hat. Wenn die festgefahrenen Zeremonien schließlich nichts als inszenierte Fassaden hervorbringen, sind Sie in der Leere der Umsetzung angekommen – dem vierten Modus, in dem das „Feedback-Horten“ seinen stillsten Schaden anrichtet.

Häufig gestellte Fragen

Wie kann ich verhindern, dass die Geschäftsleitung die Velocity gegen mein Team einsetzt?

Behalten Sie die Zahl im Blick. Die Velocity ist eine Eingangsgröße für Prognosen, keine Leistungskennzahl – die DORA-Studie lässt sie bewusst außer Acht, da die Punkte zwischen den Teams nicht vergleichbar sind. Wenn ein Manager außerhalb des Teams fragt, ob Ihre Velocity gut ist, lautet die ehrliche Antwort eine Gegenfrage: Was versuchen Sie eigentlich zu messen? Berichten Sie über Ergebnisse und Erledigungsstand, nicht über Punktestände.

Kann retrospektives Feedback bei einer Leistungsbeurteilung gegen mich verwendet werden?

Das kommt vor, und die Befürchtung ist berechtigt – Praktiker berichten, dass ehrliche Rückmeldungen aus Retrospektiven Monate später wieder auftauchen, als Vorwurf, sie würden sich zu viel beschweren. Das ist „Feedback-Banking“, und genau deshalb gibt es Anonymität, den Ausschluss von Führungskräften und die „Vegas-Regel“. Ein Retrospektive, bei der Offenheit ein Karriere-Risiko darstellt, ist psychologisch nicht sicher, und keine Moderationstechnik kann dies beheben. Ändern Sie die Machtverhältnisse, nicht die Wortwahl.

Wie kann ich verhindern, dass aus Schätzungen Fristen werden?

Trennen Sie das Schätzen bewusst und ausdrücklich vom Festlegen ab. Eine Schätzung ist eine Wahrscheinlichkeit; eine Zusage ist ein Versprechen; wenn man das eine mit dem anderen verwechselt und das Team dann daran festhält, bricht das Vertrauen. Geben Sie eine Spanne an, nennen Sie die Annahmen und lassen Sie niemals zu, dass eine in einer Planungssitzung geäußerte Vermutung als Termin wiedergegeben wird, zu dem sich das Team verpflichtet hat.

Sollte mein Vorgesetzter an der Retrospektive teilnehmen oder das Stand-up-Meeting leiten?

Im Allgemeinen nicht. Der Scrum Guide definiert die Retrospektive als Selbstreflexion des Teams und das Daily Stand-up als interne Koordination der Entwickler. Eine Autoritätsperson im Raum muss kein einziges Wort sagen, um die Offenheit zu beeinträchtigen – die Person, die Beförderungen genehmigt, wirkt von Natur aus einschüchternd. Leiten Sie die Aktionspunkte nach oben weiter, nicht die Sitzplätze.

Weiterführende Literatur

• Die Lücke der Nachwirkung – dort, wo aufgestaute Rückmeldungen und Ohnmacht aufeinandertreffen.
• Performance: die Zeremonie, die Sie für das Publikum inszenieren – das Theater, das die Macht zu einem Zwang macht.
• Geschwindigkeit: Wozu dient sie und wie berechnet man sie? – Verwenden Sie diesen Wert für Prognosen, niemals zur Benotung.
• Story-Punkte vs. Stunden – warum die Umrechnung die „Schönrechnerei“ bei Schätzungen begünstigt.
• Sprint-Planung (die Zeremonie) – bei der eine Schätzung als Prognose des Teams betrachtet wird und keine verbindliche Zusage darstellt.
• Wie man einen psychologisch sicheren Raum schafft – Offenheit, die nicht davon abhängt, wer im Raum anwesend ist.
• Glossar zum agilen Theater – „Estimate Laundering“, „Feedback Banking“ und „Velocity Ratchet“ – Erläuterungen.