Retrospektive variieren

In vielen agilen Projekten, in denen ich nur Beteiligter war, wurden die Retrospektiven oft nach Schema F durchgeführt. Ohne eine Phase zur Einstimmung ging es direkt in die Fragestellungen „Was war gut“, Was war schlecht“ und „Welche Maßnahmen leiten wir ein“. Es gab keinerlei Abwechselung. Dies hatte zur Folge, dass spätestens nach der dritten Iteration die Luft raus war und viele Teammitglieder das Meeting eher als eine lästige Pflicht ansahen.

Dabei kann gerade in der Retrospektive an wichtigen Stellschrauben, die zur Verbesserung der weiteren Projektverlaufs führen können, gedreht werden. Ich empfehle daher den Ansatz der Durchführung öfters zu wechseln. Eine schier unendliche Fülle an Möglichkeiten bietet der Retromat, der Euch sowohl eine Vielzahl an Anregungen und Vorschlägen macht, der Euch aber auch einen zufälligen Ablauf für die nächste Retro generiert. Dabei folgt jede Retro den Schritten „Positives Gesprächsklima schaffen“, „Themen sammeln“, „Erkenntnisse gewinnen“, „Entscheidungen treffen“ und „Retro abschließen“.

Ein relativ einfaches Format, dass insbesondere für noch unerfahrene Teams geeignet ist, möchte ich Euch vorstellen. Man nennt sie die Start-Stop-Continue-Retro und man geht wie folgt vor:

1. Positives Gesprächsklima schaffen
   
   Zu Beginn berichtet jeder von einem positiven Erlebnis, dass er im letzten Sprint hatte. Folgende Fragestellungen können dazu führen:
   
   
   • Was habe ich im letzten Sprint wirklich gut gemacht?
   • Wie habe ich im letzten Sprint jemand unterstützt oder geholfen?
   • Was hat mich in der letzten Iteration glücklich gemacht?
     
     
2. Themen sammeln
   
   An einem Whiteboard erstellen wir eine Spalte mit folgenden drei Überschriften: „Start“, „Stop“, „Continue“. Anhand dieser Überschriften ordnet man nun Erkenntnisse aus dem letzten Sprint ein. Idealerweise benutzt ihr Karten, die man später noch umarrangieren kann. Hilfreich ist es auch die Karten in den Ampelfarben Grün, rot und gelb für die jeweilige Spalte zu nutzen, dies ist aber nicht zwingend erforderlich.
   
   Unter „Start“ ordnet man alle Ideen ein, die man bisher nicht getan hat, die aber sinnvoll wären und mit denen man beginnen möchte. Als Beispiel wäre hier zu nennen, dass man ab dem nächsten Sprint Pair Programming einführen möchte, weil man sich davon vielleicht eine bessere Code-Qualität verspricht.
   
   In der Spalte „Stop“ ordnet man Tätigkeiten oder Verhalten ein, die man beenden möchte, da sie einen negativen Einfluss auf das Projekt haben bzw. keinen Mehrwert liefern. Beispielweise könnte der Product Owner während des Sprint zusätzliche Stories eingebracht haben, was nicht dem üblichen Vorgehen entspricht und man dies zukünftig vermeiden möchte.
   
   In der Spalte „Weitermachen“ weist man auf Prozeduren ein Verhaltensweisen hin, die man im Projekt eingeführt hat, die sich aber noch nicht verfestigt haben. Auch hierbei ist darauf zu achten, dass man wenn möglich konkrete Maßnahmen benennt und nicht nur allgemeine Platituden. Zum Beispiel könnte man darauf hinweisen, dass man weiterhin darauf achtet, das Daily Meeting pünktlich zu beginnen und zu beenden.
   
   
3. Erkenntnisse gewinnen
   
   Nach der Sammelphase werden gemeinsam ähnliche Beiträge gruppiert, um einen besseren Überblick zu bekommen und Schwerpunkte zu erkennen. Dies kann durch das Arrangieren der Karten an der Wand erfolgen. Wenn man nicht mit Karten, sondern nur mit der Tabelle und dem Whiteboard arbeitet, kann man versuchen schon bei der Sammelphase zusammengehörige Ideen zu gruppieren.
   
   Jedes Teammitglied stimmt anschließend darüber ab, welche Themengruppe man am liebsten weiter diskutieren möchte. Jeder kann dabei z.B. drei Stimmen abgeben. Es ist jedem überlassen, ob er die Stimmen auf mehrere Themen verteilt oder ihm ein Thema so wichtig ist, dass er alle drei Stimmen diesem Thema gibt.
   
   
4. Entscheidungen treffen
   
   Die Themen mit den meisten Stimmen werden danach diskutiert und die Maßnahmen konkretisiert. Das bedeutet auch, dass eventuell noch zusätzliche Aufgaben ergänzt werden. Jeder Punkt wird mit einem Verantwortlichen und einem Fälligkeitsdatum versehen.
   
   
5. Retro abschließen
   
   Zum Abschluss bedankt man sich bei allen Teilnehmern für die Unterstützung und erklärt die Retrospektive für beendet. Im Anschluss dokumentiert man die Ergebnisse und teilt sie mit den Projektteilnehmern. Dies kann per E-Mail, besser aber über ein weniger flüchtiges Medium, wie Confluence oder ähnliches erfolgen.

Wer sich intensiver mit dem Thema beschäftigen möchte, dem empfehle ich das hervorragende Buch „Agile Retrospectives: Making Good Teams Great“ von Esther Derby und Diana Larsen.

Darüber hinaus ist der oben bereits erwähnte Retromat eine hervorragende Quelle für weitere Erkenntnisse und Anregungen.