Warum Retrospektiven scheitern (und wie Sie Ihre Retrospektive sinnvoll gestalten können)

Ihr Team führt in jedem Sprint eine Retrospektive durch. Die Teilnehmer erscheinen, heften ihre Haftnotizen an, nicken bei zwei oder drei Aktionspunkten und gehen wieder. Dann ändert sich nichts daran, wie die Arbeit tatsächlich abläuft. Wenn Sie das vierzig Mal im Jahr tun, haben Sie keine Gewohnheit der Verbesserung aufgebaut. 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 fehlgeschlagene Retrospektive als Moderationsproblem: Wechseln 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 Anti-Muster bei Retrospektiven 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 Ingenieure 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 diese wird in unserem eigenen Beitrag zu Anti-Mustern falsch interpretiert. 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 wird zu einem Druckventil: Das Team darf sich äußern, 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 dafür die Schuld 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“-Beispiel 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 verschleiern, um die Gesprächsatmosphäre angenehm zu halten. Verfolgen Sie stattdessen einen strengeren Ansatz. Sortieren Sie jedes Problem danach, wer tatsächlich dafür verantwortlich 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. Auflage). 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 ohne die Zustimmung anderer vornehmen kann – 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 in Retrospektiven 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 darauf hingewiesen wurde, dass ich mich ‚zu viel beschwere‘“. 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-Horten“: ehrliche Rückmeldungen, die gesammelt und später gegen Sie verwendet werden – und der schnellste Weg, eine Retrospektive zunichte zu machen. 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 dann 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“ hat ergeben, dass psychologische Sicherheit der wichtigste Prädiktor für die Teameffektivität ist; die bloße Anwesenheit eines Managers 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 Moderationskniff 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 heikle Themen ans Licht; wird sie jedoch als dauerhafte Krücke genutzt, untergräbt sie das Vertrauen, das Sie aufzubauen versuchen. Lassen Sie die Nutzer selbst entscheiden, bei welchem Beitrag Anonymität erforderlich ist.
• Seien Sie vorsichtig beim Einbeziehen 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-Ratschmechanik“ geschaffen, und die Mitarbeiter optimieren die Zahl, anstatt die Wahrheit zu sagen. Dies ist der kritische Fehlermodus, der Offenheit in Leistungsdruck verwandelt.

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

Nehmen wir einmal an, die Probleme hinsichtlich der Leistungsfähigkeit und Sicherheit seien gelöst. Dennoch scheitern Retrospektiven an der am häufigsten vorgebrachten 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 Problem wird nicht angegangen“) ist genau das, wie sich Retrospektiven, die sich wie der „Tag der Murmeltiere“ anfühlen, von innen heraus anhören. Das ist keine Einbildung: Die Zahl, die jeder wiederholt – eine häufig zitierte Angabe, wonach nur etwa ein Drittel der Teams ihre Retrospektiven-Maßnahmen konsequent umsetzt –, stellt die Lage letztlich düsterer dar, als sie tatsächlich ist. Wir haben anhand von Hunderttausenden realer Maßnahmen ermittelt, wie viele Aktionspunkte aus Retrospektiven tatsächlich umgesetzt werden: Die Umsetzungsquote liegt näher bei drei von vier, und die Regelmäßigkeit sowie die Verantwortlichkeit entscheiden darüber, auf welcher Seite dieser Kluft ein Team landet. Was die gängige Meinung jedoch richtig erfasst, ist die Art des Scheiterns. Eine Maßnahme, für die niemand die Verantwortung übernimmt, ohne festgelegten Termin und in einem Team ohne Rhythmus – genau diese wird auf das Whiteboard geschrieben und wieder gelöscht.

Zwei Korrekturen, wobei die zweite die wichtigste ist.

Zunächst einmal: Hören Sie auf, alles in Ordnung bringen zu wollen. Je länger die Liste ist, desto schlechter wird die Umsetzung der einzelnen Punkte: Unseren Daten zufolge werden bei Retros, die mit zehn oder mehr Maßnahmen enden, etwa 56 % davon umgesetzt, gegenüber etwa 79 % bei Retros, die mit ein bis drei Maßnahmen enden. 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 der Tafel stehen zu lassen, und beginnen Sie jede Retrospektive damit, die eine Maßnahme aus der letzten Sitzung zu überprüfen, bevor Sie neue Punkte formulieren. Falls diese nicht umgesetzt wurde, ist dies das nützlichste Gespräch im Raum. Das Streben nach einem neuen Format ist das Erste, was Teams versuchen, und das, was am wenigsten hilft: „Mad/Sad/Glad“ gegen ein Segelboot auszutauschen, ist nur Augenwischerei, wenn die Umsetzung nicht erfolgt.

Zweitens: Hören Sie auf, den Aktionspunkt als das Wesentliche zu betrachten. Dies ist die neue Sichtweise aus der 2. Auflage von „Agile Retrospectives“, auf die sich die gesamte Branche zubewegt. Der entscheidende Wandel, den Derby, Larsen und David Horowitz einführen, besteht darin, dass Lernen – und nicht eine erledigte Aufgabe – das Erfolgskriterium ist. Ersetzen Sie die Aktionsaufgabe durch ein Experiment: eine Hypothese, die Sie testen („Wenn wir bei der risikobehafteten Story im Pair-Programming arbeiten, reduzieren wir den Nacharbeitsaufwand“), einen Termin für die Überprüfung sowie eine ehrliche Bestandsaufnahme dessen, was tatsächlich geschehen ist. Eine Retrospektive, die 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 lange bevor er zum Standard in Retrospektiven wurde in ihrem Buch Create Your Successful Agile Project an: 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 stilleres Scheitern: die Retrospektive, bei der 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 Beteiligten 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 erst 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 im Stillen 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 auf das Retrospektive verzichten“ allzu schnell beiseite wischen: 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 Standups, Planung, Review und Verfeinerung noch hinzu. Bei kurzen Sprints wird die Rechnung brutal: Teams mit einwöchigen Sprints bezeichnen die wöchentliche Planung und Retrospektive als „Belastung“ – und sie haben Recht. Fünfzig Retros pro Jahr in einem ausgereiften Team sind keine Tugend. Die gleiche Kritik taucht auf Organisationsebene in der Forschung zur Besprechungsbelastung auf, wo der Anteil der Besprechungen, die die Befragten nach eigener Aussage hätten auslassen können, gemessen statt geschätzt wird.

Die Lösung besteht nicht darin, Retros auszulassen, sondern darin, sie in angemessener Form durchzuführen. 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 Energie, 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 in die Zukunft, 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 Retrospektive keine Möglichkeit gibt, diese an die zuständige Stelle weiterzuleiten. Das Board füllt sich mit Problemen, die das Team nicht allein lösen kann (Personalengpässe, Abhängigkeiten, eine defekte Deployment-Pipeline), und am Ende haben alle lediglich das Wetter beschrieben, anstatt es zu ändern. Die Lösung besteht darin, jeden Punkt danach zu sortieren, 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 nach oben zu eskalieren, 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 kontrollieren kann, 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. Auf diese Weise 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 denjenigen 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 beruflichen Nachteile nach sich zieht. 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 über Beförderungen entscheiden, 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 auf Ideenebene an, anstatt sie als „Alles-oder-Nichts“-Modus zu handhaben.

Sind Retrospektiven Zeitverschwendung?

Dies ist der Fall, wenn der einzige Erfolgstest eine abgeschlossene Aufgabe 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 Aufgabe, die abgehakt werden kann –, und wenn es ein ehrliches Experiment durchführt, anstatt zehn aufgegebene To-dos. Retrospektiven leisten auch stillere Arbeit (das frühzeitige Aufdecken von Spannungen, die Aufrechterhaltung des Teamzusammenhalts), die niemals als Aktionspunkt auftaucht, aber dennoch real ist. Wenn man sie als Lernritual statt als Aufgabenfabrik betrachtet, verdienen sie ihren Platz.