Retrospektiven: Formate, die tragen, Maßnahmen, die bleiben

Eine Retrospektive ist ein kurzes, wiederkehrendes Meeting, in dem ein Team auf einen abgeschlossenen Arbeitsabschnitt zurückschaut — einen Sprint, eine Projektphase, einen Monat — und entscheidet, was es vor dem nächsten ändert. Die Standardform hat fünf Phasen: Rahmen setzen, Daten sammeln, Erkenntnisse gewinnen, Maßnahmen beschließen, abschließen. Diese Definition liefert dir jede Seite bei Google, und sie stimmt.

Der Teil, der darüber entscheidet, ob sich das Meeting gelohnt hat, passt in vier Zeilen:

• Wie lange: 30–60 Minuten für einen Zwei-Wochen-Sprint. Der Scrum Guide begrenzt sie auf drei Stunden bei einem Ein-Monats-Sprint; kürzere Sprints bekommen kürzere Retros.
• Wie oft: am Ende jeder Iteration. Wenn du nicht in Sprints arbeitest, alle zwei Wochen oder einmal im Monat.
• Was dabei herauskommt: ein oder zwei Änderungen. Kein Whiteboard mit zwanzig Klebezetteln — ein oder zwei Maßnahmen, jede mit genau einer benannten verantwortlichen Person und einem gebuchten Zeitslot.
• Woran du merkst, dass es funktioniert hat: Die nächste Retro beginnt damit, genau diese Maßnahmen zu prüfen, bevor irgendwer einen neuen Zettel schreibt.

Die letzte Zeile ist die, die fast niemand umsetzt. Ich moderiere seit Jahren Retros für Engineering- und Produktteams und mache jeden Freitag eine Solo-Version für mich selbst. Das häufigste Scheitern ist weder ein schlechtes Format noch ein stilles Team. Es sind Maßnahmen, die donnerstags um 16 Uhr großartig aussehen und am Dienstag tot sind — weil sie niemandem gehörten und nichts in irgendeinem Kalender festhielt, wann sie passieren sollten.

Warum die meisten Retrospektiven nichts verändern

Adobes Leitfaden nennt mangelnde Umsetzung („poor follow-through”) als eine von drei Hürden für eine gute Retrospektive, neben geringer Beteiligung und fehlendem Vertrauen. Ich würde sie mit Abstand an die erste Stelle setzen. Beteiligungs- und Vertrauensprobleme sieht man im Raum. Die Umsetzung scheitert leise, eine Woche später, wenn niemand hinschaut.

Das Muster ist immer dasselbe:

1. Das Team produziert acht bis zwölf Maßnahmen, weil jeder gute Punkt eine verdient.
2. Als Verantwortliche steht „Team” da — oder gar nichts.
3. Die Maßnahmen landen in einem Dokument, einer Confluence-Seite oder einem Miro-Board — irgendwo, das zwischen zwei Retros niemand öffnet.
4. Bis Montag hat die Sprint-Arbeit den Kalender gefüllt. Verbesserungsarbeit hat keinen Slot, also verliert sie jedes Mal.
5. Zwei Wochen später kommt dieselbe Beschwerde. Jemand sagt „Hatten wir das nicht schon?”, und das Team verliert still den Glauben an das Ritual.

Schritt fünf sind die eigentlichen Kosten. Eine Retro, die nie etwas ändert, bringt Menschen bei, dass es sinnlos ist, Wahres laut auszusprechen — genau das Gegenteil dessen, wofür das Meeting da ist.

Adobe zitiert außerdem Forschung, nach der Teams mit Retros 24 % reaktionsschneller sind und 42 % höhere Qualität liefern. Die Studie wird nicht genannt, deshalb würde ich mich nicht auf die Zahlen stützen. Der Mechanismus ist plausibel — aber er wirkt nur, wenn die Änderungen tatsächlich passieren.

Die Lösung: weniger Maßnahmen, eine Person, ein Slot, eine Prüfung

Atlassian rät, Verbesserungen für die zwei wichtigsten Problemfelder zu besprechen und einen Aktionsplan mit klaren Verantwortlichen und Fälligkeitsdaten zu erstellen. Das ist schon fast die ganze Antwort. Ich würde es auf vier Regeln zuspitzen:

1. Höchstens zwei Maßnahmen. Wenn sich das Team nicht einigen kann, welche zwei am wichtigsten sind, wird mit Punkten abgestimmt. Eine dritte Maßnahme ist kein zusätzlicher Fortschritt, sondern eine Steuer auf die ersten beiden.

2. Eine verantwortliche Person pro Maßnahme, mit Namen. „Das Team verbessert das Code-Review” ist ein Wunsch. „Priya entwirft eine Review-Checkliste und postet sie im Channel” ist eine Maßnahme. Die Person muss nicht alles selbst machen — sie muss dafür sorgen, dass es passiert. Dieselbe Logik wie beim einzelnen A in einer RACI-Matrix: Zwei Verantwortliche erzeugen gegenseitiges Abwarten, nicht doppelten Einsatz.

3. Ein gebuchter Slot, bevor das Meeting endet. Kein Fälligkeitsdatum — ein Slot. Die Person öffnet noch im Raum ihren Kalender und blockt die 45 Minuten, die sie diese Woche daran arbeitet. Ein Fälligkeitsdatum sagt, wann es zu spät ist. Ein Slot sagt, wann es erledigt wird. Wenn du deine Woche ohnehin per Time Blocking planst, ist das nur ein Block mehr.

4. Die nächste Retro beginnt mit der Prüfung. Die ersten fünf Minuten, jedes Mal: erledigt, in Arbeit oder verworfen — und wenn verworfen, warum. Eine Maßnahme bewusst zu verwerfen ist völlig in Ordnung. Sie zu vergessen ist genau das, was wir hier reparieren.

Laut Scrum Guide können die wirkungsvollsten Verbesserungen sogar ins Sprint Backlog aufgenommen werden. Ich würde das „können” streichen. Steht es nicht im Backlog oder in jemandes Kalender, konkurriert es ohne eigenen Slot mit Lieferarbeit — und verliert.

Der Kreis schließt sich nur, wenn jede Maßnahme einen Namen und eine Uhrzeit bekommt. Fehlt der Slot, versickert sie vor Dienstag.

Retrospektiven-Formate, die funktionieren — und wann du welches nimmst

Formate sind weniger wichtig als die Umsetzung, aber ein neues Format hilft einem Team, das in Routine erstarrt ist. Adobe listet acht auf — 4Ls, Segelboot, Dot-Voting, Start/Stop/Continue, Fragekarten, Affinity Mapping, PMI und Six Hats. Atlassian ergänzt More/Less und Glad/Sad/Mad. Diese fünf wechsle ich tatsächlich durch:

Format	Die Fragen	Nimm es, wenn …	Achte auf …
Start / Stop / Continue	Was sollten wir anfangen, lassen, beibehalten?	neue Teams, erste Retros, wenig Zeit	„Stop” wird übersprungen, weil es nach Schuldzuweisung klingt
4Ls	Liked, Learned, Lacked, Longed for	nach einem Projekt oder längeren Abschnitt	„Longed for” wird zur Wunschliste — begrenzen
Segelboot	Wind, Anker, Felsen, Insel	Teams, die das Ziel aus den Augen verloren haben	dauert zehn Minuten länger; braucht ein echtes Ziel
Glad / Sad / Mad	Was hat dich gefreut, traurig, wütend gemacht?	nach einem harten Sprint, wenn Stimmung die eigentlichen Daten sind	braucht Vertrauen; nicht mit neuer Führungskraft im Raum
More / Less	Wovon wollen wir mehr, wovon weniger?	reife Teams, die einen ordentlichen Prozess feinjustieren	zu sanft für Teams mit echten Problemen

Start/Stop/Continue ist nicht ohne Grund der Standard: Man kann es kaum missverstehen, und Coursera wie Atlassian stellen es an die erste Stelle. Die Schwäche: „Stop” verlangt, öffentlich die Gewohnheit eines Kollegen zu benennen. Ich umgehe das, indem „Stop” nur für Prozesse gilt — „keine Code-Reviews mehr am Freitagnachmittag starten”, nicht „nicht mehr zu spät zum Review kommen”.

4Ls funktioniert am besten nach etwas, das länger als einen Sprint gedauert hat, weil „Learned” Zeit braucht, um etwas zu bedeuten.

Das Segelboot ist mein Favorit für ein Team, das beschäftigt ist, aber treibt. Die Insel erzwingt die Frage, die die meisten Retros überspringen: Wohin wollten wir eigentlich? Wenn niemand das beantworten kann, hast du deine Maßnahme gefunden.

Wind, Anker, Felsen, Insel. Die Maßnahme entsteht fast immer daraus, einen Anker zu kappen — nicht daraus, mehr Wind zu erzeugen.

Wie läuft das Segelboot in der Praxis? Zeichne das Boot, gib allen pro Bereich fünf Minuten stilles Schreiben, clustere, und stelle dann eine einzige Frage: Welcher Anker würde uns, wenn wir ihn kappen, am schnellsten Richtung Insel bringen? Das ist deine erste Maßnahme. Die Felsen liefern einen zweiten Kandidaten, falls einer davon dringend ist.

Eine 30-Minuten-Agenda für die Team-Retrospektive

Coursera empfiehlt je nach Komplexität 45 Minuten bis drei Stunden, Atlassian 30 Minuten bis eine Stunde. Für einen Zwei-Wochen-Sprint und ein Team von fünf bis acht Leuten nehme ich 30 Minuten, und das reicht — solange niemand die letzten zehn Minuten für optional hält.

Minuten	Phase	Was passiert
0–5	Den letzten Kreis schließen	Maßnahmen der letzten Retro prüfen: erledigt, in Arbeit, verworfen. Noch keine neuen Themen.
5–8	Rahmen setzen	Sprint-Ziel nennen. Ein-Wort-Runde. Erinnern: Es geht um das System, nicht um die Person.
8–15	Daten sammeln	Stilles Schreiben im gewählten Format. Die Stille ist wichtig — sonst bestimmt die lauteste Person die Agenda.
15–22	Erkenntnisse gewinnen	Zettel clustern, mit Punkten abstimmen, nur die zwei stärksten Cluster besprechen.
22–28	Beschließen	Zwei Maßnahmen. Je eine verantwortliche Person. Die Personen buchen ihren Slot jetzt, im Meeting.
28–30	Abschließen	Beide Maßnahmen laut vorlesen. Ein Satz von allen, ob sich die Retro gelohnt hat.

Drei Anmerkungen aus vielen Durchläufen:

• Die ersten fünf Minuten sind nicht verhandelbar. Lässt du sie einmal aus, ist der Kreis gebrochen. Laut Scrum Guide prüft das Team, wie der letzte Sprint gelaufen ist — und die Verbesserungen aus dem letzten Sprint gehören dazu.
• Wechsle die Moderation. Atlassian nennt Scrum Master, Product Owner oder eine rotierende Rolle. Rotation funktioniert besser als gedacht: Wer einmal moderiert hat, wird ein deutlich besserer Teilnehmer.
• Remote-Teams brauchen ein Board, kein Dokument. Stilles Schreiben und Dot-Voting brauchen eine gemeinsame visuelle Fläche, und jedes Whiteboard, das das Team ohnehin nutzt, trägt das Gespräch. Lass nur die Maßnahmen nicht dort liegen: Auf dem Board wird die Retro besprochen, nicht entschieden, ob sie gewirkt hat.

Viele Moderatorinnen und Moderatoren eröffnen mit Norm Kerths Retrospective Prime Directive, die alle bittet anzunehmen, dass jede und jeder mit dem damaligen Wissensstand das Bestmögliche getan hat. Beim ersten Mal klingt das kitschig. Es verändert den Ton der folgenden Stunde zuverlässiger als alles andere, was ich ausprobiert habe.

Die 15-Minuten-Solo-Retrospektive für Wissensarbeiter

Retrospektiven sind nicht nur etwas für Scrum-Teams. Eine Solo-Retro ist dieselbe Idee, gerichtet auf deine eigene Woche — und für die meisten Wissensarbeiter sind das die ertragreichsten fünfzehn Minuten im Kalender.

Sie ist nicht dasselbe wie Wochenplanung. Planung schaut nach vorn: Was kommt wohin in der nächsten Woche? Die Retro schaut zurück und fragt, warum die letzte Woche so gelaufen ist, wie sie gelaufen ist. Ich mache zuerst die Retro, dann die Planung — die eine Änderung aus der Retro wird zum Input für den Plan.

Freitag, 15 Minuten:

1. Die Änderung der letzten Woche prüfen (2 Min.). Habe ich das eine, was ich mir vorgenommen hatte, wirklich gemacht? Wenn nicht: Lag es am Slot, am Umfang, oder wollte ich es eigentlich gar nicht?
2. Ein Format wählen (1 Min.). Start/Stop/Continue funktioniert auch allein gut. Nach einer harten Woche ist Glad/Sad/Mad ehrlicher.
3. Schreiben, nicht grübeln (6 Min.). Drei bis fünf Zeilen pro Frage. Schau in deinen echten Kalender und deine Aufgabenliste, nicht in deine Erinnerung an die Woche — die Erinnerung schmeichelt.
4. Das Muster finden (3 Min.). Was taucht doppelt auf? Ein Meeting, das immer überzieht, eine Art Aufgabe, die du ständig verschiebst, ein Nachmittagsslot, in dem nie etwas passiert.
5. Eine Änderung, ein Slot (3 Min.). Genau eine. Trag sie in den Kalender der nächsten Woche ein, bevor du den Laptop zuklappst.

Eine Änderung pro Woche klingt winzig. Fünfzig Änderungen im Jahr sind es nicht. Und anders als bei einer Team-Retro hält dich niemand sonst daran fest — der Slot zählt also noch mehr.

Die Solo-Retro hat einen Nebeneffekt, den ich nicht erwartet hatte: Sie ist ein Frühwarnsystem. Wenn dasselbe „Stop” drei Wochen in Folge auftaucht — zu viele Meetings, Arbeit, die in den Abend rutscht, der Deep-Work-Block, der nie überlebt —, lohnt es sich, das ernst zu nehmen. Über diese zählbaren Warnzeichen habe ich in Die Anzeichen von Burnout, die dein Kalender zuerst zeigt geschrieben.

Wo meine Retro-Maßnahmen tatsächlich landen

Ich habe Retro-Maßnahmen in einem Dokument, einer Notiz-App und einem eigenen Retro-Board gepflegt. Alles scheitert auf dieselbe Weise: Die Maßnahme liegt irgendwo, wo ich während der Woche nicht hinschaue.

Was heute für mich funktioniert: Jede Retro-Maßnahme ist eine ganz normale Aufgabe mit Datum. Ich plane meine Woche in Fokus (während der Public Beta kostenlos, ohne Kreditkarte), das Aufgaben automatisch in echte Kalenderslots rund um meine Meetings legt — die Maßnahme taucht also in meinem Tag auf wie alles andere. Rutscht sie, wird sie auf den nächsten Tag übertragen, statt zu verschwinden. Wenn am Freitag die Retro sie prüft, steht sie also noch sichtbar da.

Die tägliche Version zählt ebenfalls. Fokus hat ein End-of-Day Review als Ritual, und ich nutze es als Zwei-Minuten-Mini-Retro: Was ist passiert, was ging voran, was nicht? So muss ich die Woche am Freitag nicht aus dem Gedächtnis rekonstruieren. Das Morning Briefing am nächsten Morgen ist die andere Hälfte: Es führt mich durch den Tag, holt das Wichtige nach oben und bewertet den Plan — der Tag beginnt also mit dem, was geplant ist, nicht mit meinem Posteingang.

Größere, langsamere Änderungen — „keine Meetings mehr vor 10 Uhr” — hänge ich an ein Wochenziel, damit sie mit etwas verbunden sind, das ich für wichtig erklärt habe, statt frei herumzuschweben. Entscheidend ist, dass die Maßnahme dort landet, wo deine Woche ohnehin stattfindet, in einem Aufgabensystem, das im Kalender endet — und in Fokus ist das einfach der Ort, an dem Aufgaben leben.

Das Gespräch selbst kann auf jedem Whiteboard stattfinden. Der Teil, der darüber entscheidet, ob die Retro funktioniert hat — zwei Maßnahmen mit Verantwortlichen, jede mit eingeplantem Slot und noch sichtbar, wenn die nächste Retro sie prüft —, liegt in Fokus.

Fragen zu Retrospektiven, kurz beantwortet

Was bedeutet Retrospektive? Wörtlich: Rückschau. Im Arbeitskontext ist es ein strukturiertes Meeting, in dem ein Team einen abgeschlossenen Arbeitsabschnitt betrachtet, um zu entscheiden, was es ändert. Coursera grenzt es von Introspektion ab: Eine Retro untersucht Ereignisse und Handlungen, nicht innere Gefühle.

Was sind Retrospektiven im Projektmanagement? Ein wiederkehrender Rückblick während eines Projekts, nicht nur an dessen Ende. Adobe betont diesen Unterschied: Anders als ein Post-mortem findet eine Retro statt, während die Arbeit weiterläuft, sodass sich das Team noch vor Projektende anpassen kann.

Was ist ein Beispiel für eine Retrospektive? Ein Team beendet einen Zwei-Wochen-Sprint. Bei Start/Stop/Continue schreibt es „Start: Pairing bei riskanten Änderungen”, „Stop: Merges am Freitagnachmittag”, „Continue: die Demo am Dienstag”. Es stimmt ab, wählt „keine Freitags-Merges”, und der Tech Lead übernimmt das mit einem 30-Minuten-Slot am Montag, um die Release-Checkliste anzupassen.

Warum machen wir Retrospektiven? Weil Prozesse abdriften und niemand es merkt, bis etwas kaputtgeht. Eine Retro ist ein geplanter Moment, es zu merken. Gut gemacht, lernt ein Team dort außerdem, dass das Ansprechen von Problemen zu Veränderung führt.

Was sind die fünf Phasen einer Retrospektive? Rahmen setzen, Daten sammeln, Erkenntnisse gewinnen, Maßnahmen beschließen, abschließen. Ich würde eine nullte ergänzen: die Maßnahmen der letzten Retro prüfen.

Wie lange sollte eine Retrospektive dauern? 30 Minuten für einen Zwei-Wochen-Sprint mit kleinem Team; bis zu einer Stunde für größere Teams oder nach harten Sprints. Die Obergrenze im Scrum Guide liegt bei drei Stunden für einen Ein-Monats-Sprint. Eine wöchentliche Solo-Retro braucht 15.

Die Kurzfassung

Eine Retrospektive ist nur so gut wie das, was sich danach ändert. Nimm ein vernünftiges Format — Start/Stop/Continue für den Anfang, das Segelboot, wenn das Team den Faden verloren hat — und halte es bei 30 Minuten. Geh mit höchstens zwei Maßnahmen raus. Gib jeder eine verantwortliche Person und einen gebuchten Slot, bevor jemand den Raum verlässt. Beginne die nächste Retro damit, sie zu prüfen.

Wende denselben Kreislauf jeden Freitag in 15 Minuten auf dich selbst an, mit einer Änderung statt zwei. Die Meetings müssen nicht besser werden. Sie müssen zu Ende gebracht werden.