Wieso ich Retros nicht mehr mag

Und was ich daraus gelernt habe…

Seit 2017 bin ich in der IT unterwegs. Ich bin quasi mit agilen Methoden aufgewachsen – Scrum, Kanban, SAFe, alles dabei. Am Anfang fand ich das faszinierend: Teams, die sich selbst organisieren, kontinuierlich verbessern, gemeinsam wachsen. Die Retrospektive war für mich das Herzstück davon. Der Ort, an dem echte Veränderung passiert.

Und dann, irgendwann, schlich sich ein Gefühl ein:

Ich freue mich nicht mehr auf meine Retrospektive.

Nicht weil ich das Format grundsätzlich ablehne. Sondern weil sich etwas verändert hatte – schleichend, kaum merkbar. Die Retro fühlte sich an wie ein weiteres Meeting. Pflicht statt Impuls. Routine statt Reflexion.

“

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

Dieses Zitat hat mich jahrelang begleitet. Und ich glaube immer noch daran – im Prinzip. Aber ich habe gelernt, dass zwischen dem Ideal und der Realität sechs ziemlich hartnäckige Anti-Patterns liegen.

---

Die sechs Anti-Patterns

1. Inspect ohne Adapt

Das Problem: Das Team reflektiert brav, sammelt Erkenntnisse, formuliert Action Items – und dann passiert nichts. Die Items landen in Jira, verstauben dort, und beim nächsten Mal fängt man von vorne an. Inspect ohne Adapt.

Der Kern: Jedes ungelöste Action Item reduziert die Bereitschaft, sich beim nächsten Mal wirklich einzubringen. Warum sollte ich offen über Probleme sprechen, wenn sowieso nichts passiert? Es entsteht eine schleichende Resignation – und die ist für ein Team toxischer als jedes konkrete Problem.

Wege raus:

• Konkret formulieren: Nicht „Kommunikation verbessern”, sondern „Max spricht bis Freitag mit dem PO über die Akzeptanzkriterien.”
• Status-Review: Die ersten fünf Minuten jeder Retro gehören den offenen Items der letzten Runde. Was wurde erledigt? Was nicht? Warum nicht?
• Bewusst verwerfen: Nicht jedes Item muss abgearbeitet werden. Manchmal ist ein ehrliches „Wir lassen das fallen” besser als endloses Mitschleppen.
• Kleine Erfolge feiern: Wenn ein Action Item tatsächlich etwas verändert hat – benennen, würdigen, sichtbar machen.

2. Zu große oder zu heterogene Teams

Das Problem: 10, 12, 15 Leute in einem Raum. Ein Facilitator versucht verzweifelt, alle einzubinden. Am Ende haben drei Leute geredet, der Rest hat höflich genickt oder am Laptop gearbeitet.

Der Kern: Ab einer gewissen Gruppengröße kippt die Dynamik. Introvertierte verstummen, die üblichen Verdächtigen dominieren, und die Diskussionen bleiben an der Oberfläche. Echte Offenheit entsteht in kleinen, vertrauten Runden – nicht in Großveranstaltungen.

Wege raus:

• Subgruppen bilden: Breakout-Sessions von 3–5 Personen, die anschließend ihre Erkenntnisse teilen.
• Nach Thema oder Rolle clustern: Manchmal braucht das Backend-Team eine andere Retro als das Frontend-Team.
• Rollenspezifische Retros: Nicht jeder muss bei jeder Retro dabei sein. Manchmal ist eine Retro nur für die Devs, manchmal nur für PO und Scrum Master sinnvoll.
• Teamgröße hinterfragen: Wenn die Retro zu groß ist, ist vielleicht das Team zu groß.

3. Retro Overload – Zombie-Retros

Das Problem: Alle zwei Wochen, pünktlich am Sprintende, findet die Retro statt. Egal ob es etwas zu besprechen gibt oder nicht. Das Team sitzt da, geht das Schema durch, produziert pflichtbewusst Post-its – und alle wissen: Das hier ist eine Zombie-Retro. Lebendig sieht anders aus.

Der Kern: Die Dosis macht das Gift. Retrospektiven funktionieren, wenn sie einem echten Bedürfnis entspringen. Zu häufige, ritualisierte Retros ohne Anlass erzeugen Meeting-Müdigkeit und entwerten das Format.

Wege raus:

• Frequenz kritisch hinterfragen: Muss es wirklich alle zwei Wochen sein? Vielleicht reicht monatlich – oder nach besonderen Events (Release, Krise, Teamwechsel).
• Retro-Pause: Bewusst eine Retro ausfallen lassen und schauen, ob das Team sie vermisst. Wenn nicht – war sie überflüssig.
• Formate variieren: Lean Coffee, Walk & Talk, eine Retro beim gemeinsamen Mittagessen. Alles besser als das immer gleiche Miro-Board.

4. Focus auf den Circle of Concern

Das Problem: „Die Tools sind schlecht.” „Das Management versteht uns nicht.” „Die Strategie ist unklar.” Alles valide Punkte – aber keiner davon liegt im Einflussbereich des Teams. Die Retro wird zur kollektiven Beschwerderunde über Dinge, die man nicht ändern kann.

Der Kern: Wenn ein Team dauerhaft über seinen Circle of Concern diskutiert statt über seinen Circle of Influence, entsteht Ohnmacht. Die Retro wird zum Ventil – fühlt sich kurz gut an, verändert aber nichts. Schlimmer noch: Das Team verlernt, die eigene Wirksamkeit zu sehen.

Wege raus:

• Circle of Influence fokussieren: Aktiv fragen: „Was davon können wir beeinflussen? Was liegt in unserer Hand?”
• Perspektivwechsel: „Was war unser Anteil an der Situation?” Nicht als Schuldzuweisung, sondern als Weg zur Handlungsfähigkeit.
• Externe Themen parken: Ein „Parking Lot” für Themen außerhalb des Einflussbereichs – mit klarer Verantwortung, wer sie eskaliert.
• Selbstwirksamkeit betonen: Bewusst Erfolge sichtbar machen, bei denen das Team selbst die Ursache war.

5. Infantilisierung und Monotonie

Das Problem: Check-in mit Emojis. Sammeln auf Post-its. Dot-Voting. Action Items. Check-out. Jedes Mal. Ja, manchmal heißt das Format „Segelboot-Retro”, manchmal „Dino-Retro”, manchmal „Lego-Retro” – aber unter der Oberfläche ist es immer dasselbe Schema. Und, ganz ehrlich: Irgendwann fühlt es sich an, als würde man erwachsene, kompetente Menschen behandeln wie eine Schulklasse.

Der Kern: Viele agile Praktiken haben eine Tendenz zur Infantilisierung. Das mag gut gemeint sein – spielerische Elemente sollen die Hemmschwelle senken. Aber erfahrene Teams erleben es oft als herablassend. Und die Monotonie des immer gleichen Ablaufs killt jede Motivation, sich wirklich einzulassen.

Wege raus:

• Radikal neue Formate: Pre-Mortem statt Rückblick. Lean Coffee statt gelenkter Diskussion. Fishbowl statt Plenum.
• Team gestaltet die Retro selbst: Rotierende Facilitation oder die Frage: „Was braucht ihr diese Woche wirklich?”
• Erwachsene als Erwachsene behandeln: Weniger Spielchen, mehr ehrliche Gespräche. Nicht jede Retro braucht ein ausgefallenes Framework.

6. Misstrauen und das „Gallische-Dorf-Syndrom”

Das Problem: Das Team hat sich eingeigelt. Die Retro ist der sichere Raum – aber nicht im positiven Sinne. Eher im Sinne von: Wir gegen die anderen. Management ist der Feind. Andere Teams verstehen uns nicht. Die Retro dient nicht der Verbesserung, sondern der kollektiven Selbstbestätigung.

Der Kern: Wenn ein Team sich wie das gallische Dorf fühlt – umzingelt von Bedrohungen, zusammengehalten durch ein gemeinsames Feindbild – wird die Retro zum Ritual der Abgrenzung. Man bestärkt sich gegenseitig darin, dass die Probleme von außen kommen. Echte Reflexion? Findet nicht statt.

Wege raus:

• Brücken bauen: Retro-Reviews, bei denen Ergebnisse bewusst mit Stakeholdern geteilt werden.
• Führungskräfte als Dialogpartner einladen: Nicht als Kontrollinstanz, sondern als echte Gesprächspartner. Eine Retro, bei der der Engineering Manager offen zuhört und Fragen stellt, kann Wunder wirken.
• Externe Stimmen integrieren: Perspektiven von außen – ob durch andere Teams, Coaches oder Kunden – brechen eingefahrene Narrative auf.

---

Fazit

Retrospektiven sind und bleiben eines der mächtigsten Werkzeuge in der agilen Arbeit. Aber sie sind auch fragil – anfällig für Routine, Ermüdung und Bedeutungsverlust. Kein Format überlebt es, unreflektiert durchgezogen zu werden.

Der erste Schritt ist oft der einfachste und der schwierigste zugleich: Offen im Team darüber sprechen, welche dieser Anti-Patterns auf die eigene Situation zutreffen. Vielleicht ist das die beste Retro, die man haben kann – eine Retro über die Retro.

---

Eure Retrospektiven brauchen frischen Wind? In unseren Agile-Coaching-Schulungen lernt ihr neue Formate, Haltungen und Werkzeuge für wirksame Teamarbeit.