Warum Retrospektiven scheitern (und wie Sie Ihre Retrospektive zu etwas Sinnvollem machen können)

Ihr Team führt in jedem Sprint eine Retrospektive durch. Die Teilnehmer erscheinen, heften ihre Haftnotizen an die Pinnwand, nicken bei zwei oder drei Aktionspunkten und gehen wieder. Doch an der Art und Weise, wie die Arbeit tatsächlich erledigt wird, ändert sich nichts. Wenn Sie das vierzig Mal im Jahr tun, haben Sie keine Gewohnheit der Verbesserung etabliert. Sie haben sich die Gewohnheit angeeignet, über Verbesserungen zu sprechen. Das ist der Fehler, den fast niemand beim Namen nennt: kein schlechtes Format, sondern ein Ritual, das zuverlässig Worte und nur Worte hervorbringt.

Der übliche Ratschlag betrachtet eine missglückte Retrospektive als Moderationsproblem: Ändern Sie das Format, formulieren Sie „SMART“-Maßnahmen, fügen Sie einen Icebreaker hinzu. Manchmal ist das tatsächlich das Problem. Meistens ist es das jedoch nicht. Wir haben an anderer Stelle die zehn häufigsten Retrospektiv-Antimuster zusammengestellt, und es lohnt sich, diese zu beheben. Dieses Kapitel befasst sich mit den beiden Problemen, die in der Liste höflich umgangen werden, da sie genau die Ursachen sind, die erfahrene Entwickler dazu bringen, Retrospektiven als Zeitverschwendung zu bezeichnen: ein Macht-Problem und ein Umsetzungs-Problem. Kein Icebreaker kann hier Abhilfe schaffen. Sollte die Moderation tatsächlich Ihr Problem sein, liegt die Lösung in der Durchführung effektiver Retrospektiven, nicht hier.

Der Rückblick, der nichts ändert, weil die Mannschaft dazu nicht in der Lage ist

Hier liegt die tiefgreifendste Kritik an Retrospektiven vor – und genau hier liegt der Fehler in unserem eigenen Beitrag zu Anti-Mustern. Wenn ein Entwickler sagt: „Es passiert nie etwas“, meint er damit in der Regel nicht, dass das Team vergessen hat, Aktionspunkte festzuhalten. Er meint vielmehr, dass die Probleme, die es wert sind, angesprochen zu werden (Personalbestand, teamübergreifende Abhängigkeiten, eine Deployment-Pipeline, die vierzig Minuten dauert, eine von der dritten Führungsebene festgelegte Frist), tatsächlich außerhalb der Befugnisse des Teams liegen, sie zu beheben. Wie ein Ingenieur auf Hacker News treffend formulierte, kann eine Retrospektive zu „einer Zeremonie ohne tatsächlichen Zweck werden, da die tiefergehenden Themen, die die Teilnehmer ansprechen, in der Regel nicht im Einflussbereich des Teams liegen“. Ein anderer Teilnehmer im selben Thread: „Das gibt der Führungsebene einen Vorwand, Dinge nicht zu beheben oder nicht zuzuhören, da das Retrospektive angeblich als Ventil für Beschwerden gedacht ist.“

Das ist die Falle. Das Retrospektive-Gespräch wird zu einem Druckventil: Das Team kommt zu Wort, gerade damit sich nichts ändern muss. Die Mitarbeiter lassen Dampf ab, die Führungskräfte haben das Gefühl, die Aufgabe sei erledigt, und die eigentliche Ursache bleibt unberührt. Dem Moderator die Schuld dafür zu geben, ist, wie es in einem Essay eines Entwicklers hieß, „so, als würde man dem Vorschlagsbriefkasten die Schuld dafür geben, dass die Geschäftsleitung die Vorschläge nicht liest“. Kein noch so oft wiederholtes „Segelboot-gegen-Seestern“-Argument wird einem Team die Befugnis verleihen, ein Problem zu lösen, für dessen Lösung es nie die Befugnis erhalten hat.

Unser alter Ratschlag („Konzentrieren Sie sich nicht auf Dinge außerhalb Ihres Einflussbereichs“) steht hier stillschweigend auf der Seite des Systems. Er fordert das Team auf, das eigentliche Hindernis zu verschweigen, um die Gesprächsatmosphäre angenehm zu halten. Verfolgen Sie stattdessen einen strengeren Ansatz. Sortieren Sie jedes Problem danach, wem es tatsächlich zuzuordnen ist: Was das Team kontrolliert, worauf es Einfluss nehmen kann und was es lediglich hinnehmen muss. Das ist die „Circles and Soup“-Übung aus Esther Derby und Diana Larsens Agile Retrospectives (2. Aufl.). Der Sinn des äußeren Rings besteht nicht darin, diese Punkte zu „ignorieren“. Er dient als Grundlage für eine Eskalation.

Nicht alles spitzt sich zu, und nicht alles ist hoffnungslos. 15 %-Lösungen, die „Liberating Structures“-Technik, mit der die kleinste Veränderung ermittelt wird, die das Team vornehmen kann, ohne die Erlaubnis von jemandem einzuholen, hält die Dynamik im Einflussring aufrecht, während sich die großen Hindernisse nach und nach auflösen. Doch die ehrliche Retrospektive weigert sich, so zu tun, als sei der äußere Ring die Schuld des Teams.

Das Feedback, das gesammelt und gegen Sie verwendet wird

Nun zu dem Teil, über den kein Anbieter schreibt. Die Menschen schweigen bei Retros aus einem konkreteren Grund als bloßer Schüchternheit: Ehrlichkeit kann sich negativ auf die Karriere auswirken. Diese Angst ist ganz konkret und zeigt sich in realen Geschichten. Ein Entwickler beschrieb, wie Feedback aus Retros „in meiner jährlichen Beurteilung wieder auftauchte, wo mir vorgeworfen wurde, ich würde ‚zu viel meckern‘“. Ein anderer äußerte sich zynischer: „Sie sammeln all diese Beschwerden, um sie bei Ihrer jährlichen Bonusbeurteilung gegen Sie zu verwenden.“

Das ist Feedback-Banking: ehrliche Rückmeldungen, die gesammelt und später gegen Sie verwendet werden – und der schnellste Weg, eine Retrospektive zu ruinieren. Der Scrum Guide beschreibt die Sprint-Retrospektive als die Selbstreflexion des Scrum-Teams. Nehmen Sie das wörtlich: Das Team, das sich selbst reflektiert. Warum sitzt also die Person, die Ihre Leistungsbeurteilung unterzeichnet, im Raum und macht sich Notizen? Ihr Schweigen reicht aus. Niemand, der über Ihre Beförderung entscheidet, muss ein Wort sagen, um Sie dazu zu bringen, das, was Sie sonst gesagt hätten, abzuschwächen. Googles „Project Aristotle“ ergab, dass psychologische Sicherheit der wichtigste Prädiktor für die Effektivität eines Teams ist; die bloße Anwesenheit eines Vorgesetzten reicht oft schon aus, um diese zu untergraben. (Wir behandeln die Mechanismen dazu im Kapitel über den Aufbau eines psychologisch sicheren Raums.)

Benennen Sie also die Angst und entwickeln Sie eine Strategie, um ihr entgegenzuwirken:

• Halten Sie die Beförderungsbefugnis aus dem Raum fern. Geben Sie die vereinbarten Maßnahmen nach oben weiter, nicht die Sitzplätze. Ein Team, das durch die Anwesenheit eines Vorgesetzten blockiert wird, kann keine transparente Retrospektive durchführen, und kein Moderationstrick kann dies wieder in Ordnung bringen.
• Man ist sich einig, dass das Gesagte im Raum bleibt. Nur die Maßnahmen, die das Team veröffentlicht, verlassen den Raum. Genau das ermöglicht es den Menschen überhaupt erst, sich zu äußern.
• Machen Sie Anonymität zu einer Option für jeden einzelnen Vorschlag, nicht zu einem dauerhaften Modus. Anonymität gleicht Machtverhältnisse aus und bringt sensible Themen ans Licht; wird sie jedoch als dauerhafte Krücke genutzt, untergräbt sie das Vertrauen, das Sie aufbauen möchten. Lassen Sie die Nutzer diese Option für diejenigen Beiträge wählen, bei denen sie erforderlich ist.
• Seien Sie vorsichtig bei der Einführung von Kennzahlen. Objektive Daten (Velocity, Zykluszeit) gehören in ein Retrospektive-Meeting, doch sobald die Velocity zu einem Ziel wird, an dem das Team gemessen wird, haben Sie eine Velocity-Ratchet geschaffen, und die Mitarbeiter optimieren die Zahlen, anstatt die Wahrheit zu sagen. Dies ist der Power-Failure-Modus, der Offenheit in Leistungsdruck verwandelt.

Die Lücke im Nachschwung und die Umdeutung, die sie behebt

Nehmen wir einmal an, die Probleme hinsichtlich der Arbeitsbelastung und der Sicherheit seien gelöst. Dennoch scheitern Retrospektiven an der am häufigsten geäußerten Kritik in der gesamten Diskussion: „Retrospektiven bieten zwar die Möglichkeit, Bedenken zu äußern, doch aus diesen Bedenken wird nie wirklich etwas.“ Oder, noch deutlicher ausgedrückt: „Ich habe noch nie erlebt, dass außer Worten etwas passiert ist.“ Der resignierte Unterton („dieses Thema wird nicht angegangen“) ist genau das Gefühl, das Retrospektiven, die sich wie der „Tag der Murmeltiere“ anfühlen, von innen heraus vermitteln. Das ist keine Einbildung: Die Zahl, die alle wiederholen – eine häufig zitierte Angabe, wonach nur etwa ein Drittel der Teams ihre aus Retrospektiven resultierenden Maßnahmen konsequent umsetzt –, stellt die Lage letztlich in einem übertriebenen Licht dar. Wir haben gemessen, wie viele Aktionspunkte aus Retrospektiven tatsächlich umgesetzt werden anhand von Hunderttausenden realer Maßnahmen: Die Umsetzungsquote liegt näher bei drei von vier, und die Regelmäßigkeit sowie die Übernahme von Verantwortung entscheiden darüber, auf welcher Seite dieser Kluft ein Team landet. Was die gängige Meinung richtig erkennt, ist die Form des Scheiterns. Eine Maßnahme, für die niemand die Verantwortung übernimmt, für die kein Termin festgelegt ist und die in einem Team ohne Rhythmus umgesetzt werden soll, ist genau die, die auf ein Whiteboard geschrieben und wieder gelöscht wird.

Zwei Korrekturen, wobei die zweite die wichtigere ist.

Zunächst einmal: Hören Sie auf, alles in Ordnung bringen zu wollen. Je länger die Liste ist, desto schlechter ist die Erfolgsquote bei den einzelnen Punkten: Unseren Daten zufolge werden bei Retrospektiven, bei denen zehn oder mehr Maßnahmen festgelegt werden, etwa 56 % davon umgesetzt, gegenüber etwa 79 % bei Retrospektiven, bei denen ein bis drei Maßnahmen festgelegt werden. Beschränken Sie sich auf eine Verbesserung, zu der sich das Team wirklich verpflichtet, nehmen Sie diese in die Arbeit des nächsten Sprints auf, anstatt sie auf dem Board stehen zu lassen, und eröffnen Sie jede Retrospektive mit einer Rückschau auf die eine Maßnahme aus der letzten Sitzung, bevor Sie neue Punkte erarbeiten. Falls diese noch nicht umgesetzt wurde, ist dies das nützlichste Gespräch im Raum. Die Suche nach einem neuen Format ist das Erste, was Teams versuchen, und das, was am wenigsten hilft: „Mad/Sad/Glad“ durch ein Segelboot zu ersetzen, ist nur Kosmetik, wenn die Umsetzung nicht erfolgt.

Zweitens: Hören Sie auf, den Aktionspunkt als das Wesentliche zu betrachten. Dies ist die neue Sichtweise aus Agile Retrospectives, 2. Auflage, auf die sich die gesamte Kategorie zubewegt. Der entscheidende Wandel, den Derby, Larsen und David Horowitz einführen, besteht darin, dass das Lernen – und nicht eine erledigte Aufgabe – das Erfolgskriterium ist. Ersetzen Sie den Aktionspunkt durch ein Experiment: eine Hypothese, die Sie testen („Wenn wir bei der riskanten Story im Pair-Programming arbeiten, reduzieren wir den Nacharbeitsaufwand“), einen Termin zur Überprüfung sowie eine ehrliche Bestandsaufnahme dessen, was tatsächlich geschehen ist. Eine Retrospektive, die zwar keine abhakbaren Maßnahmen hervorgebracht hat, dem Team aber wirklich etwas beigebracht hat, ist keine gescheiterte Retrospektive. Dieser eine Schritt beseitigt die Beschwerde, dass sich „nichts ändert“, denn das Ziel ist nicht mehr eine erledigte Pflichtübung, sondern eine Veränderung, die Sie tatsächlich umsetzen. Johanna Rothman wandte diesen Austausch bereits an, lange bevor er zum Standard in Retrospektiven wurde, und zwar in Create Your Successful Agile Project: ein Punkt, der als Experiment durchgeführt wird, wobei der nächste Arbeitsblock des Teams so gestaltet wird, dass er diesen Punkt einbezieht.

Schweigen ist keine Gleichgültigkeit: Es ist ein Signal.

Ein stiller Misserfolg: das Retrospektive-Meeting, bei dem zwei von acht Personen fünf Minuten lang sprechen und der Rest aus Funkstille besteht – und kein Format und kein vorgefertigtes Board, das Sie ausprobieren, etwas daran ändert. Es ist leicht, dies als ein unengagiertes Team zu interpretieren. Das ist es in der Regel jedoch nicht. Stille in einer Retrospektive ist ein Signal, nicht das Problem an sich: Sie deutet auf fehlendes Vertrauen, einen unklaren Zweck oder ein Führungsproblem hin, das die Teilnehmer nicht laut aussprechen wollen. Die Arbeit im Homeoffice verschlimmert dies noch: Kameras ausgeschaltet, Mikrofone stummgeschaltet, die Stimmung ist gedrückt.

Füllen Sie die Stille nicht mit weiteren Aufforderungen. Wechseln Sie die Reihenfolge, wer als Erster das Wort ergreift. Führen Sie vor jeder Diskussion ein stilles, individuelles Brainstorming durch, damit die Teilnehmer zunächst schreiben, bevor sie sprechen – dies schützt die Introvertierten und diejenigen, die nicht die Ersten sein möchten, die etwas laut aussprechen. Sammeln Sie Beiträge asynchron im Vorfeld. Geben Sie den Teilnehmern die Möglichkeit, einen Haftzettel beizusteuern, ohne diesen vor der gesamten Runde verteidigen zu müssen. Das Ziel ist kein lebhaftes Meeting, sondern ehrliche Daten – und ehrliche Daten kommen oft ganz still und leise zum Vorschein.

Die Sitzungsgebühr ist ein tatsächlicher Kostenfaktor und keine Ausrede

Schließlich gibt es noch die Kritik, die die Anhänger des Mottos „Nie das Retrospektive auslassen“ allzu schnell abtun: Retrospektiven verursachen Kosten. „Es ist ein weiteres Meeting in meinem Kalender, das möglicherweise meine gerade erreichte tiefe Konzentration unterbricht“, schrieb ein Entwickler. Dies kommt zu den Standup-Meetings, der Planung, der Überprüfung und der Verfeinerung noch hinzu. Bei kurzen Zyklen wird die Rechnung gnadenlos: Teams mit einwöchigen Sprints bezeichnen die wöchentliche Planung und Retrospektive als „Belastung“ – und sie haben Recht. Fünfzig Retrospektiven pro Jahr in einem ausgereiften Team sind keine Tugend.

Die Lösung besteht nicht darin, Retros zu überspringen, sondern darin, sie in der richtigen Häufigkeit abzuhalten. Ein neu gebildetes Team, das unter Druck steht, profitiert von einer Retro in jedem Sprint. Ein stabiles Team, das immer wieder dieselben oberflächlichen Gespräche führt, signalisiert Ihnen, dass der Rhythmus falsch ist – nicht, dass die Reflexion wertlos wäre. Wechseln Sie zu zweiwöchentlichen Retrospektiven oder lösen Sie diese durch Ereignisse aus (nach einer Veröffentlichung, nach einem Ausfall, nach einem schwierigen Sprint), wenn es tatsächlich etwas zu besprechen gibt. Die Häufigkeit ist ein Regler, kein Gebot. (Die gleiche Logik der Überlastung zieht sich durch jede Zeremonie: siehe Standup-Anti-Muster und die Lücke bei der Umsetzung in unserem Leitfaden „Agile Theatre“.)

Beheben Sie das Problem mit der Durchsetzungskraft, wahren Sie die Ehrlichkeit, setzen Sie eine konkrete Maßnahme konsequent um und passen Sie das Tempo an – dann ist das Retrospektive-Meeting kein Druckventil mehr. Es wird zu jener einen Stunde pro Sprint, in der das Team tatsächlich seine Arbeitsweise verändert, was ja immer der Sinn der Sache war. Ein Online-Tool für Retrospektiven hilft dabei auf ganz konkrete Weise: Es überträgt jede vereinbarte Änderung als nachverfolgbare Maßnahme, sodass die Umsetzung auch über die Woche nach dem Meeting hinaus Bestand hat.

Häufig gestellte Fragen

Warum ändert sich nach unseren Retrospektiven eigentlich nie etwas?

In der Regel liegt dies daran, dass die wichtigsten Probleme außerhalb des Zuständigkeitsbereichs des Teams liegen und es im Rahmen des Retrospekts keine Möglichkeit gibt, diese weiterzuleiten. Das Board füllt sich mit Problemen, die das Team nicht allein lösen kann (Personalbestand, Abhängigkeiten, eine defekte Bereitstellungs-Pipeline), und alle gehen, nachdem sie lediglich das Wetter beschrieben haben, anstatt es zu ändern. Die Lösung besteht darin, jeden Punkt danach zu priorisieren, wer tatsächlich dafür verantwortlich ist, eine einzige, vom Team kontrollierte Verbesserungsmaßnahme zur Bearbeitung beizubehalten und die Punkte, die außerhalb des Zuständigkeitsbereichs liegen, namentlich mit Angabe eines Verantwortlichen und eines Termins an die nächsthöhere Ebene weiterzuleiten, anstatt sie stillschweigend fallen zu lassen.

Was tun Sie, wenn das eigentliche Problem außerhalb des Einflussbereichs des Teams liegt?

Sie eskalieren das Problem offiziell. Sortieren Sie die Probleme danach, was das Team kontrolliert, worauf es Einfluss nehmen kann und was es lediglich hinnehmen muss (die „Circles and Soup“-Übung aus Agile Retrospectives). Der allgemeine Rat lautet, den äußeren Ring zu ignorieren und in Ihrem Einflussbereich zu bleiben. So wird eine Retrospektive zum Theater. Machen Sie stattdessen aus den Punkten des äußeren Rings eine sichtbare Anfrage (einen „Retrospektive Radiator“), in der das Hindernis, die Auswirkungen und die verantwortlichen Personen benannt werden, und legen Sie diese den Personen vor, die etwas daran ändern können. Eine Retrospektive, die nur Probleme aufzeigt, die das Team ohnehin bereits beheben kann, ist bequem und unehrlich.

Ist es sicher, in einer Retrospektive ehrlich zu sein?

Nur wenn Ehrlichkeit keine negativen Auswirkungen auf die Karriere hat. Entwickler berichten regelmäßig, dass Rückmeldungen aus Retrospektiven in Leistungsbeurteilungen wieder auftauchen – als Beweis dafür, dass sie sich „zu viel beschweren“. Befindet sich die Person, die über Beförderungen entscheidet, im Raum, oder wird das Gesagte für später aufbewahrt, verstummen die Teilnehmer und geben vor, alles sei in Ordnung. Schützen Sie Offenheit bewusst. Halten Sie Vorgesetzte, die für Beförderungen zuständig sind, von der Sitzung fern, vereinbaren Sie, dass das Besprochene im Raum bleibt und nur vereinbarte Maßnahmen nach außen gelangen, und bieten Sie Anonymität für jede einzelne Idee an, anstatt sie pauschal zu gewähren.

Sind Retrospektiven Zeitverschwendung?

Dies ist der Fall, wenn der einzige Erfolgstest eine abgeschlossene Maßnahme ist, denn die meisten Sprints liefern Ihnen keine ordentliche Lösung. Formulieren Sie das Ziel neu. Eine Retrospektive ist dann erfolgreich, wenn das Team etwas lernt, das es in den nächsten Sprint mitnimmt – auch ohne eine abgehakte Maßnahme –, und wenn es ein ehrliches Experiment durchführt, anstatt zehn aufgegebene Aufgaben. Retrospektiven leisten auch stillere Arbeit (das frühzeitige Aufdecken von Spannungen, die Aufrechterhaltung des Teamzusammenhalts), die nie als Aktionspunkt auftaucht, aber dennoch real ist. Werden sie als Lernritual statt als Aufgabenfabrik betrachtet, verdienen sie ihren Platz.