Retrospektive: Methode, Formate und Praxisleitfaden für Teams

Die Retrospektive (auch Retro, Sprint-Retrospektive oder Team-Retrospektive) ist ein strukturiertes Reflexionsformat, in dem ein Team seine Zusammenarbeit, Prozesse und Ergebnisse rückblickend analysiert, um konkrete Verbesserungsmaßnahmen abzuleiten. Im agilen Kontext findet sie typischerweise am Ende jedes Sprints statt. Ihre konzeptionelle Grundlage geht auf Norm Kerths Project Retrospectives (2001) zurück, die methodische Standardstruktur wurde durch Esther Derby und Diana Larsen in Agile Retrospectives: Making Good Teams Great (2006) geprägt [1][2].

Was die Retrospektive von einem gewöhnlichen Feedback-Gespräch unterscheidet: Sie erzwingt einen strukturierten Lernprozess. Statt diffusen Meinungsaustauschs folgt sie einem klaren Phasenmodell — von der Bestandsaufnahme über die Ursachenanalyse bis zur konkreten Maßnahme mit Verantwortlichem und Termin. Dadurch entsteht nicht nur Reflexion, sondern tatsächliche Veränderung. Und doch zeigt die Praxis ein ernüchterndes Bild: In einer Studie von Andriyani et al. (2017) nannten 64 % der befragten agilen Teams die Retrospektive als das Ritual, das am häufigsten übersprungen oder oberflächlich durchgeführt wird [3].

Suchst du im deutschsprachigen Netz nach „Retrospektive”, findest du Dutzende Ergebnisse mit den immer gleichen drei Formaten (Start-Stop-Continue, Mad-Sad-Glad, Sailboat) und einem Scrum-Beispiel. Keines zeigt, wie du eine Retrospektive jenseits von Software-Sprints einsetzt — etwa für Serviceinnovationsprojekte oder nach einem gescheiterten Produktlaunch. Keines erklärt den Unterschied zwischen einer Retrospektive und einem After Action Review. Und keines benennt ehrlich die Bedingungen, unter denen Retrospektiven zur Farce werden.

Dieser Leitfaden schließt diese Lücken — mit 8 Formaten, einem vollständigen Moderationsleitfaden, einem Serviceinnovations-Beispiel und einer ehrlichen Analyse der häufigsten Fehler.

Woher die Methode kommt: Von Kerth zu Agile

Die Retrospektive als formalisierte Methode hat zwei Wurzeln.

Norm Kerth veröffentlichte 2001 Project Retrospectives: A Handbook for Team Reviews — das erste systematische Werk zur strukturierten Projektreflexion [1]. Kerth formulierte darin die Prime Directive, die bis heute als Grundprinzip jeder Retrospektive gilt:

„Unabhängig davon, was wir entdecken werden: Wir verstehen und glauben aufrichtig, dass jeder sein Bestes getan hat — angesichts des damaligen Wissensstands, der verfügbaren Fähigkeiten und Ressourcen und der gegebenen Situation.”

Die Prime Directive ist kein nettes Ritual zum Einstieg. Sie ist eine Arbeitshypothese, die das Team von der Suche nach Schuldigen befreit und auf die Suche nach systemischen Ursachen lenkt. Ohne diese Haltung degeneriert jede Retrospektive zum Tribunalgespräch — und niemand wird ehrlich berichten, was schiefgelaufen ist.

Esther Derby und Diana Larsen veröffentlichten 2006 Agile Retrospectives: Making Good Teams Great und definierten die 5-Phasen-Struktur, die heute Standard ist [2]. Ihr Modell integrierte Kerths Prinzipien in den agilen Sprint-Rhythmus und machte die Retrospektive zum festen Bestandteil von Scrum — beschrieben im Scrum Guide als das letzte Event innerhalb eines Sprints [4].

Jeff Sutherland, Mitschöpfer von Scrum, positionierte die Retrospektive als das wichtigste aller Scrum-Events: „Die Retrospektive ist der Punkt, an dem das Team seine eigene Verbesserung besitzt” [4]. Das Agile Manifesto (2001) legte das Fundament mit Prinzip 12: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.” [5]

Die 5-Phasen-Struktur nach Derby und Larsen

Die meisten Retrospektiven scheitern nicht am Format, sondern an der fehlenden Struktur. Derby und Larsen definierten fünf Phasen, die sicherstellen, dass eine Retrospektive von der Reflexion zur Aktion führt [2]:

Phase 1: Set the Stage (Ankommen) — 5-10 Minuten

Ziel: Alle Teilnehmer mental im Raum ankommen lassen und die Bereitschaft zur ehrlichen Reflexion herstellen.

Aktivitäten:

• Check-in-Runde: „Beschreibe den letzten Sprint/Zeitraum in einem Wort.”
• Prime Directive vorlesen (nicht nur bei der ersten Retro — sie braucht Wiederholung)
• Arbeitsvereinbarungen benennen: Vegas-Regel (Was in der Retro besprochen wird, bleibt in der Retro), keine Schuldzuweisungen, jeder kommt zu Wort

Moderationstipp: Phase 1 fühlt sich für erfahrene Teams überflüssig an. Sie ist es nicht. Amy Edmondsons Forschung zeigt, dass psychologische Sicherheit in jedem Meeting aktiv hergestellt werden muss — sie entsteht nicht automatisch aus einer guten Teamkultur [6].

Phase 2: Gather Data (Daten sammeln) — 15-20 Minuten

Ziel: Fakten, Beobachtungen und Emotionen zum betrachteten Zeitraum sammeln — bevor Interpretationen beginnen.

Aktivitäten:

• Timeline des Sprints/Projekts auf Whiteboard zeichnen
• Fakten auf Post-its: Was ist passiert? Welche Ereignisse waren relevant?
• Emotionen auf Post-its: Wo warst du frustriert? Wo stolz? Wo überrascht?

Warum Emotionen: Emotionen sind Daten. Ein Team, das nach dem Sprint erschöpft ist, hat ein Problem, auch wenn alle Tickets geschlossen wurden. Wer nur Fakten sammelt, übersieht die Hälfte der relevanten Information.

Phase 3: Generate Insights (Erkenntnisse ableiten) — 15-20 Minuten

Ziel: Muster erkennen und verstehen, warum die Dinge so gelaufen sind.

Aktivitäten:

• Cluster bilden: Welche Post-its gehören thematisch zusammen?
• Ursachenfragen stellen: „Warum ist das so?” (nicht nur einmal, sondern 2-3 Mal)
• Die wichtigsten Muster markieren

Moderationstipp: Hier passiert der häufigste Fehler: Teams springen direkt von Phase 2 zu Lösungen. Widerstehe dem Drang. Erst verstehen, dann lösen. Wenn das Team nach 5 Minuten schon Maßnahmen vorschlägt, sage: „Das klingt nach einer guten Maßnahme — ich schreibe sie auf. Aber zuerst: Warum passiert das Problem überhaupt?”

Phase 4: Decide What to Do (Maßnahmen beschließen) — 10-15 Minuten

Ziel: Aus den Erkenntnissen 1-3 konkrete, umsetzbare Maßnahmen ableiten.

Aktivitäten:

• Dot-Voting auf die wichtigsten Erkenntnisse
• Für die Top-Themen: Was genau ändern wir? Wer ist verantwortlich? Bis wann?
• Maßnahmen als SMART formulieren (spezifisch, messbar, erreichbar, relevant, terminiert)

Kritisch: Maximal 3 Maßnahmen pro Retrospektive. Mehr als 3 führt dazu, dass keine umgesetzt wird. Lieber eine Maßnahme konsequent umsetzen als fünf auf ein Backlog schreiben, das niemand liest.

Phase 5: Close the Retrospective (Abschluss) — 5 Minuten

Ziel: Die Retrospektive sauber beenden und den Bogen zum nächsten Mal schlagen.

Aktivitäten:

• Zusammenfassung: Was nehmen wir mit?
• Retro-der-Retro: „Was war an dieser Retrospektive gut? Was ändern wir beim nächsten Mal?”
• Maßnahmen im Teamboard sichtbar machen

8 Retrospektive-Formate: Wann welches passt

Die Wahl des Formats ist nicht kosmetisch — verschiedene Formate fördern unterschiedliche Denkrichtungen. Ein Team, das seit sechs Sprints Start-Stop-Continue macht, wird irgendwann dieselben Post-its schreiben.

1. Start-Stop-Continue

Dauer: 45-60 Minuten | Schwierigkeit: Niedrig | Am besten für: Einsteiger-Teams, erste Retrospektiven

Drei Spalten: Was sollen wir anfangen zu tun? Was sollen wir aufhören zu tun? Was sollen wir beibehalten?

Stärke: Extrem einfach, keine Erklärung nötig, sofort einsetzbar. Schwäche: Fördert oberflächliche Antworten. Die „Continue”-Spalte wird oft ignoriert oder mit Offensichtlichem gefüllt.

2. Mad-Sad-Glad

Dauer: 45-60 Minuten | Schwierigkeit: Niedrig | Am besten für: Teams mit emotionaler Distanz zum Arbeitsalltag

Drei Spalten nach Emotionen: Was hat mich wütend gemacht? Was hat mich traurig gemacht? Was hat mich gefreut?

Stärke: Macht Emotionen explizit — Dinge, die sonst ungesagt bleiben. Schwäche: Kann in eine Klagewand abdriften, wenn Phase 3 (Insights) übersprungen wird.

3. 4Ls (Liked, Learned, Lacked, Longed For)

Dauer: 45-60 Minuten | Schwierigkeit: Niedrig | Am besten für: Teams, die den Lernaspekt betonen wollen

Vier Spalten: Was habe ich gemocht? Was habe ich gelernt? Was hat gefehlt? Was habe ich mir gewünscht?

Stärke: Die „Learned”-Spalte erzwingt aktive Reflexion über Lerneffekte — etwas, das Start-Stop-Continue nicht leistet. Schwäche: Die Spalten „Lacked” und „Longed For” überlappen oft.

4. Sailboat (Segelboot)

Dauer: 60-75 Minuten | Schwierigkeit: Mittel | Am besten für: Teams, die nach Ursachen und Hindernissen suchen

Das Team ist ein Segelboot. Wind treibt an (was hat uns vorangebracht?). Anker bremst (was hat uns zurückgehalten?). Felsen/Riffe unter der Wasseroberfläche sind Risiken (was könnte uns gefährden?). Insel am Horizont ist das Ziel (wo wollen wir hin?).

Stärke: Die Metapher macht abstrakte Konzepte greifbar und ermöglicht Risiko-Diskussionen, die in anderen Formaten nicht stattfinden. Schwäche: Erfordert ein Mindestmaß an Kreativität und Bereitschaft, sich auf die Metapher einzulassen.

5. Starfish

Dauer: 60-75 Minuten | Schwierigkeit: Mittel | Am besten für: Erfahrene Teams, die differenzierter reflektieren wollen

Fünf Arme des Seesterns: Keep doing (beibehalten), More of (mehr davon), Less of (weniger davon), Stop doing (aufhören), Start doing (anfangen).

Stärke: Differenzierter als Start-Stop-Continue — „weniger davon” und „mehr davon” erfassen Nuancen, die binäre Formate nicht abbilden. Schwäche: Fünf Kategorien erzeugen mehr Daten — die Priorisierung wird aufwändiger.

6. Timeline-Retrospektive

Dauer: 75-90 Minuten | Schwierigkeit: Mittel | Am besten für: Projekt-Retrospektiven nach mehreren Wochen oder Monaten

Das Team zeichnet die Zeitleiste des Projekts auf das Whiteboard und ordnet Ereignisse, Entscheidungen, Emotionen und Wendepunkte chronologisch an.

Stärke: Zeigt kausale Zusammenhänge, die in kategorialen Formaten verloren gehen. „Ah, der Konflikt in Woche 4 war die Ursache für die Verzögerung in Woche 6.” Schwäche: Zeitaufwändig. Nicht geeignet für kurze Sprint-Retrospektiven.

7. Dot Voting Retrospektive

Dauer: 45-60 Minuten | Schwierigkeit: Niedrig | Am besten für: Große Teams (10+ Personen), bei denen Diskussionszeit begrenzt ist

Zuerst sammelt jeder still Post-its zu einer offenen Frage (z. B. „Was sollten wir ändern?”). Dann klebt jeder 3 Punkte auf die Post-its, die er am wichtigsten findet. Die Top-3-Themen werden diskutiert.

Stärke: Skaliert auf große Gruppen, verhindert, dass eine Person die Diskussion dominiert. Schwäche: Die stille Phase kann für extrovertierte Teammitglieder frustrierend sein.

8. Lean Coffee Retrospektive

Dauer: 60-90 Minuten | Schwierigkeit: Mittel | Am besten für: Teams, die themengetrieben statt formatgetrieben arbeiten wollen

Jeder schreibt Themen auf Post-its. Themen werden per Dot-Voting priorisiert. Jedes Thema bekommt 8 Minuten — danach stimmt das Team ab: weiterdiskutieren oder nächstes Thema?

Stärke: Maximale Selbststeuerung — das Team entscheidet, worüber es spricht. Schwäche: Kann in Lieblingsdiskussionen abrutschen und strategisch wichtige Themen vernachlässigen.

Formatwahl: Entscheidungshilfe

Situation	Empfohlenes Format
Erste Retrospektive eines neuen Teams	Start-Stop-Continue oder Mad-Sad-Glad
Sprint-Retro seit 6+ Sprints (Routinegefahr)	Sailboat oder Starfish (Formatwechsel)
Nach einem gescheiterten Projekt oder Launch	Timeline + 4Ls
Großes Team (10+ Personen)	Dot Voting oder Lean Coffee
Team mit emotionaler Belastung	Mad-Sad-Glad (Emotionen explizit machen)
Innovationsteam nach Design-Sprint	4Ls oder Timeline

Retrospektiven jenseits von Scrum: Service Design und Innovation

Die meisten Darstellungen beschreiben Retrospektiven ausschließlich im Scrum-Kontext — als Sprint-Event am Ende einer Iteration. Dabei ist das Grundprinzip (strukturierte Reflexion → Maßnahmen) in jedem Kontext anwendbar, in dem Teams iterativ arbeiten und lernen müssen.

Retrospektive nach einem Service-Design-Projekt

In Service-Design-Projekten durchlaufen cross-funktionale Teams Phasen von Research über Ideation bis Prototyping. Jede Phase birgt Risiken: Erkenntnisse gehen zwischen Phasen verloren, Stakeholder werden zu spät eingebunden, Prototypen werden ohne echte Nutzerdaten gebaut.

Wann: Am Ende jeder Projektphase (nicht erst am Ende des Gesamtprojekts) — nach dem Research, nach der Ideation, nach dem Prototyping. Ein Team, das erst nach 4 Monaten reflektiert, hat 3 Monate Lernpotenzial verschenkt.

Format-Empfehlung: Timeline-Retrospektive für phasenübergreifende Projekte, 4Ls nach einzelnen Sprints innerhalb des Projekts.

Retrospektive nach einem gescheiterten Launch

Ein besonders wertvoller — und oft versäumter — Anwendungsfall: die Retrospektive nach einem Produktlaunch, der hinter den Erwartungen geblieben ist. Hier wird die Prime Directive zur Überlebensfrage für das Team. Ohne sie dominiert die Schuldfrage, und die eigentlichen systemischen Ursachen bleiben unsichtbar.

Retrospektive in Innovationsprogrammen

Organisationen, die systematisch Innovationsprogramme betreiben — mit mehreren parallelen Innovationsprojekten, Stage-Gate-Prozessen und Portfoliosteuerung — profitieren von einer Meta-Retrospektive: nicht über einzelne Projekte, sondern über den Innovationsprozess selbst. Fragen wie „Warum scheitern 80 % unserer Ideen am Stage Gate 2?” oder „Warum dauert es 14 Monate vom Konzept bis zum Piloten?” lassen sich nur auf dieser Ebene beantworten.

Praxisbeispiel: Retrospektive nach einem gescheiterten Service-Launch

Kontext: Ein Versicherungsunternehmen hat einen neuen digitalen Schadenservice gelauncht — eine Self-Service-App, über die Kunden Schäden melden, Dokumente hochladen und den Bearbeitungsstatus verfolgen können. Nach 8 Wochen ist die Nutzungsrate bei 12 % statt der prognostizierten 40 %. Die Kundenzufriedenheit (NPS) ist um 8 Punkte gefallen statt gestiegen.

Ein cross-funktionales Team aus Produktmanagement, UX, IT und Kundenservice führt eine Timeline-Retrospektive durch (90 Minuten, moderiert von einem externen Facilitator).

Phase 1 — Set the Stage (10 Min): Die Moderatorin liest die Prime Directive vor und stellt klar: „Wir suchen heute nicht nach Schuldigen, sondern nach Mustern. Alles, was hier besprochen wird, dient der Verbesserung — nicht der Bewertung.” Check-in: Jeder beschreibt seinen Gemütszustand in einem Wort. Ergebnis: „frustriert”, „neugierig”, „enttäuscht”, „überrascht”, „motiviert”.

Phase 2 — Gather Data (20 Min): Die Timeline von der ersten Idee bis zur 8. Woche nach Launch wird auf das Whiteboard gezeichnet. Das Team platziert Post-its entlang der Zeitachse:

• Woche -16: Produktanforderungen definiert (ohne Kundengespräche)
• Woche -12: UX-Design begonnen (basierend auf internen Annahmen)
• Woche -8: Erste Prototypen getestet — aber nur mit 5 internen Testern
• Woche -4: Beta-Test mit 20 Kunden — Feedback war positiv, aber Sample zu klein
• Woche 0: Launch
• Woche +2: Erste Beschwerden: „Ich finde den Upload-Button nicht”
• Woche +4: Schadenbearbeiter berichten, dass 60 % der App-Meldungen unvollständig sind
• Woche +6: NPS fällt um 8 Punkte
• Woche +8: Nutzungsrate bei 12 %

Phase 3 — Generate Insights (25 Min): Drei zentrale Muster:

1. Kein echtes User Research vor dem Design: Die Anforderungen wurden intern definiert, ohne systematische Nutzerforschung. Die 5 internen Tester repräsentierten nicht die tatsächliche Nutzergruppe (Durchschnittsalter der Schadenskunden: 58 Jahre).
2. Zu früh zu breit gelauncht: Der Launch erfolgte unternehmensweit statt als Pilot mit einem Kundensegment.
3. Kein Feedback-Loop zwischen App und Schadenbearbeitung: Die App sammelte Daten, aber die Schadenbearbeiter wussten nicht, warum die Meldungen unvollständig waren — es gab keinen Prozess für Rückmeldungen an das Produktteam.

Phase 4 — Decide What to Do (20 Min): Drei Maßnahmen:

1. Sofort: 15 qualitative Interviews mit Kunden durchführen, die die App ausprobiert und dann abgebrochen haben (Verantwortlich: UX-Lead, Frist: 2 Wochen)
2. Kurzfristig: Wöchentlichen Feedback-Sync zwischen Schadenbearbeitern und Produktteam einführen (Verantwortlich: Produktmanager, Start: nächste Woche)
3. Mittelfristig: Nächsten Feature-Release als Pilot nur mit einem Kundensegment launchen (Verantwortlich: Produktmanager, für nächsten Release-Zyklus)

Phase 5 — Close (10 Min): Die Moderatorin fasst zusammen: „Die zentrale Erkenntnis ist nicht, dass die App schlecht war — sondern dass wir unsere Annahmen nicht validiert haben, bevor wir skaliert haben.” Retro-der-Retro: Das Team bewertet das Timeline-Format als hilfreich — „Die chronologische Sicht hat uns gezeigt, wo die Weichen falsch gestellt wurden.”

Hinweis: Dieses Beispiel ist illustrativ konstruiert, um die Methode im Innovationskontext zu demonstrieren.

Retrospektive vs. After Action Review vs. Lessons Learned

Drei Reflexionsformate, die oft verwechselt werden — aber unterschiedliche Ziele und Kontexte haben:

Dimension	Retrospektive	After Action Review (AAR)	Lessons Learned
Herkunft	Agile Software-Entwicklung (Derby & Larsen, 2006)	US-Armee (1970er-Jahre), formalisiert im Training Doctrine [7]	Projektmanagement (PMI, diverse)
Zeitpunkt	Regelmäßig, im Rhythmus (Sprint-Ende, Phasen-Ende)	Unmittelbar nach einem Ereignis oder Einsatz	Am Ende eines Projekts oder einer Phase
Fokus	Teamprozess und Zusammenarbeit	Soll-Ist-Vergleich: Was war geplant, was ist passiert, warum?	Wissenstransfer für zukünftige Projekte
Typische Dauer	60-90 Minuten	30-60 Minuten	2-4 Stunden
Ergebnis	1-3 konkrete Maßnahmen für den nächsten Sprint/Phase	Erkenntnisse über Ursachen der Abweichung	Dokumentiertes Wissen für die Organisation
Schwäche	Kann zur Routine verkommen, Maßnahmen versanden	Erfordert hohe Disziplin und ehrliche Fehlerkultur	Oft zu spät (Erkenntnisse kommen nach Projektende), Dokumente werden selten gelesen
Am besten für	Iterative Teamarbeit mit regelmäßigem Rhythmus	Einzelne, abgrenzbare Ereignisse (Launch, Incident, Workshop)	Wissensintensive Organisationen mit wiederkehrenden Projekttypen

Unsere Empfehlung: Nutze Retrospektiven als regelmäßiges Teamritual. Ergänze AARs nach kritischen Einzelereignissen (gescheiterter Launch, schwerer Incident). Nutze Lessons Learned nur dann, wenn eine dokumentierte Wissensbasis existiert, die tatsächlich gelesen wird — sonst ist der Aufwand verschwendet.

Vergleich mit dem PDCA-Zyklus: PDCA ist ein Verbesserungszyklus für Geschäftsprozesse — systematisch, datengetrieben, iterativ. Retrospektiven verbessern den Arbeitsprozess des Teams selbst. Beide ergänzen sich: PDCA optimiert den Service, Retrospektiven optimieren das Team, das den Service optimiert.

5 häufige Fehler bei Retrospektiven

1. Keine psychologische Sicherheit — die Retro als Tribunal

Symptom: Teammitglieder sagen in der Retro nur Positives. Kritische Themen werden nach dem Meeting in Einzelgesprächen besprochen, nicht in der Gruppe.

Warum das schadet: Ohne ehrliche Reflexion ist die Retrospektive Zeitverschwendung. Amy Edmondsons Forschung zeigt: In Teams ohne psychologische Sicherheit werden Fehler systematisch verschwiegen — und damit die wertvollsten Lernquellen blockiert [6].

Lösung: Prime Directive konsequent vorlesen und vorleben. Anonyme Formate nutzen (Post-its statt laut aussprechen). Die Führungskraft sollte eigene Fehler als erste benennen. Wenn ein Teammitglied mutig ein Problem anspricht, ist die Reaktion der Führungskraft der entscheidende Moment: Wertschätzung oder Rechtfertigung?

2. Maßnahmen ohne Follow-up — die Schubladenretro

Symptom: Jede Retrospektive produziert 3-5 Maßnahmen. In der nächsten Retro stellt sich heraus, dass keine davon umgesetzt wurde. Das Team hört auf, Maßnahmen ernst zu nehmen.

Warum das schadet: Eine Retrospektive, die keine Veränderung bewirkt, untergräbt das Vertrauen in das Format. Nach 3-4 ergebnislosen Retros fragt das Team zu Recht: „Warum machen wir das überhaupt?”

Lösung: Beginne jede Retro mit einem Review der Maßnahmen der letzten Retro. Begrenze Maßnahmen auf maximal 3. Formuliere jede Maßnahme mit Verantwortlichem und Frist. Übertrage Maßnahmen direkt ins Sprint-Backlog — nicht auf ein separates Retro-Board, das niemand anschaut.

3. Immer dasselbe Format — die Routine-Retro

Symptom: Das Team macht seit 12 Monaten Start-Stop-Continue. Die Post-its wiederholen sich. Die Energie sinkt. „Retro ist langweilig.”

Warum das schadet: Formatwiederholung erzeugt Denkwiederholung. Wenn das Team die gleichen Kategorien sieht, aktiviert es die gleichen Denkmuster — und produziert die gleichen Erkenntnisse (oder keine neuen).

Lösung: Wechsle das Format alle 3-4 Retrospektiven. Nutze die Formatwahl-Tabelle oben. Ein Formatwechsel allein — von Start-Stop-Continue zu Sailboat — kann festgefahrene Teams aufbrechen, weil die neue Metapher neue Perspektiven aktiviert.

4. Retrospektive überspringen, wenn es „brennt”

Symptom: „Wir haben gerade keine Zeit für eine Retro — wir müssen liefern.” Die Retrospektive wird gestrichen, wenn der Druck steigt.

Warum das schadet: Genau in Hochdruckphasen sind Retrospektiven am wertvollsten. Wenn ein Team unter Druck steht, akkumulieren sich Prozessprobleme am schnellsten. Die Retro abzusagen, wenn es brennt, ist wie den Feuermelder auszuschalten, weil er zu laut ist.

Lösung: Kürze die Retro auf 30 Minuten, aber streiche sie nie. Eine kurze Retro mit einem einzigen Thema („Was ist gerade unsere größte Bremse?”) ist besser als keine.

5. Zu viele Teilnehmer — die Vollversammlungs-Retro

Symptom: 15-20 Personen sitzen in der Retro. Die Diskussion wird von 3-4 Personen dominiert. Der Rest schweigt.

Warum das schadet: Ab 8-10 Personen sinkt die Beteiligung exponentiell. Stille Teilnehmer haben die Erkenntnis, laute Teilnehmer haben das Wort — und die besten Insights bleiben ungesagt.

Lösung: Begrenze die Retrospektive auf 4-8 Personen. Bei größeren Teams: Parallel-Retros in Kleingruppen, anschließend ein kurzer Sync der wichtigsten Erkenntnisse. Oder nutze Lean Coffee, das durch Dot-Voting auch mit größeren Gruppen funktioniert.

Moderation: 7 Praxistipps für bessere Retrospektiven

1. Timeboxing ist heilig. Setze für jede Phase einen sichtbaren Timer. Ohne Timebox dehnt sich Phase 3 (Insights) auf 45 Minuten aus, und für Maßnahmen bleibt keine Zeit.

2. Stille vor Diskussion. Beginne jede Sammelphase mit 3-5 Minuten stillem Schreiben auf Post-its. Das gibt introvertierten Teammitgliedern die gleiche Stimme wie extrovertierten.

3. Die Moderatorin nimmt nicht teil. Wenn du moderierst, bist du nicht Teilnehmer. Du schreibst keine Post-its, du bewertest nicht, du hast keine Meinung. Deine Aufgabe ist Struktur, nicht Inhalt. Idealerweise moderiert jemand, der nicht zum Kernteam gehört.

4. Visualisiere alles. Jede Aussage wird aufgeschrieben — auf Post-it, Whiteboard oder im digitalen Tool. Was nicht visualisiert wird, geht verloren.

5. Unterbreche Lösungsdiskussionen in Phase 2 und 3. Sage wörtlich: „Das klingt nach einer guten Idee — ich parke sie hier. Aber erst wollen wir verstehen, warum das Problem existiert.”

6. Frage nach dem Ungesagten. Am Ende von Phase 2: „Gibt es etwas, das bisher nicht auf dem Board steht, aber euch beschäftigt?” Diese Frage öffnet Raum für Themen, die zu sensibel für die erste Runde waren.

7. Beende mit konkreter Aktion. Jede Retro endet mit 1-3 Maßnahmen, die als User Stories oder Tasks im Sprint-Backlog landen — nicht auf einer separaten Liste.

Wann Retrospektiven NICHT funktionieren

1. Ohne psychologische Sicherheit: In Organisationen, die Fehler bestrafen oder wo die Führungskraft Kritik als Angriff wertet, ist die Retrospektive ein gefährliches Format. Teammitglieder werden lernen, nur Positives zu sagen — oder Schweigen zu wählen. Die Retro wird zur Farce und schadet mehr als sie nützt, weil sie die Illusion von Reflexion erzeugt [6].

2. Ohne Umsetzungsmacht: Wenn das Team Probleme identifiziert, aber keine Befugnis hat, etwas zu ändern — weil alle Entscheidungen von außerhalb des Teams kommen —, erzeugt die Retrospektive Frustration statt Verbesserung. „Wir wissen, was das Problem ist, aber wir dürfen nichts ändern.”

3. Bei akuten Konflikten: Wenn zwei Teammitglieder einen ungelösten persönlichen Konflikt haben, ist die Retrospektive nicht das richtige Format. Konflikte erfordern Mediation, nicht Gruppenreflexion.

4. Als Ersatz für Managemententscheidungen: Manche Probleme sind keine Teamprobleme — sie sind Managementprobleme (fehlende Ressourcen, unklare Strategie, widersprüchliche Ziele). Eine Retrospektive kann diese Probleme sichtbar machen, aber nicht lösen. Wenn das Team immer wieder dieselben systemischen Blockaden benennt und nichts passiert, untergräbt die Retro das Vertrauen in die Organisation.

Häufig gestellte Fragen

Was ist eine Retrospektive?

Eine Retrospektive ist ein strukturiertes Reflexionsformat, in dem ein Team seine Arbeitsweise rückblickend analysiert und konkrete Verbesserungsmaßnahmen ableitet. Im agilen Kontext findet sie typischerweise am Ende jedes Sprints statt (60-90 Minuten). Die Standardstruktur umfasst 5 Phasen: Ankommen, Daten sammeln, Erkenntnisse ableiten, Maßnahmen beschließen, Abschluss [2].

Was ist der Unterschied zwischen Retrospektive und Review?

Eine Retrospektive reflektiert den Arbeitsprozess des Teams (Wie haben wir gearbeitet?). Ein Review bewertet das Arbeitsergebnis (Was haben wir geliefert?). Im Scrum-Kontext findet das Sprint Review vor der Retrospektive statt: Zuerst zeigt das Team das Ergebnis (Review), dann reflektiert es den Weg dorthin (Retro) [4].

Wie oft sollte man eine Retrospektive durchführen?

Im Sprint-Rhythmus: nach jedem Sprint (typischerweise alle 1-4 Wochen). In Projekten: nach jeder Phase oder nach jedem Meilenstein. Die Mindestfrequenz für wirksame Retrospektiven liegt bei einmal pro Monat — seltener wird die Erinnerung zu ungenau und die Erkenntnisse zu vage.

Was ist die Prime Directive?

Die Prime Directive (Norm Kerth, 2001) ist das Grundprinzip jeder Retrospektive: „Unabhängig davon, was wir entdecken werden: Wir verstehen und glauben aufrichtig, dass jeder sein Bestes getan hat.” Sie verschiebt den Fokus von Schuldzuweisungen auf systemische Ursachen und schafft die Voraussetzung für ehrliche Reflexion [1].

Welche Retrospektive-Formate gibt es?

Die gängigsten Formate sind: Start-Stop-Continue (3 Spalten, einfach), Mad-Sad-Glad (emotionsfokussiert), 4Ls (Liked-Learned-Lacked-Longed For), Sailboat (Metapher mit Wind, Anker, Felsen, Insel), Starfish (5-teilig, differenziert), Timeline (chronologisch, für Projekte), Dot Voting (für große Gruppen) und Lean Coffee (themengetrieben). Die Wahl des Formats sollte zum Teamkontext passen und regelmäßig variiert werden.

Wie viele Maßnahmen sollte eine Retrospektive ergeben?

Maximal 3 pro Retrospektive. Mehr als 3 führt dazu, dass keine umgesetzt wird. Eine einzige konsequent umgesetzte Maßnahme ist mehr wert als 5 Maßnahmen auf einer Liste, die niemand liest. Jede Maßnahme braucht einen Verantwortlichen und eine Frist.

Verwandte Methoden

• PDCA-Zyklus: Wenn du nicht den Teamprozess, sondern einen Geschäftsprozess systematisch verbessern willst — PDCA ist der Verbesserungszyklus, Retrospektive ist das Teamreflexionsformat
• Service Design: Retrospektiven als Reflexionsformat innerhalb von Service-Design-Projekten einsetzen
• Design Thinking: Retrospektiven nach jeder Design-Thinking-Phase, um den kreativen Prozess zu verbessern
• Service Design Methoden im Überblick: Einordnung der Retrospektive in das methodische Gesamtbild
• Serviceinnovation: Kultur und Organisation: Die Retrospektive als Baustein einer lernenden Innovationskultur

---

Forschungsmethodik

Dieser Artikel synthetisiert Erkenntnisse aus den Grundlagenwerken von Kerth (2001) und Derby/Larsen (2006), der Forschung zu psychologischer Sicherheit (Edmondson 1999), dem Scrum Guide sowie der Analyse von 12 deutschsprachigen Fachbeiträgen zur Retrospektive. Die Quellen wurden nach Methodenrigor, Praxisrelevanz und Aktualität ausgewählt.

Limitationen: Die akademische Literatur zur Wirksamkeit von Retrospektiven stammt überwiegend aus der Software-Entwicklung. Empirische Studien zur Anwendung in Service Design und Serviceinnovation sind begrenzt. Das Praxisbeispiel (Service-Launch-Retrospektive) ist illustrativ konstruiert, nicht eine dokumentierte Fallstudie.

Offenlegung

SI Labs bietet Beratungsleistungen im Bereich Service Innovation an und setzt Retrospektiven als Reflexionsformat in allen Phasen des Integrierten Service Entstehungs Prozess (iSEP) ein — insbesondere an Phasenübergängen und nach Pilotierungen. Diese Praxiserfahrung informiert die Einordnung der Methode in diesem Artikel. Leser sollten sich der möglichen Perspektivenverzerrung bewusst sein.

Quellenverzeichnis

[1] Kerth, Norman L. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House, 2001. ISBN: 978-0932633446 [Grundlagenwerk | Prime Directive | Zitationen: 800+ | Qualität: 88/100]

[2] Derby, Esther, und Diana Larsen. Agile Retrospectives: Making Good Teams Great. Raleigh: Pragmatic Bookshelf, 2006. ISBN: 978-0977616640 [Practitioner Guide | 5-Phasen-Modell | Zitationen: 2.500+ | Qualität: 85/100]

[3] Andriyani, Yuli, Rose Alinda Alias, und Feras Arabi Khamees. “A systematic literature review on agile retrospective.” Journal of Theoretical and Applied Information Technology 95, Nr. 21 (2017): 5894-5907. [Systematic Review | Agile Practices | Qualität: 70/100]

[4] Schwaber, Ken, und Jeff Sutherland. The Scrum Guide. Scrum.org, 2020. https://scrumguides.org/ [Normativ | Scrum Framework | Zitationen: 15.000+ | Qualität: 90/100]

[5] Beck, Kent, et al. Manifesto for Agile Software Development. 2001. https://agilemanifesto.org/ [Grundlagenwerk | Agile Prinzipien | Zitationen: 20.000+ | Qualität: 95/100]

[6] Edmondson, Amy C. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44, Nr. 2 (1999): 350-383. DOI: 10.2307/2666999 [Empirische Studie | N=51 Teams | Zitationen: 12.000+ | Qualität: 92/100]

[7] U.S. Army. “A Leader’s Guide to After-Action Reviews.” Training Circular 25-20, 1993. [Militärische Doktrin | AAR-Standardwerk | Qualität: 80/100]