Dennis Gugel In der Theorie, Blogs, Best Practices und im Austausch mit Agilisten hört man immer wieder von der Fünf-Phasen-Retrospektive*. In diesen fünf Phasen geht es darum, die nächsten hilfreichen Änderungen, Maßnahmen, Regeln, Tätigkeiten oder Absprachen zu definieren.
Auch wir praktizieren das so. In meinem aktuellen Scrum-Team wird jede Retrospektive nach den fünf Phasen methodisch vorbereitet, die Durchführung entsprechend der Planung moderiert und dann geht der nächste Sprint seines Weges.
Soweit die Theorie
Wahrscheinlich verläuft auch der Großteil Ihrer Retrospektiven so ab. Die Praxis bei uns zeigt allerdings folgende Beobachtungen:
- In der Phase: „Gather Data“ & „Generate Insights“ der Retro wird sehr viel Zeit auf ausgedehnte Diskussionen verwendet, die rückblickend nicht zum Ergebnis der Retro beigetragen haben.
- Beim „Decide what to do“ legen wir manchmal eine Veränderung fest, die jedoch sehr generisch bzw. oberflächlich definiert wurde. Fühlt es sich in der Retro noch sehr konkret an, stellen sich im Laufe des Folgesprints einige Fragen, die dann zum nächsten Punkt führen:
- Plötzlich eintretende Vergesslichkeit der in der Retro festgelegten Maßnahmen. Festlegungen, und sind sie noch so konkret, werden oft einfach vom Sprintalltag kannibalisiert. Dadurch wird der Retro weniger Wert beigemessen. Die Motivation für die nächste Retro sinkt.
Sowohl die obigen Beobachtungen als auch meine untenstehenden Erfahrungswerte sind Momentaufnahmen aus meinem Scrum Team. Was auf uns zutrifft, muss nicht für andere Teams gelten.
Erfahrungswert 1: Fokus der Retrospektive
Vielleicht handelt es sich nicht um eine neue Erkenntnis, sie ist aber trotzdem wichtig: Eine Retro hat divergente, kreative (bspw. das Sammeln von Ideen) und konvergente, analytische Phasen (z.B. Bewerten & Auswählen), die getrennt voneinander bearbeitet werden sollten. Ob das nun an der Hirnphysiologie (rechte / linke Gehirnhälfte) liegt oder nicht – ich kann jedenfalls diese Erfahrung teilen.
Meiner Erfahrung nach fallen Teams manche Phasen leichter als andere. Und genau daran setzt mein Learning an: Weiß ich als Moderator, bei was sich mein Team schwertut, kann ich mehr Zeit für die entsprechende Phase allokieren, sie mit Methoden bspw. aus Liberating Structures auflockern und meine Moderation entsprechend anpassen. Insbesondere muss man sich bei der Entscheidung für eine Änderung die Fragen stellen, ob diese durch einen inneren Druck entsteht und damit wichtig wird oder, ob nur etwas gewählt wurde, weil man etwas wählen musste.
Erfahrungswert 2: PoC the Decision
Je konkreter die festgelegte Änderung definiert ist, desto besser ist sie greif- und vorstellbar. Deshalb ist ein Ansatz, die Retro um eine Phase zu verlängern – die „PoC the Decision“-Phase. Hat man festgelegt, was geändert werden soll, kann man diese Neuerung im Schnelldurchlauf ausprobieren.
Nehmen wir an, es wurde festgelegt, dass in jedem Daily Sprint die Ergebnisse des „Nightly Runs“ der Testing-Pipeline angeschaut werden. Warum dann bis morgen warten? Warum nicht noch in der Retrospektive dieses neue Vorgehen üben, ein Daily durchführen und direkt am neuen Vorgehen feilen? Bei so einer Trockenübung sieht man sehr schnell, wie konkret und praktikabel die Festlegungen der Retro sind.
Erfahrungswert 3: Informelle Retrospektive
Wie immer hilft die Kaffeemaschine, das Bier, der Small Talk, oder der Telefon-Abendspaziergang bei der Auswahl potenzieller Themen der Retro. Aus allen informellen 1:1- und Kleingruppen-Gesprächen lassen sich gut die „echten“ Anliegen und Bedürfnisse der Kolleg:innen herausarbeiten. Diese darf man gerne und nach Absprache mit den Kolleg:innen mit in eine Retro nehmen und damit das „Gather Data“ überspringen oder eben kürzen.
Erfahrungswert 4: Das Outro
Weder Intro noch Outro werden von vielen Agilist:innen und Developer:innen ernst genommen. Techies halten nicht selten ganze Retrospektiven für überflüssig, weshalb ich hierzu noch einen Erfahrungswert teilen möchte. Im Outro geht es für mich nicht darum, Spiele zu spielen oder Post-Its auf Wolke, Regen oder Sonne zu kleben. Dieser Slot sollte der Zufriedenheit der Developer:innen gewidmet werden. Wenn Techies das Gefühl haben, in Retros ihre Zeit zu verschwenden, dann war die Retro oft auch verschwendete Zeit! Ich finde, es gibt wenig Schlimmeres als Developern ihre Zeit in Meetings zu rauben. Insofern müssen wir Agilisten uns der ehrlichen Kritik offen stellen und sie ernst nehmen. Auch, wenn die Kritik unsachlich oder verkürzt ist. Und genau dieses Feedback erhalten wir in einer Outro-Phase.
Erfahrungswert 5: After-Retro
Sie kennen das sicherlich: Die Retro ist vorbei, alle gehen aus dem Raum und noch auf dem Weg vom Meetingraum zu den Arbeitsplätzen geht das Getuschel los. Wäre es für uns Agilisten nicht schön, genau diese Gedanken und den Inhalt dieser Gespräche zu sammeln/festzuhalten? Warum diese Phase nicht bewusst herbeiführen? Ich überlasse es mal Ihrer Fantasie, wie Sie das hinbekommen.
Zusätzlich gehört, zumindest für mich, zur After-Retro eine Zusammenfassung. Egal ob mit oder ohne PoC: Am Ende der Retro empfiehlt es sich, eine kurze Zusammenfassung noch mal in Teams oder Slack zu senden.
Zum Abschluss noch ein Nerd-Tipp
Wo werden Ihre Retro-Ergebnisse dokumentiert? Möglicherweise in Confluence, möglicherweise in Teams, vielleicht aber auch überhaupt nicht. Wir stellen uns öfter die Frage „Wann haben wir das noch mal eingeführt? Und warum war das noch schnell?“
Zugegebenermaßen, wir haben den folgenden Nerd-Tipp noch nicht ausprobiert, für mich hört er sich aber vielversprechend an:
Als Softwareentwicklungs-Team nutzen Sie sicher eine Code-Versionierung wie GitLab oder GitHub. Retro-Ergebnisse können hier als .md-File abgelegt und per Merge-Request genehmigt werden. Dadurch hat man eine Retro-Historie, arbeitet in der IDE, also absolut im Entwickler-Zuhause, die durch das Verschriftlichen und Genehmigen auch unterzeichnet ist.
Zusätzlich kann man mit einem Tool wie Pandoc nach jedem Merge die Retro-Ergebnisse in Confluence, HTML, als PDF in Teams oder andere Tools exportieren und ist auch immer up-to-date.
Ich würde mich über einen regen Austausch über Ihre Retrospektiven freuen. Hier auf dieser Seite, bei LinkedIn oder per Mail.
*5 Phasen der Retrospektive: (1) Set the Stage (2) Gather Data (3) Generate Insights (4) Decide what to do und (5) Outro