Retrospektiven
Die Retrospektive ist die wiederkehrende Sitzung, in der das ganze Team die eigene Arbeitsweise prüft und festlegt, was es für den nächsten Zeitraum ändert. Sie findet am Ende jeder Iteration oder jedes Release statt. Arbeitet ein Team nicht in festen Zyklen, wird die Sitzung in regelmässigem Abstand angesetzt. Sie verläuft in zwei Teilen: Das Team blickt auf die abgeschlossene Iteration zurück und bestimmt danach Anpassungen. Sie betrifft den Prozess; die Agile Extension zum BABOK Guide hält alles Persönliche aus der Diskussion heraus. Jede Sitzung beginnt mit den beim letzten Mal beschlossenen Massnahmen und endet mit einigen neuen, jede davon mit einer Frist und einem Teammitglied, das dafür einsteht. In Scrum ist die Sprint-Retrospektive diese Sitzung: Sie schliesst den Sprint ab und dauert bei einem einmonatigen Sprint höchstens drei Stunden.
Ziel
Die Retrospektive ist die Sitzung, in der ein Team den eigenen Arbeitsprozess prüft und festlegt, was es daran ändert. Die Agile Extension zum BABOK Guide bestimmt ihren Zweck: nachdenken über das, was gut lief und was besser laufen könnte, und danach die Prozesse verbessern. Die Sitzung versammelt das ganze Team, jenes, das den geprüften Prozess ausgeführt hat und das Beschlossene anwenden wird.
Was die Technik von einer einmaligen Durchsicht unterscheidet, ist die Schleife. Das erste Element der Sitzung ist die Durchsicht der Massnahmen, die in der vorangegangenen Retrospektive beschlossen wurden; das Team misst deren Fortschritt und Wirkung. Ohne diese Prüfung verbindet nichts die Sitzungen: Dieselben Themen kehren von Iteration zu Iteration wieder.
Die Agile Extension verortet die Retrospektive an den Horizonten Initiative und Delivery: Das Team zieht die Lehren aus dem abgeschlossenen Lieferzyklus und legt fest, was im nächsten zu ändern, beizubehalten oder einzustellen ist. Tabelle 7.0.1 führt sie unter den Kommunikationstechniken, die mit internen Teams funktionieren, ohne sie für externe Stakeholder zu nennen.
Die Abgrenzung zu den Lessons Learned
Die Lessons Learned des BABOK sind die Abschlussdurchsicht eines Projekts oder einer Phase: Sie findet einmal statt, reicht über das Team hinaus und erzeugt ein Register, das die Organisation in ihren nächsten Initiativen wiederverwendet. Die Retrospektive kehrt in jeder Iteration wieder, bleibt innerhalb des Teams und erzeugt einige Massnahmen für den beginnenden Zeitraum.
Einsatz
Wann einsetzen
- Ende einer Iteration oder eines Release: das Gelernte vor dem nächsten Zyklus im Prozess verankern.
- Team ohne feste Zyklen: die Sitzung in regelmässigem Abstand ansetzen, damit die Prüfung des Prozesses erhalten bleibt.
- Meilenstein im Lebenszyklus der Lösung: eine Inbetriebnahme oder ein Phasenende rechtfertigt eine Sitzung ausserhalb der Kadenz.
- Meinungsverschiedenheit, die im Moment aufkam und unentschieden blieb: über die Arbeitsweise entscheidet das ganze Team.
Wann nicht einsetzen
- Problem, das während der Iteration sichtbar wird: es sofort bearbeiten.
- Thema, das mit einem externen Stakeholder zu klären ist: Die Retrospektive ist eine interne Sitzung, das Thema gehört ins Sprint Review.
- Beurteilung der Leistung einer einzelnen Person: Die Sitzung betrifft den Prozess, das Mitarbeitergespräch gehört zur Personalführung.
Beschreibung
Die fünf Elemente
Die Agile Extension unterscheidet fünf Elemente.
| Element | Was das Team dabei tut |
|---|---|
| Durchsicht der vorherigen Massnahmen | Die in der vorangegangenen Retrospektive beschlossenen Massnahmen aufnehmen und ihren Fortschritt und ihre Wirkung beurteilen. |
| Vorbereitung | Vor der Sitzung sammelt jede Person die Beobachtungen aus der abgeschlossenen Iteration, die eine Analyse verdienen. |
| Safety Check | Das Team vereinbart, einander zu vertrauen und jede Bemerkung als Beitrag zur Verbesserung seiner Leistung aufzufassen. |
| Sammeln der Punkte | Alle Mitglieder schreiben auf, was gut lief, was zu verbessern ist und was sich zu teilen lohnt. Die Agile Extension gibt diesen Mechanismus als den verbreitetsten an. |
| Wahl der Massnahmen | Ist die Diskussion erschöpft, legt das Team die durchzuführenden Verbesserungen fest, bestimmt einen Zeitplan und benennt für jede das Mitglied, das dafür einsteht. |
Der Safety Check
Der Safety Check ist die ausdrückliche Vereinbarung, mit der sich das Team das Recht zu sprechen gibt. Die Agile Extension nennt ihre Grenze: Mitglieder können sich verpflichtet fühlen, ein Vertrauen vorzugeben, das sie nicht haben. Die verbreitetste Fassung dieser Vereinbarung ist die Prime Directive von Norm Kerth, die zu Beginn der Sitzung vorgelesen wird: "Was immer wir entdecken, wir verstehen und glauben aufrichtig, dass jede und jeder die bestmögliche Arbeit geleistet hat, gemessen an dem, was damals bekannt war, an den eigenen Fähigkeiten, an den verfügbaren Mitteln und an der Lage." Sie stammt aus der Literatur zu Retrospektiven; keiner der beiden Anker schreibt sie vor.
Die Agile Extension hält es für nützlich, die Moderation einer neutralen Person ausserhalb des Teams zu übertragen, ohne daraus eine Pflicht zu machen: Sie zählt es zu den Stärken der Technik, dass ein Team die Sitzung selbst moderieren kann.
Das Format der Sitzung stammt aus der Praxis
Weder die Agile Extension noch der Scrum Guide legt ein Moderationsformat fest. Die Agile Extension nennt einen verbreiteten Mechanismus für das Sammeln der Punkte und hört dort auf. Die verwendeten Formate stammen aus der Praxis und aus der Literatur: Esther Derby und Diana Larsen liefern die Referenzstruktur in fünf Schritten, den Rahmen setzen, Daten sammeln, Erkenntnisse gewinnen, entscheiden, was zu tun ist, die Sitzung schliessen. Ein Team, das in jeder Iteration dasselbe Format beibehält, erhält nach einigen Zyklen dieselben Antworten, denn die Frage ist dieselbe.
Die Sprint-Retrospektive in Scrum
Der Scrum Guide gibt der Sprint-Retrospektive einen Zweck: Wege zu planen, um Qualität und Wirksamkeit zu erhöhen. Das Scrum Team prüft darin den abgeschlossenen Sprint unter dem Blickwinkel der Personen, der Interaktionen, der Prozesse, der Werkzeuge und seiner Definition of Done, jener Kriterien, die ein Inkrement erfüllen muss, um als fertig zu gelten. Es benennt die Annahmen, die es in die Irre geführt haben, und erkundet deren Ursprung, dann bespricht es, was gut lief, welche Probleme auftraten und wie sie gelöst wurden oder nicht.
Danach legt es die für seine Wirksamkeit nützlichsten Änderungen fest und nimmt die auffälligsten so früh wie möglich auf, notfalls indem es sie ins Sprint Backlog des nächsten Sprints einträgt. Eine im Anschluss an diese Prüfung überarbeitete Definition of Done ist eines der Ergebnisse der Sitzung. Die Retrospektive schliesst den Sprint ab. Ihre Dauer ist bei einem einmonatigen Sprint auf drei Stunden begrenzt; bei einem kürzeren Sprint ist die Sitzung in der Regel kürzer.
Was eine Retrospektive scheitern lässt
Sicherheit nur dem Anschein nach
Die Sitzung findet statt, alle sprechen und nichts von dem, was zählt, wird gesagt. Das Anzeichen ist eine Liste von Massnahmen, welche die Themen nie berührt, über die das Team auf dem Gang spricht. Die Moderation einer Person von aussen zu übertragen, wie es die Agile Extension vorschlägt, ist das einfachste Gegenmittel, denn die Führung der Diskussion liegt dann nicht mehr beim Team.
Massnahmen ohne Folge
Die Agile Extension stellt die Bedingung: Die Retrospektive hat nur dann Wert, wenn das Team auf das reagiert, was es lernt. Das fünfte Element verlangt für jede Massnahme eine Frist und eine verantwortliche Person; was beides nicht hat, kehrt unverändert in die nächste Sitzung zurück. Die Agile Extension benennt den Preis eines Themas, das aufgeworfen und dann ohne Antwort gelassen wird: ein Risiko für Moral und Motivation des Teams.
Die Sitzung als Ersatz für die laufende Bearbeitung
Die meisten in einer Retrospektive aufgeworfenen Ideen sind mindestens einem Mitglied des Teams bereits bekannt. Die Agile Extension leitet daraus eine Anforderung ab: Ein reifes Team bearbeitet seine Probleme, sobald sie auftreten, statt sie für die Sitzung zurückzuhalten. Die Retrospektive dient dann dazu, Prozessänderungen zu beschliessen.
KI-Überlegungen
Ein Sprachmodell gruppiert die Notizen der Sitzung: Es führt die Formulierungen zusammen, die dasselbe aussagen, und erzeugt eine nach Häufigkeit geordnete Liste von Themen. Im Massnahmenregister meldet es jene, die dreimal ohne Fortschritt weitergeführt wurden, eine Information, die ein Team von einer Iteration zur nächsten verliert. Es schlägt zudem Moderationsformate vor und formuliert die Fragen für einen Abschnitt der Sitzung.
Was beim Team bleibt, ist der Kern der Technik. Der Safety Check ist eine Vereinbarung zwischen Personen und lässt sich an kein Werkzeug delegieren. Eine automatische Gruppierung glättet die Unstimmigkeiten, während der Unterschied zwischen zwei Formulierungen oft das Thema ist: Zwei Mitglieder beschreiben denselben Vorfall, und die eine führt ihn auf das Werkzeug zurück, der andere auf die Entscheidung, die es vorgeschrieben hat. Die Wahl der Massnahmen bindet die Kapazität des Teams für die nächste Iteration und liegt beim Team. Die Notizen einer Retrospektive tragen schliesslich Beurteilungen über namentlich genannte Kolleginnen und Kollegen: Sie sind Personendaten im Sinne des Datenschutzgesetzes (DSG) und vor jeder Übermittlung an einen externen Dienst als solche zu behandeln.
Beispiele
Ein Team von sechs Personen bei einer Krankenkasse der Westschweiz liefert das Kundenportal in Sprints von zwei Wochen. Die Retrospektive von Sprint 24 wird von einem Business Analysten eines anderen Teams desselben Programms moderiert, ein Dienst, den sich die beiden Teams seit drei Sprints gegenseitig erweisen. Sie beginnt mit den in Sprint 23 beschlossenen Massnahmen.
| In Sprint 23 beschlossene Massnahme | Verantwortlich | Stand und Wirkung |
|---|---|---|
| Die Zahl der Personen im Pikett am Tag der Inbetriebnahme auf zwei senken | Nadia | Erledigt. Zwei Unterbrechungen während des Sprints gegenüber sieben in Sprint 22. |
| Das Umstellungsverfahren der Tarifdatenbank dokumentieren | Marc | Nicht erledigt, zum zweiten Mal weitergeführt. |
| Code-Review zu zweit bei den Tarifierungstickets erproben | Sarah | Erledigt, dann aufgegeben: Das Warten auf eine zweite Person überstieg die gewonnene Zeit. |
Die am wenigsten offensichtliche Zeile der Tabelle ist das Review zu zweit: Das Team hat es erprobt, gemessen und beendet; das Thema ist für die folgenden Sprints abgeschlossen. Das Umstellungsverfahren geht in einen dritten Sprint, mit zwei Namen und einem im Kalender reservierten halben Tag, denn dieselbe Formulierung erneut einzutragen war schon zweimal gescheitert. Danach sammelt das Team seine Punkte und legt drei Massnahmen fest.
| Aufgeworfener Punkt | Für Sprint 25 festgelegte Massnahme | Verantwortlich | Frist |
|---|---|---|---|
| Drei Tarifierungstickets mehrere Tage blockiert, weil eine fachliche Antwort ausstand | Zeitfenster von dreissig Minuten am Dienstag und am Donnerstag mit der Product Ownerin für die offenen Fragen | Ana | Ab dem ersten Tag des Sprints |
| Die Testumgebung fällt am Ende des Sprints aus, wenn alle darauf deployen | Die Last der Umgebung über den Sprint messen und die Zahlen in der nächsten Sitzung berichten | Julien | Bericht in der Retrospektive von Sprint 25 |
| Die Tarifumstellung ist weiterhin nur von einer einzigen Person dokumentiert | Das Verfahren zu zweit während eines im Kalender reservierten halben Tages verfassen | Marc und Sarah | Mitte des Sprints |
Diese beiden Tabellen sind das vollständige Ergebnis der Sitzung. Die zweite wird in Sprint 25 Zeile für Zeile durchgegangen, was sie kurz hält.
Visualisierungen
Zwei Dinge lassen sich zeichnen. Das erste ist die Schleife: eine Iteration, die Retrospektive, die sie abschliesst, die nächste Iteration und dann die Retrospektive, die mit dem Durchgehen der Massnahmen der vorherigen beginnt. Die Zeichnung schliesst sich in sich selbst und zeigt den Übergang der Massnahmen von einer Sitzung zur nächsten, was eine Reihe von Schritten auf einer Linie nicht leistet.
Das zweite ist das Ergebnis der Sitzung. In zwei Tabellen gesetzt, lässt sich das Register in der nächsten Sitzung in einer Minute lesen und bringt hervor, was eine fortlaufende Liste durchrutschen lässt: die zum dritten Mal eingetragene Massnahme.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Gering | Jede Person sammelt ihre Beobachtungen aus der Iteration; die Moderation wählt das Format und öffnet das Massnahmenregister wieder. |
| Durchführung | Mittel | Die Sitzung bindet das ganze Team, laut Scrum Guide bis zu drei Stunden bei einem einmonatigen Sprint, und der Aufwand fällt in jeder Iteration erneut an. |
| Dokumentation | Gering | Das Ergebnis ist eine Liste von Massnahmen mit Frist und verantwortlicher Person, geführt dort, wo das Team sie wiedersehen wird. |
Werkzeuge
Die kollaborativen Whiteboards (Miro, Mural, FigJam und Vergleichbares) tragen die Sitzung auf Distanz: Spalten, verschiebbare Notizen, Gruppierung nach Thema und eine Abstimmung darüber, was besprochen wird. Ein Team am selben Standort erreicht dasselbe mit einer Wand und Haftnotizen, sofern die festgelegten Massnahmen noch am selben Tag in ein Medium übertragen werden, das die Woche überdauert.
Die auf Retrospektiven spezialisierten Werkzeuge (Retrium, TeamRetro, Parabol und Vergleichbares) ergänzen fertige Formate, einen Timer je Abschnitt, anonyme Beiträge und die Historie der Massnahmen von einer Sitzung zur nächsten. Anonymität hilft, solange das Vertrauen noch wächst; der Safety Check bleibt in der Sitzung zu schliessen.
Die Backlog-Werkzeuge (Jira, Azure DevOps, GitLab und Vergleichbares) nehmen die festgelegten Massnahmen auf, dort, wo das Team täglich hinschaut. Der Scrum Guide lässt zu, die auffälligsten Verbesserungen ins Sprint Backlog des nächsten Sprints einzutragen, was ihnen denselben Rang gibt wie der übrigen Arbeit des Sprints.
Quellen
- IIBA, Agile Extension to the BABOK Guide, §7.14 Retrospectives: der Zweck der Technik, die Sitzung in zwei Teilen, die Teilnahme des ganzen Teams, die Kadenz am Ende einer Iteration oder eines Release und die regelmässige Kadenz ohne feste Zyklen, der unpersönliche Charakter der Diskussion, die Moderation durch eine neutrale Person, die fünf Elemente sowie die genannten Stärken und Grenzen, darunter das vorgegebene Vertrauen, der an das Handeln geknüpfte Wert und das Risiko für die Moral bei einem ohne Antwort gelassenen Thema.
- IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: die Retrospektive eingeordnet unter den Kommunikationstechniken, die mit internen Teams funktionieren.
- IIBA, Agile Extension to the BABOK Guide, §5.7.1 und §6.7.1 (Techniken nach Planungshorizont) und §6.3.4 (Lernen am Horizont Delivery): die Retrospektive an den Horizonten Initiative und Delivery sowie die Prüfung dessen, was im nächsten Lieferzyklus zu ändern, beizubehalten oder einzustellen ist.
- Ken Schwaber und Jeff Sutherland, The Scrum Guide (November 2020), Abschnitt "Sprint Retrospective": der Zweck des Events, die geprüften Elemente, darunter die Definition of Done, die Annahmen, die das Team in die Irre geführt haben, die Wahl der nützlichsten Änderungen und ihre mögliche Eintragung ins Sprint Backlog, der Abschluss des Sprints und die Obergrenze von drei Stunden bei einem einmonatigen Sprint.
- Norm Kerth, Project Retrospectives: A Handbook for Team Review, Dorset House, 2001: die Prime Directive, die Referenzfassung jener Vereinbarung, welche die Agile Extension Safety Check nennt.
- Esther Derby und Diana Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006: die Moderationsstruktur in fünf Schritten, die weder die Agile Extension noch der Scrum Guide festlegt.