"Retrospektiven, die nichts verändern"

Dezember 2025 10 Min. Lesezeit Meinung + Tool-Review

Die Retrospective ist Scrums kraftvollster Mechanismus für organisatorisches Lernen. Sie ist auch die Ceremony, die am konsequentesten zu einer strukturierten Beschwerdesession reduziert wird, die Action Items produziert, auf die niemand reagiert. Das ist kein Facilitation-Problem. Es ist ein strukturelles.

---

Der Einstieg: Dieselben drei Probleme, jeden Sprint

Hier ist ein Test. Suchen Sie die Retrospektiven-Notizen Ihres Teams aus den letzten sechs Sprints. Schauen Sie sich die drei am häufigsten genannten Probleme in jeder einzelnen an. Zählen Sie, wie viele davon in mehr als drei Sprints auftauchen.

In meiner Erfahrung lautet die Antwort meistens: die meisten. Dieselben Kommunikationsprobleme, dieselben Abhängigkeitsprobleme, dieselben Schätzungsherausforderungen, dieselben Reibungen zwischen Teams – sie tauchen auf, werden besprochen, erzeugen Action Items, und tauchen dann unverändert in der nächsten Retrospektive wieder auf. Monat für Monat.

Wenn die Retrospective funktioniert, ist sie der Motor der kontinuierlichen Verbesserung. Wenn sie nicht funktioniert – wenn dieselben Probleme immer wieder ohne Lösung auftauchen – ist sie schlimmer als nutzlos. Sie ist ein Beweis dafür, dass das Ansprechen von Problemen nirgendwohin führt. Teams, die diese Lektion lernen, hören auf, echte Probleme anzusprechen. Sie sprechen stattdessen sichere an. Die Retrospektive wird zum Komfortritual statt zum Veränderungsmechanismus.

---

Die Realität: Warum Retrospektiven aufhören zu funktionieren

Grundursache 1: Action Items ohne Eigentümer oder Deadlines

Das mechanischste Versagen. Die Retrospektive identifiziert fünf Probleme und erzeugt fünf Action Items. Jedes Action Item wird auf der Confluence-Seite des Teams oder auf einem Haftnotiz-Zettel an der Wand festgehalten. Niemand ist konkret für eines davon verantwortlich. Es gibt keine Deadline. Bei der nächsten Retrospektive liest der Scrum Master sie vor. Eines wurde teilweise angegangen. Vier wurden nicht angetastet. Fünf neue Action Items werden erzeugt.

Das ist kein Retrospektiven-Problem. Es ist ein Nachverfolgungsproblem, das sich durch Retrospektiven ausdrückt. Die Lösung ist brutal in ihrer Schlichtheit: maximal ein Action Item pro Retrospektive. Ein Eigentümer. Ein konkretes, messbares Ergebnis. Überprüft zu Beginn der nächsten Retrospektive, bevor irgendetwas anderes besprochen wird.

Teams widersetzen sich dem, weil es sich anfühlt, als würde Fortschritt begrenzt. In Wirklichkeit erzeugen fünf unerledigte Items weniger Verbesserung als ein abgeschlossenes. Die Einschränkung erzwingt Priorisierung. Priorisierung erzwingt Verantwortlichkeit. Verantwortlichkeit produziert Veränderung.

Grundursache 2: Das Team hat keine Autorität, das Problem zu lösen

Das ist das strukturelle Problem, auf das der Titel verweist. Viele der Probleme, die in Retrospektiven auftauchen, liegen nicht im Einflussbereich des Teams. Sie betreffen andere Teams, andere Abteilungen, Management-Entscheidungen, organisatorische Richtlinien oder Ressourcenbeschränkungen. Das Team kann sie identifizieren, besprechen und Action Items dafür erzeugen. Lösen kann es sie nicht.

Wenn ein Team wiederholt ein Impediment anspricht, das organisatorische Autorität zur Lösung erfordert, und dieses Impediment wiederholt ungelöst bleibt, passiert eines von zwei Dingen: Entweder wird das Impediment nicht effektiv eskaliert, oder es wird eskaliert und ignoriert. Beides ist schädlich. Ersteres ist ein Scrum-Master-Problem. Letzteres ist ein organisatorisches Problem, das kein Retrospektiven-Format adressieren kann.

Die Autoritäts-Diagnose: Kategorisieren Sie Ihre letzten zehn Retrospektiven-Action-Items. Wie viele lagen im direkten Einflussbereich des Teams? Wie viele erforderten Handeln von jemandem außerhalb des Teams? Für die externen – was ist passiert? Wenn das Muster “angesprochen, vermerkt, ungelöst” lautet – identifiziert Ihre Retrospektive organisatorische Impediments, die Ihre Organisation sich entschieden hat, nicht anzugehen. Das ist kein Retrospektiven-Problem.

Grundursache 3: Unzureichende Psychological Safety

Teams besprechen sichere Probleme in Retrospektiven und halten die echten Probleme privat. Die echten Probleme betreffen zwischenmenschliche Konflikte, Performance-Bedenken, Managementverhalten oder organisatorische Dysfunktion, die sich zu riskant anfühlt, um sie in einer Gruppenumgebung anzusprechen. Die Retrospektive produziert eine ordentliche Liste von Prozessverbesserungen, während die eigentlichen Quellen der Team-Dysfunktion unangetastet bleiben.

Das ist die schwierigste Grundursache anzugehen, weil sie etwas erfordert, das keine Facilitation-Technik erzeugen kann: einen echten Glauben daran, dass das Ansprechen schwieriger Themen zu produktiven Ergebnissen statt zu persönlichen Konsequenzen führt. Dieser Glaube entsteht über Zeit durch konsequentes, demonstriertes Führungsverhalten – nicht durch Spielregeln, die zu Beginn einer Retrospektive auf ein Whiteboard geschrieben werden.

Grundursache 4: Format-Fetischismus

Die agile Retrospektiven-Industrie hat eine außerordentliche Vielfalt von Formaten hervorgebracht. Sailboat, Starfish, 4Ls (Liked, Learned, Lacked, Longed For), Timeline, Happiness Radar, DAKI (Drop, Add, Keep, Improve), Speed Car, Hot Air Balloon. Scrum Master rotieren durch diese Formate auf der Suche nach jenem, das bessere Ergebnisse produziert.

Das Format ist nicht das Problem. Ich habe das einfachste Start/Stop/Continue-Format profunde Team-Gespräche produzieren sehen. Ich habe aufwendig, wunderschön facilitierte Sailboat-Retrospektiven gesehen, die nichts Substanzielles produzierten. Das Format schafft den Rahmen. Was ihn füllt, hängt von der Psychological Safety des Teams, dem Können des Facilitators und – am wichtigsten – davon ab, ob frühere Retrospektiven-Ergebnisse tatsächlich Veränderung produziert haben.

Teams, die gelernt haben, dass Retrospektiven nichts ändern, werden durch ein neues Format nicht neu engagiert. Sie werden die Bewegungen des neuen Formats mit demselben Grad an echtem Einsatz vollziehen, den sie den vorherigen entgegengebracht haben.

“Eine Retrospektive ist nur so kraftvoll wie die Bereitschaft der Organisation, auf das zu reagieren, was sie produziert. Ohne diese Bereitschaft ist das ausgefeilteste Retrospektiven-Format eine aufwendige Art, Zeit zu verschwenden.” Markus – agile-checksum.com

---

Der Checksum: Was der Scrum Guide sagt – und was nicht

Der Scrum Guide beschreibt den Zweck der Retrospektive klar: zu inspizieren, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und ihre Definition of Done verlaufen ist, und die wichtigsten Verbesserungen zu identifizieren.

Zwei Wörter in dieser Beschreibung sind es wert, betont zu werden: wichtigsten. Nicht alle Verbesserungen. Die wichtigsten. Der Scrum Guide erkennt implizit an, dass ein Team nicht alles gleichzeitig verbessern kann. Er bittet Teams, ihre Verbesserungsbemühungen zu priorisieren – die eine oder zwei Änderungen zu identifizieren, die die größte Wirkung haben, und sich auf diese zu konzentrieren.

Die meisten Retrospektiven machen das Gegenteil. Sie erzeugen umfassende Listen von allem, was besser sein könnte, und handeln dann bei keinem davon, weil es zu viel ist und keine klare Priorität unter den Items besteht.

Wie gute Retrospektiven-Ergebnisse aussehen

Effektives Retrospektiven-Ergebnis	Ineffektives Retrospektiven-Ergebnis
Eine oder zwei spezifische, umsetzbare Verbesserungen	Fünf bis zehn Action Items unterschiedlicher Spezifität
Namentlich genannter Eigentümer für jedes Action Item	”Das Team” als Eigentümer
Klare Definition, wie “fertig” für die Maßnahme aussieht	Vage Action Items mit Interpretationsspielraum
Überprüfung zu Beginn der nächsten Retrospektive, als erstes Item	Überprüfung passiert manchmal, manchmal nicht
Eskalationsplan für Items außerhalb der Team-Autorität	Items außerhalb der Team-Autorität werden vermerkt und vergessen

---

Praxisbeispiele

Die siebenundvierzig Action Items

Zu Beginn dieses Blogs erwähnte ich ein Team mit siebenundvierzig Retrospektiven-Action-Items, die über zwölf Monate angesammelt worden waren, sechs davon abgeschlossen. Dieses Team ist es wert, hier zurückzukehren, weil die Diagnose aufschlussreich war.

Als ich die Action Items im Detail durchging, fand ich drei Kategorien. Die erste Kategorie – etwa 30 % – waren Items, zu deren Bearbeitung das Team echte Autorität hatte und die es schlicht nicht priorisiert hatte. Die zweite Kategorie – etwa 50 % – erforderte Handeln von jemandem außerhalb des Teams: eine Abhängigkeitslösung, eine Management-Entscheidung, eine Prozessänderung in einer anderen Abteilung. Die dritte Kategorie – etwa 20 % – waren Items so vage, dass niemand sie hätte umsetzen können. “Kommunikation verbessern” tauchte viermal auf.

Das Team hatte Action Items erzeugt, ohne zwischen diesen Kategorien zu unterscheiden. Es behandelte “wir haben das Problem identifiziert” als gleichwertig mit “wir gehen das Problem an.” Das tat es nicht. Die Retrospektive war zu einer Dokumentationsübung statt zu einem Veränderungsmechanismus geworden.

Die Retrospektive, die alles veränderte

Ich möchte ein Beispiel einer Retrospektive einschließen, die wie beabsichtigt funktionierte, weil das Muster lehrreich ist.

Ein Team, das ich coachte, kämpfte mit einem hartnäckigen Qualitätsproblem – einer hohen Rate von Bugs, die die Produktion erreichten, obwohl es eine Definition of Done gab, die Testanforderungen beinhaltete. Das Problem war in drei aufeinanderfolgenden Retrospektiven angesprochen worden. Action Items waren erzeugt worden. Nichts hatte sich geändert.

In der vierten Retrospektive änderte ich den Ansatz. Statt Action Items zu erzeugen, verbrachten wir die gesamte Session damit, eine Ursachenanalyse an einem einzigen spezifischen Beispiel durchzuführen: einem Bug, der vor zwei Sprints die Produktion erreicht hatte, und verfolgten rückwärts jede Entscheidung und jeden Prozessschritt, der dies ermöglicht hatte. Wir verwendeten einen Five-Whys-Ansatz und folgten dem Faden, wohin er auch führte.

Was wir fanden, war nicht das, was irgendjemand erwartet hatte. Der Bug hatte die Produktion nicht wegen unzureichender Tests erreicht, sondern weil ein Entwickler eine Story unter Zeitdruck am Ende eines Sprints als fertig markiert hatte, obwohl er wusste, dass eines der Definition-of-Done-Kriterien nicht erfüllt worden war. Er hatte das getan, weil das Team im Sprint Planning konsequent zu viel committed hatte und er sich nicht in der Lage gefühlt hatte, die Bedenken zu äußern, ohne als Engpass zu erscheinen.

Die Grundursache war kein Testproblem. Es war ein Psychological-Safety-Problem, das sich als Qualitätsproblem manifestierte. Die Lösung erforderte zwei Gespräche: eines mit dem Team über zu viel Commitment im Sprint Planning, und eines mit dem Scrum Master darüber, Raum zu schaffen, in dem Bedenken ohne Konsequenzen geäußert werden können. Die Definition of Done wurde nicht geändert. Das Verhalten darum herum schon.

Diese Retrospektive dauerte neunzig Minuten und produzierte zwei Action Items, beide mit namentlich genannten Eigentümern und konkreten Ergebnissen. Beide wurden innerhalb des folgenden Sprints abgeschlossen. Die Bug-Rate sank in den nächsten zwei Monaten um 60 %.

---

Ein Tool-Review: Was tatsächlich hilft

Da dieser Artikel als Meinung + Tool-Review kategorisiert ist, hier eine ehrliche Bewertung der Retrospektiven-Tools und -Ansätze, die ich wirksam – und nicht wirksam – gesehen habe.

Was funktioniert

• Five Whys: Kraftvoll für echte Ursachenanalyse bei spezifischen, konkreten Problemen. Erfordert einen erfahrenen Facilitator, um zu verhindern, dass es zirkulär wird. Nicht für jede Retrospektive geeignet – verwenden Sie es, wenn Sie ein hartnäckiges Problem haben, das oberflächliche Diskussion nicht gelöst hat.
• Pre-Mortem: Sich vorstellen, dass der nächste Sprint katastrophal gescheitert ist, und rückwärts arbeiten, um zu identifizieren, was ihn verursacht hat. Hervorragend geeignet, um Bedenken ans Licht zu bringen, die Teammitglieder zögerlich sind, direkt anzusprechen. Schafft psychologische Distanz zur tatsächlichen Team-Dynamik.
• Team-Health-Checks: Regelmäßige, leichtgewichtige Bewertungen von Team-Gesundheitsdimensionen – Klarheit, Vertrauen, Zusammenarbeit, Lernen. Nützlich für die Verfolgung von Trends über Zeit statt für die Identifizierung spezifischer Maßnahmen. Das Spotify-Squad-Health-Check-Modell ist ein vernünftiger Ausgangspunkt.

Was nicht funktioniert (wie versprochen)

• Rotierende Formate um ihrer selbst willen: Wenn das Team nicht engagiert ist, wird ein neues Format das nicht beheben. Erst das Engagement-Problem angehen.
• Anonyme Eingabe-Tools: Nützlich für Umgebungen, in denen Psychological Safety wirklich niedrig ist. Kein Ersatz für die Lösung des Psychological-Safety-Problems selbst. Wenn Ihr Team nur ehrlich sein kann, wenn es anonym ist, haben Sie ein Kulturproblem, das Anonymität maskiert statt behebt.
• Happiness-Metriken als Hauptergebnis: “Das Team hat seine Zufriedenheit in diesem Sprint mit 3,2 von 5 bewertet, gegenüber 3,6.” Das ist ein nachlaufender Indikator für etwas. Was dieses Etwas ist, erfordert Untersuchung. Verwechseln Sie Messung nicht mit Erkenntnis.

---

Das Fazit: Die Retrospektive ist ein Spiegel und ein Vertrag

Die Retrospektive tut zwei Dinge gleichzeitig. Sie spiegelt die aktuelle Realität des Teams wider – seine Beziehungen, seine Prozesse, sein Vertrauensniveau untereinander und mit der Organisation. Und sie schafft einen Vertrag: eine Verpflichtung zu konkreten Änderungen, die den nächsten Sprint besser machen als den letzten.

Wenn sie aufhört, ein Vertrag zu sein – wenn Action Items erzeugt und nicht umgesetzt werden, wenn dieselben Probleme wiederholt ohne Lösung auftauchen – hört sie auf, eine Retrospektive zu sein. Sie wird zu einer geplanten Enttäuschung, die Teams lehrt, dass das Ansprechen von Problemen nirgendwohin führt.

Führen Sie den Checksum für Ihre Retrospektive durch:

1. Nennen Sie eine konkrete Veränderung in den Arbeitspraktiken Ihres Teams, die direkt aus einer Retrospektive in den letzten drei Monaten resultierte.
2. Wie viel Prozent der Retrospektiven-Action-Items aus Ihren letzten fünf Sprints wurden abgeschlossen?
3. Werden die in Ihren Retrospektiven besprochenen Probleme mit der Zeit kleiner, oder tauchen dieselben grundlegenden Probleme immer wieder auf?

Wenn die Probleme wiederkehren, scheitert die Retrospektive nicht. Sie meldet akkurat, dass die Organisation sich nicht verändert. Das sind verschiedene Probleme mit verschiedenen Lösungen.

---

Im Artikel verwendete Glossarbegriffe

• Retrospective – Eine Scrum-Ceremony zur Inspektion des Sprintverlaufs und zur Identifizierung der wichtigsten Verbesserungen.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, im Team zwischenmenschliche Risiken einzugehen.
• Definition of Done – Die gemeinsame Vereinbarung, was “fertig” für ein Produktinkrement bedeutet.
• Scrum Master – Die Scrum-Verantwortlichkeit für die Etablierung von Scrum und den Dienst am Team.
• Sprint – Eine feste Timebox von 1–4 Wochen, in der ein Scrum-Team ein potenziell auslieferbares Increment liefert.