Retrospektive Der Motor für kontinuierliche Verbesserung

Im Review geht es ums Produkt. In der Retrospektive geht es ums Team. Sie ist der letzte Termin im Sprint — und vielleicht der wichtigste: Hier reflektiert das Team, wie die Zusammenarbeit gelaufen ist, was gut funktioniert hat und was sich ändern sollte. Ohne Retro gibt es keine kontinuierliche Verbesserung — und ohne Verbesserung wird Scrum zur leeren Routine.

Retrospektive auf einen Blick

Was?
Team-Reflexion über den Prozess
Wer?
Scrum-Team (ohne Stakeholder!)
Dauer
Max. 3 Stunden bei 4-Wochen-Sprint
Ergebnis
1-3 konkrete Verbesserungsmaßnahmen für den nächsten Sprint

Wie läuft eine Retrospektive ab?

Das Grundmuster ist immer gleich — die konkreten Formate variieren:

  1. Einchecken: Wie geht es jedem? Eine kurze Runde, um die Stimmung einzufangen.
  2. Daten sammeln: Was lief gut? Was lief schlecht? Was hat uns überrascht?
  3. Erkenntnisse gewinnen: Warum lief etwas gut oder schlecht? Muster erkennen.
  4. Maßnahmen vereinbaren: Maximal 1-3 konkrete Verbesserungen für den nächsten Sprint.
  5. Abschluss: Kurzes Feedback zur Retro selbst.
Gut Gute Kommunikation Sprint-Ziel erreicht Code Review hilfreich Schlecht Zu viel gleichzeitig Daily zu lang Deployment-Probleme Ideen WIP-Limit einführen Daily-Timer starten Pair Programming

Beliebte Retro-Formate

Es gibt Dutzende Formate — hier die bewährtesten:

  • Start-Stop-Continue: Was sollen wir anfangen, aufhören und weitermachen? Einfach, schnell, wirksam.
  • Mad-Sad-Glad: Emotionaler Zugang — was macht wütend, traurig, froh? Gut für Teams, die über Gefühle reden müssen.
  • Segelboot: Das Team ist ein Boot. Wind = was treibt uns an? Anker = was hält uns zurück? Felsen = welche Risiken sehen wir? Visuell und einprägsam.
  • 4L: Liked, Learned, Lacked, Longed for. Breiter Blick mit Lern-Komponente.

Wichtig: Format regelmäßig wechseln. Wenn jede Retro gleich abläuft, wird sie langweilig — und Langeweile ist der Tod jeder Reflexion.

Warum Retrospektiven oft scheitern

  • Keine psychologische Sicherheit: Wenn Teammitglieder Angst haben, Probleme anzusprechen, bleibt die Retro oberflächlich. Der Scrum Master muss einen geschützten Raum schaffen.
  • Keine Umsetzung: Jede Retro produziert Maßnahmen — aber niemand setzt sie um. Lösung: Maßnahmen ins Sprint Backlog aufnehmen.
  • Management ist dabei: Die Retro ist für das Team, nicht für Vorgesetzte. Wenn der Chef am Tisch sitzt, sagt niemand die Wahrheit.
  • Immer dasselbe Format: Siehe oben — nach der zehnten „Was lief gut / was lief schlecht"-Runde hat niemand mehr Lust.