Sprint Retrospective
Der Motor der kontinuierlichen Verbesserung.
1Zweck der Retrospektive
Die Sprint Retrospective ist der Moment, in dem das Scrum Team sich selbst überprüft – wie es zusammengearbeitet hat – und einen Plan zur Verbesserung erstellt.
Wichtige Punkte:
- Timebox: Maximal 3 Stunden für einen einmonatigen Sprint (90 Min. für 2 Wochen)
- Teilnehmer: Nur Scrum Team (keine Stakeholder)
- Ergebnis: Umsetzbare Verbesserungen, idealerweise zum Sprint Backlog hinzugefügt
Dies ist das Herz der kontinuierlichen Verbesserung. Lasst ihr sie aus, hört ihr auf, besser zu werden.
Das wichtigste Event
Viele argumentieren, dass die Retrospektive das wichtigste Scrum-Event ist. Sie ist der primäre Mechanismus für das Team, seinen Prozess anzupassen. Alles andere kann hier behoben werden.
2Was überprüft wird
Die Retrospektive untersucht drei Bereiche:
Menschen: Wie gut haben wir zusammengearbeitet? Kommunikation? Zusammenarbeit?
Prozesse: Dienen uns unsere Praktiken? Standups, Planung, Refinement?
Tools: Helfen oder behindern uns unsere Tools? CI/CD, Kommunikationstools?
Die oberste Direktive: „Unabhängig davon, was wir entdecken, verstehen und glauben wir wirklich, dass jeder die bestmögliche Arbeit geleistet hat, angesichts dessen, was er zu diesem Zeitpunkt wusste, seiner Fähigkeiten und Fertigkeiten, der verfügbaren Ressourcen und der vorliegenden Situation."
Diese Haltung schafft psychologische Sicherheit für ehrliche Reflexion.
3Formate, die funktionieren
Start/Stop/Continue: Was sollten wir anfangen zu tun? Aufhören zu tun? Weitermachen?
Mad/Sad/Glad: Was hat uns frustriert? Was enttäuscht? Was hat uns glücklich gemacht?
4Ls: Was mochten wir (Like)? Was haben wir gelernt (Learn)? Was fehlte (Lack)? Wonach sehnen wir uns (Long for)?
Segelboot: Wind (was treibt uns voran), Anker (was hält uns zurück), Felsen (Risiken voraus), Sonne (worauf wir hinarbeiten).
Zeitstrahl: Geht den Sprint chronologisch durch. Wo lief es gut oder schlecht?
Formate rotieren: Das gleiche Format jeden Sprint wird langweilig. Variiert.
4Verbesserungen zum Erfolg bringen
Der größte Fehlermodus: Verbesserungen identifizieren, aber nicht umsetzen.
Verbesserungen konkret machen: Nicht „besser kommunizieren", sondern „bei komplexen Items die erste Stunde Pair Programming machen."
Zum Sprint Backlog hinzufügen: Behandelt Prozessverbesserungen als Sprint-Arbeit mit zugewiesener Zeit.
Verbesserungen begrenzen: Wählt 1-2 aus, auf die ihr euch konzentriert. Versucht nicht, alles zu beheben.
Verbesserungen des letzten Sprints überprüfen: Haben wir sie umgesetzt? Haben sie geholfen?
Friedhof der Aktionspunkte
Wenn eure Retro-Aktionspunkte konsequent unerledigt bleiben, verschwendet ihr die Retrospektive. Macht sie entweder kleiner, priorisiert sie im Sprint oder geht dem nach, warum sie nicht passieren.
- Retrospektiven überprüfen Menschen, Prozesse und Tools
- Die oberste Direktive schafft Sicherheit für Ehrlichkeit
- Rotiert Formate, um es frisch zu halten
- Verbesserungen müssen Sprint-Arbeit werden, sonst passieren sie nicht
- •Jedes Mal das gleiche Format führt zu Langeweile
- •Einzelne beschuldigen verletzt die oberste Direktive
- •Zu viele Aktionspunkte bedeuten, dass keiner erledigt wird
- •Ausfallen lassen, wenn man „zu beschäftigt" ist, tötet den Verbesserungsmotor