Normale Retrospektiven macht im agilen Umfeld so ziemlich jeder. In Scrum ist die Retrospektive fester Bestandteil am Ende jeden Sprints und im agilen Manifest heißt es “In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.” Jedes effektive Team hat eine Möglichkeit für sich gefunden, genau diesem Zweck der kontinuierlichen Verbesserung nachzukommen.

Häufig setzen sich Scrum Teams nachdem eine neue Version der Software ausgeliefert wurde zusammen, um eine Release Retrospektive durchzuführen. Durch den Fokus auf einen längeren Zeitraum erhoffen sie sich, Muster zu erkennen und Verbesserungen zu finden, die in herkömmlichen Iterationsretrospektiven aufgrund der Konzentration auf einzelne Sprints vielleicht nicht zu erkennen waren. Ich möchte hier einige Erfahrungen teilen, die ich bei Vorbereitung und Durchführung von Release-Retrospektiven gemacht habe und dabei auf die Unterschiede zu Iterations-Retrospektiven hinweisen.

Die Vorbereitung

Release Retrospektiven decken meist einen Zeitraum von mehreren Monaten ab, wohingegen es in einer Iterationsretrospektive meistens um einen Zeitraum von 1-4 Wochen geht. Während das noch einigermaßen überschaubar ist, benötigt man für einen ganzen Releasezeitraum etwas Vorbereitungszeit bei den Teilnehmern.

Im ersten Schritt sollte man sich Gedanken machen, wie der Teilnehmerkreis aussehen sollte. Bei einer Iterationsretrospektive ist das ziemlich eindeutig das Scrum Team. Bei einer Release Retrospektive bietet es sich an, auch die Schnittstellen des Teams zu berücksichtigen. Mit welchen anderen Teams hat man zusammengearbeitet? Welche Abteilungen hatten mit dem Team Kontakt? Welche Stakeholder könnten zu wichtigen Einsichten beitragen?

Hat man alle Teilnehmer identifiziert, sollte man eine offizielle Einladung zur Vorbereitung verschicken und dem Event auch einen würdigen Rahmen schaffen. Zur Terminfindung empfiehlt es sich auch, mit Teilnehmern, deren Teilnahme besonders wichtig ist, schon vorher Kontakt aufzunehmen und die Anwesenheit sicherzustellen. Es sollte auch genug Zeit reserviert werden (erfahrungsgemäß kann eine gute Release Retrospektive auch mal einen ganzen Tag in Anspruch nehmen) und auf die Wichtigkeit der kompletten Teilnahme hingewiesen werden. In der Einladung sollte man auch schon ein paar offene Fragen zur Vorbereitung formulieren. Empfehlenswert ist auch, wenn man die Fragen per Mail beantworten lässt. Das erleichtert einem die Vorbereitung der Retrospektive und man kann sich schon mal auf gewisse Punkte gezielt einstellen. Allerdings sollte man auch darauf hinweisen, dass die schriftliche Beantwortung der Fragen nicht bedeutet, dass die Autoren die Punkte nicht mehr selbst mit in die Retro bringen brauchen. Es bleiben ihre Punkte, und wenn sie es nicht selbst ansprechen, dann wird es auch niemand für sie übernehmen.

Für die Teamstimmung und das Klima förderlich ist auch, wenn man für ein paar Snacks und/oder ein gemeinsames Mittagessen sorgt. Viele interessante Gespräche und Gedanken können so fortgeführt werden und das Wir-Gefühl wird gestärkt.

Hat man gesammelte Daten aus den durchgeführten Sprints, dann kann man auch diese vorbereiten und am Tag der Retrospektive mitbringen. Das könnte zum Beispiel eine Auflistung der Sprint-Backlogs sein, die Velocity des Teams, eine Aufstellung der Action-Items aus den Iterationsretrospektiven oder ähnliche Fakten.

Die Durchführung

Prinzipiell unterscheidet sich eine Release Retrospektive in der eigentlichen Durchführung und Moderation nicht so stark von einer Iterationsretrospektive. Die meisten Aktivitäten, die in dem einen Setting gut funktionieren werden das auch in dem anderen Setting tun. Allerdings muss man bei der Moderation daran denken, dass man eventuell Gäste dabei hat. Diese nehmen vielleicht nicht regelmäßig an solchen Terminen teil und brauchen etwas mehr Aufmerksamkeit. Auch muss man die veränderte Dynamik der Gruppe beachten. Daher kann man hier gut zum Einstieg gemeinsame Working-Agreements vereinbaren, die für die Dauer der Retrospektive für diese Gruppe gelten sollen.

Ein solches Event kann auch ziemlich lang werden. Neben einer ausreichenden Anzahl an Pausen und dem ein oder anderen aufgestellten Snack ist es hilfreich, wenn man ein wenig Abwechslung einbaut. In einem großen Raum kann man oftmals den Standort oder Sitzplatz wechseln. Ein physischer Standortwechsel kann auch die Perspektive auf die Dinge beeinflussen. Zudem ist es hilfreich, wenn man die Medien variiert, etwas Farbe ins Spiel bringt und den Teilnehmern Raum gibt, sich selbst zu organisieren.

Da man Externe Teilnehmer an Bord hat, sollte man sich besonders auf die Zusammenarbeit an den Nahtstellen des Teams konzentrieren. Eine Timeline oder eine Wertstromanalyse kann helfen, die notwendigen Daten zusammenzutragen, um auf die Suche nach Mustern und wiederkehrenden Vorfällen zu gehen. Hier würde ich vorschlagen, die Gruppe gemeinsam arbeiten zu lassen, während es Vorteile hat, einzelne Themen im nächsten Schritt in Kleingruppen ausarbeiten zu lassen. Eine Gruppe von 3-4 Personen arbeitet deutlich effektiver und effizienter und jeder kann sich besser einbringen.

Die Struktur der Retrospektive sollte unbedingt die Schritte Datensammlung, Hintergründe erforschen und Aktionen definieren umfassen. Am Ende sollten konkrete Verbesserungen erarbeitet werden. Hier sollte man als Moderator wieder gezielt darauf achten, dass man konkrete Punkte hat, die optimaler Weise auch mit gewissen Akzeptanzkriterien und einem Zieldatum versehen sind. Vielleicht findet das Team ja sogar die ein oder andere Aufgabe, die es gleich vor Ort schon umsetzen kann. Das verbessert das Gefühl, wirklich etwas zu verändern und fördert Aktion. Dann kann man die Teilnehmer gemäß dem Pull-Prinzip Aufgaben ziehen lassen, für deren Umsetzung sie die Verantwortung allein oder in Arbeitsgruppen übernehmen wollen. Im Gegensatz zu einer Iterationsretrospektive braucht man sich dabei nicht auf ein oder zwei Action Items zu beschränken. In vielen Fällen werden Verbesserungen an den Schnittstellen etwas mehr Zeit in Anspruch nehmen, als nur einen Sprint. Daher kann hier längerfristiger gedacht werden.

Nach getaner Arbeit kann man noch ein Check-Out einbauen, in dem Raum für die Teilnehmer zur Verfügung gestellt wird, in dem sie sich bei anderen bedanken können oder ein kurzes Fazit zu der Retrospektive ziehen.

Was passiert dann

Eine gute Dokumentation der Retrospektive sollte im Anschluss an alle Teilnehmer geschickt werden. Daraus sollte auch offensichtlich werden, wer welche Aufgaben mitgenommen hat und was zu tun ist. Außerdem sollte man sich auch Gedanken darüber machen, wie der Fortschritt der Aufgaben transparent gemacht werden kann. Man kann beispielsweise die Aufgaben herunterbrechen und ins Backlog übernehmen oder Folgetermine vereinbaren. Wichtig ist, dass die Teilnehmer auch wirklich die mitgenommenen Punkte umsetzen, denn ansonsten ist der “Return on Time Invested” im tiefroten Bereich.

Was noch?

Es empfiehlt sich, für diese Retrospektive einen externen Moderator hinzuzuziehen. Vielleicht einen ScrumMaster aus einem Nachbarteam oder einen Coach. Jeder, der an einem Release beteiligt war, sollte auch inhaltlich teilnehmen und sich nicht auf die Moderation konzentrieren.

Man kann auch überlegen, die Retrospektive zusammen mit anderen Teams zu machen, wenn man eng zusammengearbeitet hat. Dann ist es umso wichtige, eine gute Vorbereitung zu haben.

Bezüglich weiterführender Informationen und einigen zielführenden Aktivitäten ist das Buch “Agile Retrospectives – Making good teams great” von Esther Derby und Diana Larsen (https://www.amazon.de/Agile-Retrospectives-Making-Pragmatic-Programmers/dp/0977616649/ref=sr_1_1?ie=UTF8&qid=1486564757&sr=8-1&keywords=agile+retrospectives) sehr zu empfehlen. Hier findet sich auch ein ganzer Abschnitt zum Thema Versionsretrospektiven.

Für die Auswahl von Aktivitäten für Retrospektiven, die auch in diesen Kontext passen, kann man sich beim Online Retromat bedienen (https://plans-for-retrospectives.com).