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 die Pinnwand, nicken bei zwei oder drei Aktionspunkten und gehen wieder. An der Art und Weise, wie die Arbeit tatsächlich erledigt wird, ändert sich jedoch nichts. Wenn Sie das vierzig Mal im Jahr tun, haben Sie keine Gewohnheit der Verbesserung aufgebaut – Sie haben eine Gewohnheit entwickelt, über Verbesserung 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-konformere 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, denn genau diese sind es, die erfahrene Entwickler dazu bringen, Retrospektiven als Zeitverschwendung zu bezeichnen: ein Macht-Problem und ein Umsetzungs-Problem. Kein Icebreaker kann hier Abhilfe schaffen.

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, oder eine Frist, die drei Ebenen höher festgelegt wurde –, tatsächlich außerhalb der Befugnisse des Teams liegen, sie zu beheben. Wie ein Entwickler 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 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 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. Aufl.) – und 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, bei 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 in 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 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-Banking – ehrliches Feedback, das gesammelt und später gegen Sie verwendet wird – und es ist der schnellste Weg, eine Sprint-Retrospektive zunichte zu machen. Der Scrum Guide beschreibt die Sprint-Retrospektive als die Selbstreflexion des Scrum-Teams. Verstehen 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 Projekt „Aristoteles“ ergab, dass psychologische Sicherheit der wichtigste Prädiktor für die Teameffektivität ist; die bloße Anwesenheit eines Vorgesetzten reicht oft schon aus, um diese zu untergraben. (Wir behandeln die Mechanismen 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, gelangen nach außen. 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 welchen Beiträgen Anonymität erforderlich ist.
• Seien Sie vorsichtig bei der Einführung von Kennzahlen. Objektive Daten (Velocity, Zykluszeit) gehören in ein Retrospektive – 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 bei der Umsetzung – und die neue Sichtweise, die Abhilfe schafft

Nehmen wir einmal an, die Probleme hinsichtlich der Leistungsfähigkeit und Sicherheit seien gelöst. Retrospektiven scheitern dennoch an der am häufigsten geäußerten Kritik in der gesamten Diskussion: „Retrospektiven bieten zwar die Möglichkeit, Bedenken zu äußern, aber aus diesen Bedenken wird nie wirklich etwas.“ Oder, noch deutlicher ausgedrückt: „Ich habe noch nie gesehen, dass außer Worten etwas passiert ist.“ Der resignierte Unterton – „dieses Problem 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: Laut einer häufig zitierten Zahl der Scrum Alliance setzt nur etwa ein Drittel der Teams ihre aus Retrospektiven resultierenden Maßnahmen konsequent um. Der Rest wird auf ein Whiteboard geschrieben und wieder gelöscht. Die gängige Meinung übertreibt die düstere Lage jedoch – wir haben anhand von Hunderttausenden realer Maßnahmen gemessen, wie viele Aktionspunkte aus Retrospektiven tatsächlich umgesetzt werden,/guides/follow-through-index/ und die Umsetzungsquote liegt näher bei drei von vier Fällen, wobei die Häufigkeit der Durchführung und die Übernahme von Verantwortung darüber entscheiden, auf welcher Seite dieser Spanne ein Team landet.

Zwei Korrekturen, wobei die zweite die wichtigere ist.

Zunächst einmal: Hören Sie auf, alles auf einmal in Ordnung bringen zu wollen. Eine Retrospektive, bei der zehn Aktionspunkte festgelegt werden, führt zu keiner einzigen Umsetzung. Beschränken Sie sich auf eine Verbesserung, zu der sich das Team wirklich verpflichtet, und beginnen Sie jede Retrospektive damit, die eine Maßnahme aus der letzten Sitzung zu überprüfen, bevor Sie neue Punkte festlegen. Falls diese noch nicht umgesetzt wurde, ist dies das nützlichste Gespräch im Raum. Der Versuch, ein neues Format einzuführen, ist das Erste, was Teams versuchen, und das, was am wenigsten hilft – „Mad/Sad/Glad“ durch ein Segelboot zu ersetzen, ist reine Kosmetik, wenn die Umsetzung nicht stimmt.

Zweitens – und dies ist die neue Sichtweise aus Agile Retrospectives, 2. Auflage, auf die sich die gesamte Kategorie zubewegt – hören Sie auf, den Aktionspunkt als das Wesentliche zu betrachten. 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 die Aktionspunkte durch ein Experiment: eine Hypothese, die Sie testen („Wenn wir bei der risikobehafteten Story im Pair-Programming arbeiten, reduzieren wir den Nacharbeitsaufwand“), einen Termin zur Überprüfung sowie eine ehrliche Bestandsaufnahme dessen, was tatsächlich geschehen ist. Ein Retrospektive, die keine abgehakbaren 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 Aufgabe, sondern eine Veränderung, die Sie tatsächlich umsetzen.

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 keine vorgefertigte Tabelle, die 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. Bei Remote-Meetings wird dies noch verschlimmert: 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 ganz still und leise zum Vorschein.

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

Schließlich gibt es noch einen Kritikpunkt, den die Anhänger des Mottos „Nie auf die Retrospektive verzichten“ 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 – zusätzlich zu Stand-up, Planung, Review und Verfeinerung. Bei kurzen Sprints 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 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 den Rhythmus an – dann ist die Retrospektive kein Druckventil mehr. Sie 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 Retrospekts 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 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 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“-Methode 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“ –, der das Hindernis, die Auswirkungen und die verantwortlichen Personen benennt, 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 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 dies als „Alles-oder-Nichts“-Modell zu handhaben.

Sind Retrospektiven Zeitverschwendung?

Dies ist der Fall, wenn der einzige Erfolgstest eine erledigte Aufgabe ist, denn die meisten Sprints liefern Ihnen keine ordentliche solche. 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 abgehaktete Aufgabe, und wenn es ein ehrliches Experiment durchführt, anstatt zehn aufgegebene To-dos. Retrospektiven leisten zudem stillere Arbeit – sie decken Spannungen frühzeitig auf und sorgen für den Zusammenhalt im Team –, die sich zwar nie als Aktionspunkt manifestiert, aber dennoch real ist. Wenn man sie als Lernritual statt als Aufgabenfabrik betrachtet, haben sie ihren Platz verdient.