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 verhindert den Anker-Effekt nur dann, 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 sich zu einem Versprechen verfestigt), 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 Sie mit dem schlagkräftigsten Argument von allen: Der Erfinder der Story-Points hat sich von ihnen distanziert. „Ich sage gerne, dass ich die Story-Points vielleicht erfunden habe, und falls dem so ist, tut es mir jetzt leid“, schrieb Ron Jeffries im Jahr 2019. Er drückte sich konkret aus: „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, liegt die Beweislast nun bei all jenen, die sie weiterhin als Bewertungsmaßstab verwenden.

Die „Velocity-Ratchet“-Effekt ist der Mechanismus, durch den dieser Schaden entsteht. Die Velocity ist als interne Selbstkalibrierung eines Teams gedacht: der gleitende Durchschnitt der fertiggestellten Punkte, der dazu dient, die Dauer der Bearbeitung eines Backlogs abzuschätzen. Sobald sie jedoch als Produktivitätsziel aus dem Raum tritt, wird sie zu einer Ratschmechanik: 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, daher 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 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 Punktinflation.

Die stichhaltigste Grundlage dafür, „Velocity“ in ihrem Rahmen zu halten, ist DORA. Ein Jahrzehnt der Forschung zu den Faktoren, die die Leistung bei der Softwarebereitstellung vorhersagen, ergab vier Schlüsselkennzahlen (Bereitstellungshäufigkeit, Durchlaufzeit, Fehlerquote bei Änderungen und Zeit bis zur Wiederherstellung), und „Velocity“ gehört nicht dazu; Story-Points sind nicht teamübergreifend vergleichbar und messen den Aufwand, nicht den gelieferten Wert. Die Regel ist also einfach und vertretbar: Prognostizieren Sie anhand der Velocity, bewerten Sie jedoch niemals danach. 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 zur Velocity zeigt, wie man dabei ehrlich bleibt, und die Velocity- und Kapazitätsplanung verdeutlicht, wie man sie für das einzige Ziel einsetzt, für das sie geeignet ist.

Schätzungswäsche

Die zweite Verzerrung ist subtiler, da sie den Anschein von Verantwortlichkeit erweckt. Unter „Schätzungswäsche“ versteht man 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 verbindliche Zusage, an die das Team dann gebunden wird, als hätte es einen Vertrag unterzeichnet. Die Schätzung fließt in die Planungssitzung ein; daraus ergibt sich ein Termin; und wenn dieser Termin nicht eingehalten wird, ist es die Schuld des Entwicklers, der „seine Schätzung verfehlt“ hat.

Die Praktiker beschreiben den gesamten „Waschzyklus“ von sich aus, ohne dazu aufgefordert zu werden: Schätzungen werden auf magische Weise 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 sich sicher, dass es nicht neun sein können?“; sagt man „Das sind zehn Punkte“, wird aus Gründen, die niemand so recht rechtfertigen 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 Lösung stammt von Mike Cohn und ist älter als unser Begriff: Trennen Sie die Schätzung von der Zusage. Eine Schätzung ist eine Wahrscheinlichkeitsverteilung; eine Zusage 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 bereits im Voraus feststehen 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 hat dies als „Water-Scrum-Fall“ bezeichnet, und die „Schätzungswäsche“ ist dessen Herzstück. Unser Kapitel „Story-Points 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. Unter „Feedback-Hortung“ versteht man, dass ehrliche Rückmeldungen aus einer Retrospektive gesammelt und später stillschweigend gegen Sie verwendet werden: bei einer Leistungsbeurteilung, einer Bonusfestlegung oder einem vertraulichen Gespräch über die „Eignung“. Das Rückblickgespräch wird als sicherer Raum für Offenheit verkauft. Feedback-Hortung ist die Erkenntnis, dass Offenheit ein Verrechnungsdatum hat.

Die Erfahrungsberichte sind konkret und treffen ins Schwarze. Ein Ingenieur beschrieb, wie sein negatives Feedback bei der jährlichen Beurteilung wieder aufgegriffen wurde – 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. Für diesen abschreckenden Effekt bedarf es nicht einmal böser Absicht. Die Person, die über Beförderungen entscheidet, muss im Raum kein einziges Wort sagen. Allein ihre Anwesenheit reicht aus, um ehrliche Beiträge zu verschleiern und allen zu verdeutlichen, dass es klüger ist, Zufriedenheit vorzutäuschen. In unserem Kapitel „Warum Retrospektiven scheitern“ geht es darum, die Sitzung so zu gestalten, dass Ehrlichkeit keine negativen Auswirkungen mehr auf die Karriere hat.

An dieser Stelle hört die Literatur zum Thema Sicherheit auf, nur in die Luft zu greifen. Amy Edmondsons Arbeit zur psychologischen Sicherheit sowie Googles „Project Aristotle“ – eine zweijährige Studie an 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 gelernt hat, dass sein Feedback „aufgespart“ wird, verfügt per Definition über keine psychologische Sicherheit, und eine Retrospektive, die so tut, als wäre dies anders, 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

Innerhalb der Abhilfemaßnahme verbirgt sich eine Schwachstelle. Diese Verzerrungen werden in der Regel unterdrückt, weil eine Führungskraft (ein Teamleiter, 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 der 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 eine vorübergehend wohlwollende Zeremonie, 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 über psychologische Sicherheit befasst sich mit dem Aufbau von Offenheit, die nicht davon abhängt, wer im Raum anwesend ist, und die „Prime Directive“ behandelt die Norm, die dafür sorgt, dass diese Offenheit Bestand hat. Wenn die festgelegte Zeremonie schließlich nichts als inszenierte Fassaden hervorbringt, sind Sie in der „Follow-Through-Leere“ angekommen: dem vierten Modus, in dem das „Feedback-Banking“ 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 dient als Eingangsgröße für Prognosen, nicht als Leistungskennzahl. Sie gehört nicht zu den Lieferkennzahlen von DORA, und Punktewerte sind ohnehin nicht teamübergreifend vergleichbar. Wenn ein Manager außerhalb Ihres 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 Angst ist berechtigt. Praktiker berichten, dass ehrliche Rückmeldungen aus Retrospektiven Monate später wieder auftauchen, als Hinweis darauf, dass sie 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. Beheben 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 Standup-Meeting leiten?

Im Allgemeinen nicht. Der Scrum Guide definiert die Retrospektive als Selbstreflexion des Teams und das tägliche Meeting 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 in der Umsetzung: wo aufgestaute Rückmeldungen und Ohnmacht aufeinandertreffen.
• Aufführung: die Zeremonie, die Sie für das Publikum inszenieren; das Theater, das die Macht zu einem Mittel der Nötigung macht.
• Geschwindigkeit: Wozu sie dient und wie man sie berechnet: Verwenden Sie diesen Wert für Prognosen, niemals zur Benotung.
• Story-Punkte vs. Stunden: Warum die Umrechnung die „Schönfärbung“ von Schätzungen begünstigt.
• Sprint-Planung (die Zeremonie): Hier soll eine Schätzung eine Prognose bleiben, für die das Team die Verantwortung trägt, und keine verbindliche Zusage.
• 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“ – Definitionen.