Warum sind Retrospektiven so gewinnbringend?

Insbesondere komplexe Projekte mit vielen Einfluss-Faktoren erfordern im Projektverlauf ständig Anpassungen an sich verändernde Bedingungen. Beispiele für sich verändernden Bedingungen sind z.B. Sicherheit, SEO, neue Kundenanforderungen oder Mitarbeiterwechsel. Angemessene Entscheidungen und Handlungen erfordern unter solch komplexen Bedingungen die kontinuierliche Prüfung und Neu-Bewertung von Projektstand und Anforderungen. Zusätzlich wird der Wissenstransfer im Team enorm gesteigert, vor allem wenn nicht alle Teammitglieder am gleichen Projekt arbeiten.

In der Retrospektive bekommt das Team den Raum, einen Schritt vom Alltagsgeschäft zurück zu treten und das Projekt auf Meta-Ebene zu betrachten. Dadurch kommen Themen zum Vorschein, die im Alltag sonst möglicherweise untergehen. Probleme jeder Art können offen angesprochen werden. Die Retrospektive ermöglicht, geeigneten Maßnahmen zur Problemlösung zu entwickeln und die Zusammenarbeit zu verbessern. Zudem kommen unterschiedliche Auffassungen unter den Team-Mitgliedern frühzeitig auf den Tisch, wodurch Frust im Team vermieden wird.

Sprint-Retrospektive – Lernen durch „Inspect & adapt“

Daher ist die Retrospektive als regelmäßiger Termin für das Entwicklungsteam einschließlich dem Product Owner fest im Scrum-Zyklus verankert und wird in der Regel vom Scrum Master des Teams moderiert. Um einen kontinuierlichen, evolutionären Verbesserungsprozess zu gewährleisten, findet nach jedem Sprint eine Sprint-Retrospektive statt. Bei punkt.de hat eine Iteration - also ein Sprint - eine Dauer von zwei Wochen. Damit haben die Teams regelmäßig Gelegenheit, offen über alle Probleme zu sprechen, mit denen sie in dieser Zeit konfrontiert waren bzw. noch sind. Ein anderer Name desselben Prinzips: „Lessons learned“. 

Intro: Begrüßung des Teams, Besprechung der Agenda, gemeinsames Ankommen im geschützten Raum. Typischerweise wird auf die Vegas-Regel und die Prime Directive verwiesen. Alles, was während der Retrospektive besprochen wird oder passiert, bleibt also im Raum. Es sei denn, das Team entschließt sich, das Ergebnis zu veröffentlichen. Die Prime Directive zielt auf eine konstruktive und wertschätzende Umgangsweise. Dazu gehört das Mindset eines unvoreingenommen und offenen Umgangs, Schuldzuweisungen passen dazu nicht.

1. Set the stage: Die Teammitglieder bringen in der Regel all ihre Gedanken und Emotionen aus dem Alltag mit in die Retrospektive. Vielleicht gilt es gerade ein akutes Problem zu lösen oder irgendetwas Belastendes (oder Erfreuliches) ist passiert. Ziel der ersten Phase ist es, den Teilnehmern das Ankommen im hier und jetzt zu ermöglichen und Offenheit für die gemeinsame Arbeit in der Retrospektive herzustellen. Den Alltag sollen sie nun hinter sich lassen. Dazu eignen sich aktivierende Übungen oder die spielerische Artikulation des aktuellen Befindens. Wie auch in den übrigen Phasen ist es wichtig, dass alle die Möglichkeit haben, sich einzubringen.
2. Gather Data: Ziel der zweiten Phase ist es, die maximal zwei wichtigsten Themen herauszufiltern, die dann in der nächsten Phase gemeinsam bearbeitet werden sollen. Der Scrum Master hat die Möglichkeit, die Größe des Problemfelds zu regulieren: Soll die letzte Iteration ganz allgemein danach analysiert werden, was gut oder schlecht lief? Oder gibt es ein konkretes Problem, das angegangen werden soll? In beiden Fällen gilt es, mit dem Team ein gemeinsames Bild der Lage zu schaffen. Hilfreich ist, auch bei der Datensammlung Emotionen mit einzubeziehen, denn oft verraten gerade diese den dringendsten Handlungsbedarf.
3. Generate Insights: Häufig ist es verlockend, nach der Benennung eines Problems gleich Lösungsvorschläge zu machen. In der dritten Phase geht es jedoch erst einmal um ein tieferes Verständnis der Problemursachen. Wird dieser Schritt vergessen, läuft das Team Gefahr nur Symptome zu bekämpfen. Auch für diese Phase gibt es hilfreiche Methoden, wie z.B. sich den perfekten Sprint vorzustellen und dann die Abweichungen zu analysieren.
4. Decide what to do: In der vierten Phase bringen die Teammitglieder nun Lösungsvorschläge ein und diskutieren über diese. Die Beachtung weniger Grundsätze steigert die Chance einer nachhaltigen Verbesserung des Teams:
   • Am Ende sollten klar definierte Aufgaben stehen, wer was bis wann erledigt.
   • Dabei ist weniger oft mehr: Durch die Fokussierung auf wenige Maßnahmen als Retrospektiven-Ergebnis fällt es den Beteiligten leicht, diese Beschlüsse auch umzusetzen.
   • Es ist darauf zu achten, dass die Maßnahmen im Verantwortungsbereich des Teams liegen, also von den Mitgliedern des Teams selbst umgesetzt werden können: "Der Kunde soll..." hilft meist nicht weiter.
   • Hilfreich ist dagegen, die Aufgaben für den Alltagsbetrieb sichtbar zu machen. Sei es auf einem Board oder als Visualisierung an der Wand des Teamraums.
   • Es müssen nicht immer Aufgaben sein. Alternativ können aus einer Retrospektive auch Teamregeln resultieren.
5. Closing the Retrospektive: In der letzten Phase wird ein Stimmungsbild der Teilnehmer eingeholt und ein klares Ende des Meetings gesetzt. Aus dem Feedback der Teilnehmer kann der Scrum Master nochmals Erkenntnisse gewinnen: sowohl für seine Arbeitsweise, als auch über die Stimmung des Teams oder wichtige Themen, die noch der Klärung bedürfen - vielleicht in der nächsten Retrospektive.

Mit guter Laune und Abwechslung lernt man besser

Jede Retrospektive ist anders. Auch wenn die Phasen der Retrospektive jedes Mal durchlaufen werden, kann der Scrum Master diese völlig unterschiedlich gestalten. Je nach Stimmung im Team oder Problemlage werden Methoden variiert und angepasst, Fragen anders gestellt. Dies bringt nicht nur andere Informationen ans Licht, es verschafft dem Team auch Abwechslung. Statt einem "so haben wir das aber schon immer gemacht" schaffen Retrospektiven auf diese Weise eine Kultur freudiger Verbesserung und Weiterentwicklung.