Wieso ich Retros nicht mehr mag

Und was ich daraus gelernt habe…

Retrospektiven gelten als Herzstück agiler Teams – doch was, wenn sie sich nur noch wie ein weiteres Meeting anfühlen? In diesem Artikel schildere ich, wie ich selbst in die Falle der „Retro Fatigue“ getappt bin, welche Muster mir dabei aufgefallen sind und wie wir Retros wieder zu echten Räumen für Verbesserung machen können. 

Beruflich gesprochen bin ich mit agiler Softwareentwicklung groß geworden. Als ich 2017 meine ersten Schritte bei einer großen deutschen Traditionsversicherung machte, waren hippe Agile-Trainingscenter mit Kickertisch und Gratiskaffee sowie der Trend zu autonomen Teams mit mehr Freiheitsgraden selbst dort längst angekommen. Und was soll ich sagen? Vielleicht lag es auch an meiner ersten Führungskraft, die noch eher vom Typ „Excelliste & Rapport-Planung“ war – aber ich war sofort fasziniert von der agilen Denkweise, die motivierte Individuen und ein funktionierendes Produkt in den Mittelpunkt stellt. Vom ersten Tag an hätte ich mich wohl als Agilist bezeichnet – ohne den Begriff überhaupt zu kennen.

Auch heute noch begeistern mich Konzepte wie Modern Agile, und in meinen Projekten übernehme ich gelegentlich agile Rollen. Umso erstaunter war ich, als ich kürzlich feststellte: Ich freue mich nicht mehr auf meine Retrospektive. Im Gegenteil – der zweiwöchentliche Termin fühlte sich zunehmend wie eine lästige Pflichtaufgabe an. Wäre ich als Agile Master nicht qua Rolle der Hüter der Retro gewesen – ich hätte sie wohl abgesagt.

Dabei halte ich es eigentlich mit Woody Zuill, der sagte:

„If you adopt only one agile practice, let it be retrospectives. Everything else will follow.“

Wie konnte es soweit kommen? Wie wurde aus dem vielleicht wichtigsten Ritual der agilen Welt eine Routine, die ich (und vermutlich große Teile des Teams) als wenig wertvoll empfand?

Eins vorweg: Nicht jede Retro war schlecht. Es gab großartige Diskussionen und wertvolle Impulse für Verbesserungen. Und ja, vermutlich habe ich mich im operativen Tagesgeschäft manchmal zu sehr verfangen und Inspect & Adapt nicht immer priorisiert.

Aber dennoch … die Retros fühlten sich oft wie eine Pflichtübung an. Wie kam es zu dieser Retro Fatigue? Und was kann man dagegen tun?

Inspect ohne Adapt

Es beginnt oft leise: Ein Action Item verschwindet in der Jira-Tiefe. Ein anderes bleibt ohne Besitzer. Beim dritten ist unklar, was es eigentlich bedeuten soll. Niemand sagt es laut, aber alle spüren es – da bewegt sich wenig. Die Retro war nicht schlecht, aber auch nicht wirksam. Genau hier entsteht sie: die stille Enttäuschung, die sich Retro für Retro summiert. Und plötzlich fragt man sich: Warum machen wir das eigentlich noch?

Ich glaube, genau dieser Punkt ist der gefährlichste Kipppunkt jeder Retrokultur. Denn auch wenn das Gespräch gut war – wenn aus den Erkenntnissen keine Veränderung entsteht, schlägt Reflexion in Frustration um. Das Team spürt: Wir reden, aber es passiert nichts. Und mit jedem unerledigten Action Item sinkt die Bereitschaft, sich beim nächsten Mal einzubringen.

Die Ursachen dafür sind vielseitig – und meist ganz banal. Maßnahmen werden vage formuliert („Wir sollten mehr aufeinander achten“), bleiben ohne Verantwortliche oder versickern einfach im Alltag. Besonders tückisch: Oft merkt es niemand sofort. Doch wenn es zur Gewohnheit wird, dass auf Retros keine Veränderung folgt, wird aus dem wichtigsten agilen Ritual ein frustrierendes Meeting mit Alibi-Charakter.

Was hilft? Klare, konkrete Maßnahmen – versehen mit Zuständigkeit, Frist und Sichtbarkeit. Und: Mut zur Ehrlichkeit. Wenn ein Thema dem Team nicht wichtig genug ist, um Energie hineinzustecken, dann darf es auch bewusst verworfen werden. Alles andere ist Selbsttäuschung. Und ja, auch als Scrum Master oder Agile Coach sollte man sich nicht reflexartig jedes „verwaiste“ To-do greifen. Denn wenn sich niemand verantwortlich fühlt, ist das oft die deutlichere Botschaft als jede Diskussion.

Nicht zuletzt hilft es, Erfolge auch sichtbar zu machen – und sei es nur ein kleiner Schritt. Denn nichts motiviert mehr als das Gefühl: Wir können etwas verändern.

Anti-Pattern: Inspect-ohne-Adapt

Teams reflektieren regelmäßig, aber ziehen daraus keine konkreten oder nachhaltigen Veränderungen. Maßnahmen bleiben vage, versickern im Alltag oder verschwinden unbeachtet in Jira. Die Retro wird zur Pflichtübung ohne Wirksamkeit.

Typische Sätze:

• „War das nicht schon letztes Mal ein Thema?“
• „Was ist eigentlich aus dem To-do geworden?“
• „Das steht irgendwo in Jira – glaub ich.“

Was tun?

• Maßnahmen konkret formulieren: Wer? Was? Bis wann?
• Verantwortliche und Fristen benennen
• Status regelmäßig reviewen – idealerweise im nächsten Sprint-Planning
• Unerledigte Punkte auch bewusst verwerfen – statt sie weiter mitziehen
• Sichtbare Erfolge schaffen, selbst bei kleinen Verbesserungen

Zu große oder zu heterogene Teams

Wer kennt es nicht? Während beispielsweise der Scrum Guide 3 bis maximal 9 Teammitglieder für ein agiles Team empfiehlt, finden sich in der Realität oft riesige Teams von 10, 15 oder gar über 20 Teammitgliedern. Dies führt nicht nur unweigerlich zu „Teams in Teams“, sondern sorgt auch dafür, dass die Retro sich anfühlt wie ein Meeting-Marathon ohne Fokus. Oft sprechen nur wenige, während sich andere zurücklehnen oder gedanklich ausklinken. Einzelne Stimmen gehen unter oder wiederholen sich. Entscheidungen werden verwässert, Diskussionen enden in Allgemeinplätzen.

In solchen Situationen hilft es, bewusst kleinere Gruppen zu bilden, etwa durch eine Retrospektive in Subteams mit anschließendem Austausch der Erkenntnisse. Auch das Wechseln der Perspektive – etwa durch gezielte Fragestellungen pro Teambereich – kann helfen, mehr Relevanz und Beteiligung zu erzeugen. 

Am Ende lässt sich dieses Problem jedoch nur bedingt im Team lösen: Wenn das Team zu groß ist, um gemeinsam wirklich reflektieren zu können, dann ist das kein Zeichen gegen die Retro – sondern ein klarer Hinweis auf ein organisatorisches Problem. 

Anti-Pattern: Teammarathon statt Teamreflexion

Retros mit zu großen oder heterogenen Gruppen führen zu ermüdenden Diskussionen ohne Fokus. Einige dominieren die Gespräche, andere klinken sich aus – Reflexion wird zur Massenabfertigung.

Typische Sätze:

• „Ich glaube, das Thema betrifft uns gar nicht direkt.“
• „Können wir das mal abkürzen?“
• „Ich hab eh nix beizutragen – die anderen reden schon genug.“

Was tun?

• Große Teams in Subgruppen aufteilen und Ergebnisse konsolidieren
• Themen gezielt nach Team-Bereichen oder Rollen clustern
• Rollen- oder themenspezifische Retros einführen (z. B. Dev-only, UX-only)
• Teamzuschnitt grundsätzlich hinterfragen: Ist das wirklich ein Team?

Retro overload

Während so gut wie alle agilen Events, von Sprintplannung über Daily Standups bis zu Reviews, mehr oder weniger regelmäßig hinterfragt oder zumindest kritisiert werden, scheinen Retrospektiven in den meisten Teams heilig. Und das ist doch gut so, oder?

Immerhin ist Inspect & Adapt der zentrale Gedanke agilen Arbeitens und ich selbst habe Woody Zuills Aussage zur Wichtigkeit von Retrospektiven zu Beginn dieses Artikels zitiert.

Ganz so einfach ist es in meinen Augen dann aber doch nicht. Vermutlich haben die meisten bereits Retros erlebt, an dem die Leute verschlossen, abgelenkt, unmotiviert oder einfach genervt von Gott und der Welt waren. Natürlich kann man hier durch gute Vorbereitung und Moderation sowie einem gemeinsamen Verständnis der Wichtigkeit einer Retrospektive viel erreichen. Aber dennoch glaube ich, manche Retros sind von vornherein zum Scheitern verurteilt.

Vielleicht sind die Teams noch nicht so weit, im vorgesehenen Rhythmus gemeinsam zu reflektieren. Vielleicht fehlt Vertrauen oder sind Verhaltensweisen oder Organisationen so festgefahren, dass Veränderung einfach eine gewisse Zeit brauchen. Es gibt viele Gründe, weswegen Teams zu viele Retros durchführen können. Dabei führen viele Retros eben nicht zu besonders viel Inspect & Adapt, sondern zu kompletten Stillstand. Frei nach Paracelsus: Die Dosis macht das Gift.

Gerade weil Retros so wichtig sind, trauen sich meiner Erfahrung nach die wenigsten Teams oder Coaches wirklich, ihre Retros kritisch zu hinterfragen. Dabei ist genau diese Reflektion zentral, um Meetings wirklich wertvoll zu machen. Und ich lade jedes Team herzlich ein, in der nächsten Retro einmal über den Sinn – und Unsinn der eigenen Retro zu diskutieren.

Anti-Pattern: Zombie-Retros

Retros finden zwar regelmäßig statt, aber ohne Energie, Fokus oder Veränderungswirkung. Das Team kommt pflichtbewusst zusammen, ohne echtes Interesse oder Beteiligung – die Retro lebt nur noch formal weiter.

Typische Sätze:

• „Schon wieder Retro? Haben wir überhaupt Themen?“
• „Lass uns einfach schnell durchziehen.“
• „Ich hab ehrlich gesagt grad keinen Nerv für das Meeting.“

Was tun?

• Retro-Frequenz kritisch mit dem Team reflektieren – Qualität vor Quantität
• Den Retro-Zweck offen thematisieren: Was bringt uns das hier wirklich?
• Temporär pausieren oder Format variieren (z. B. Lean Coffee, Walk & Talk)
• Teams Raum geben, erst Reife und Vertrauen zu entwickeln

Fokus auf den Circle of Concern

Eine Kunst bei Retrospektiven ist es, den Blick über den Tellerrand zu werfen und gleichzeitig vor allem das eigene Verhalten zu reflektieren.

Allzu häufig beobachten wir jedoch eine Fixierung auf den „Circle of Concern“ – also Themen, die zwar die Arbeit des Teams beeinflussen, auf die es aber keinen direkten Einfluss hat. Da wird dann über Tools, die Unternehmensleitung, unklare Strategie oder die Organisation als Ganzes geschimpft. Und ja, manches davon ist durchaus berechtigt – aber selten produktiv.

In Retros geht es vor allem um Selbstwirksamkeit. Um den „Circle of Influence“. Also um die Frage: Was können wir ändern? Wo liegt unser Gestaltungsspielraum? Sich das immer wieder bewusst zu machen und notfalls auch mal freundlich, aber bestimmt zurück auf den Einflussbereich zu lenken, ist eine der wichtigsten Aufgaben eines guten Facilitators.

Manchmal hilft hier ein Perspektivwechsel: Etwa durch gezielte Fragen wie „Was war unser Anteil daran?“ oder „Was würden wir anders machen, wenn wir es allein entscheiden könnten?“ – und manchmal wandelt sich tatsächlich ein Ohnmachtsgefühl in einen konkreten Handlungsspielraum.

Anti-Pattern: Circle-of-Concern-Falle

Das Team diskutiert in der Retro bevorzugt über Probleme außerhalb seines Einflussbereichs – von Managemententscheidungen über schlechte Tools bis hin zur Unternehmensstrategie. Die Reflexion bleibt folgenlos, Frust entsteht.

Typische Sätze:

• „Wenn die da oben endlich mal…“
• „Mit diesem Tool ist doch eh nix zu machen.“
• „Solange die Strategie unklar ist, bringt alles andere auch nix.“

Was tun?

• Klarer Fokus auf den „Circle of Influence“ – was können wir verändern?
• Perspektivwechsel fördern: „Was war unser Anteil daran?“
• Themen außerhalb des Einflussbereichs bewusst parken oder anders adressieren (z. B. Impediment-Backlog, Eskalationskanäle)
• Selbstwirksamkeit betonen und kleine, konkrete Veränderungen sichtbar machen

Infantilisierung von Mitarbeitern und Monotonie

Viele Retros laufen nach einem sehr ähnlichen Muster ab. Zuerst gibt es einen Checkin, um ein gutes Gesprächsklima zu schaffen. Danach werden Eindrücke und Themen aus der vergangenen Iteration gesammelt. Hieraus werden (oftmals priorisiert durch Dot-Voting) Erkenntnisse gemeinsam diskutiert und abgeleitet, bevor sich das Team auf Action Items einigt und die Retro mittels eines Check-Outs abschließt. Auch wenn es hier von Lego-, über Dino- und Superhelden-Retros verschiedenste Flavour gibt und sich die Details sicherlich unterscheiden (und die Unterscheidung sehr sinnvoll sein kann!) fallen doch die meisten Retros in dieses Schema. Und ermüden die Teams. Eigentlich tolle Hilfsmittel, wie der Retromat verstärken ein solches Muster nochmals. 

Natürlich wirkt sich dieser Faktor umso stärker aus, je weniger nachhaltige Ergebnisse die Retros wirklich produzieren (s.o.).

Auch wenn es etwas harsch klingt: Ich habe oftmals das Gefühl, auch im agilen Kontext neigen wir dazu, Kolleginnen und Kollegen zu infantilisieren. Dies beginnt damit, dass Widerstände gegen Change gerne mal mit “fehlendem agilen Mindset” weggewischt werden oder dass wir glauben, dass sich ein Teammitglied schon öffnet, wenn wir ihm schon genügend, auflockernde und teambildende Checkins und Möglichkeiten bieten. Dabei ist es eigentlich eine Grundannahme des agilen, Menschen wie Erwachsene zu behandeln.

Und genau dies ist meiner Erfahrung nach auch der richtige Weg: Das Team dort abholen, wo es startet und etwaige Störgefühle offen ansprechen. Zur Abwechslung auch mal gar keine oder nur eine minimale Struktur für die Retro vorzugeben und in einem offenen Format dem Team den Raum geben, Themen und Optimierungsmöglichkeiten zu besprechen, kann helfen, aus dem Trott auszubrechen. Auch abwechslungsreiche Formate wie ein Pre-Mortem sind in diesem Kontext spannende Werkzeuge.

Anti-Pattern: Schema-F-Retros

Retros laufen stets nach demselben Ablauf ab – Check-in, Themen sammeln, Dot-Voting, Action Items, Check-out – oft ergänzt durch Gamification-Elemente. Die Methoden überlagern die Inhalte, echte Reflexion weicht Routine.

Typische Sätze:

• „Lass mich raten, wieder Dot-Voting?“
• „Können wir den Check-in diesmal weglassen?“
• „Ich weiß schon genau, was gleich kommt.“

Was tun?

• Abwechslung einbauen: neue Formate (z. B. Pre-Mortem, Lean Coffee), offene Diskussion
• Bewusst auf Elemente verzichten – z. B. ganz ohne Miro-Board
• Retro gelegentlich vom Team selbst gestalten lassen
• Struktur der Retro gemeinsam mit dem Team infrage stellen

Anti-Pattern: Feel-Good-Facilitation

Check-ins, Spielchen und Symbolarbeit sollen Teams zum Öffnen bringen – oft auch dann, wenn das eigentliche Problem ein strukturelles oder kulturelles ist. Das Team fühlt sich nicht ernst genommen, echte Themen bleiben unausgesprochen.

Typische Sätze:

• „Sollen wir wieder Superhelden ziehen?“
• „Ich will kein Tier sein, ich hab ein Thema!“
• „Wir spielen hier doch nicht Kindergarten.“

Was tun?

• Erwachsene wie Erwachsene behandeln: echte Themen zulassen
• Störungen ansprechen, statt sie mit Ritualen zu überdecken
• Methoden als Mittel zum Zweck nutzen – nicht als Ziel
• Dem Team zutrauen, auch ohne methodischen Rahmen gut zu arbeiten

Misstrauen (in das Management) 

Ich denke manchmal an Asterix & Obelix, wenn ich manche Teams in ihren Retros beobachte. Da sitzt ein gallisches Dorf zusammen, kämpferisch, eng verbunden, voller Stolz auf die eigene Selbstorganisation. Und draußen lauert das Imperium: das Management, die Enterprise Architekten, die fremdbestimmten Roadmaps. Was als gesunder Schutzmechanismus beginnt, kann schnell zur systemischen Trennung werden.

Besonders in Retros wird dieses Muster sichtbar. Immer wieder kommen dieselben Themen auf: fehlende Entscheidungsspielräume, widersprüchliche Impulse von außen, Tooling, das bremst. Doch je häufiger solche Punkte ohne spürbare Reaktion bleiben, desto mehr verfestigt sich im Team ein Gefühl von: „Die da draußen machen ja doch, was sie wollen.“ Und damit auch: „Dann machen wir hier halt unser Ding.“ Die Retro wird zur Bühne der Selbstvergewisserung – aber nicht mehr zur Brücke nach außen.

Agile Coaches tragen zu dieser Dynamik manchmal ungewollt bei. Indem sie Teams in ihrer Eigenständigkeit stärken, aber gleichzeitig versuchen, sie vor destruktiven oder unklaren Einflüssen von außen zu schützen. Das ist verständlich – aber auch gefährlich. Denn wenn das Team sich nur noch im Inner Circle bewegt, wird Selbstorganisation schnell zu Selbstabschottung. Die Retrospektive verkommt zur Selbstbespiegelung: Immer die gleichen Themen, immer die gleichen Perspektiven, keine echte Weiterentwicklung.

Was hilft? Brücken bauen. Zum Beispiel durch „Retro Reviews“ mit Stakeholdern, durch Eskalationsschleifen mit Feedback-Rückkanal oder durch die bewusste Einbindung von Führungskräften – nicht als Kontrolle, sondern als Dialogpartner. Besonders wichtig ist in diesem Kontext die Rolle des Product Owners – und anderer Personen, die sich in übergreifenden Gremien und Abstimmungen bewegen, auf einer Ebene, die viele als Flight Level 2 bezeichnen würden. Gerade wenn diese Rollen über lange Zeit eng im Team verankert waren, neigen sie dazu, Konflikte zu vermeiden und übernehmen häufig unbewusst die Narrative des Teams als „Good Buddy“. Wenn es ihnen jedoch gelingt, sich aus dieser Sichtweise zu lösen und gezielt Impulse von außen ins Team zu tragen, kann das die Retro wieder öffnen – für neue Perspektiven und echte Veränderung.

Denn ein gallisches Dorf ist stark – aber es muss anschlussfähig bleiben, wenn es nicht irgendwann alleine dastehen will.

Anti-Pattern: Gallisches-Dorf-Reflex

Das Team schottet sich gegenüber äußeren Einflüssen ab, sieht sich als letzte Bastion der Selbstorganisation – während das Umfeld (Management, andere Teams, Architektur) als Bedrohung erlebt wird. Die Retro dient nur noch der internen Selbststärkung.

Typische Sätze:

• „Die da oben verstehen eh nicht, wie wir arbeiten.“
• „Wir müssen uns halt selbst schützen.“
• „Lass uns lieber nichts sagen, sonst mischen die sich wieder ein.“

Was tun?

• Brücken bauen: z. B. durch Retro-Reviews mit Stakeholdern oder Eskalationsfeedback
• Führung als Dialogpartner einladen – nicht als Kontrolle
• Product Owner und andere Flight-Level-2-Rollen gezielt ermutigen, systemische Impulse ins Team zu tragen
• Externe Stimmen punktuell bewusst integrieren (z. B. andere Teams)

Ein kleines Fazit 

Retrospektiven sind ein zentrales Werkzeug agiler Zusammenarbeit – und gleichzeitig anfällig für Abnutzung, Frustration und schleichende Bedeutungslosigkeit. Die in diesem Artikel beschriebenen Symptome von „Retro Fatigue“ habe ich nicht nur beobachtet, sondern teilweise selbst verursacht. Doch genau darin liegt auch eine Chance: Wenn wir den Mut haben, offen über unsere eigenen Routinen zu sprechen, können wir Retrospektiven wieder zu dem machen, was sie sein sollen – Räume für echte Reflexion, lernende Teams und kontinuierliche Verbesserung.

Also was würde ich zukünftig denn nun anders machen? Als allererstes wohl offen mit dem Team sprechen. Und einmal reflektieren, welche Anti-Pattern gerade eigentlich auf uns zutreffen.