Bei dem Bild und dem Spruch müssen wir wohl erst mal mit einem Missverständnis aufräumen: die Retrospektive ist beileibe nicht nach hinten gerichtet, sondern der weitaus wichtigere Blickwinkel ist der nach vorne!

Fragt man agile Coaches nach dem wichtigsten Meeting in Scrum, werden die meisten wie aus der Pistole geschossen antworten: die Retrospektive! Aber was ist daran eigentlich so magisch und so wertvoll?

Das Thema

DAS zentrale Thema bei agilen Vorgehensweisen ist „inspect-and-adapt“. Diese neudeutsche Wortkombination soll uns sagen: beginnend bei einer definierten Ausgangssituation starten wir „gezielte Experimente“, um im Anschluss daran zu schauen, ob wir dieses Experiment fortführen, ausbauen, verändern oder abbrechen sollten.

Um dies sachgerecht beurteilen zu können, brauchen wir Feedback. In Scrum kennen wir zwei große Feedback-Meetings: Im Sprint Review („Review von außen“) stellt das Team seine Sprint-Ergebnisse vor und die im Review anwesenden Stakeholder geben uns direkt Rückmeldung, ob das Gezeigte die Anforderungen erfüllt oder wir daneben gelegen haben. Sollte Letzteres der Fall sein, ist das zwar nicht toll, aber immerhin sind wir dann nur einen Sprint, also ca. 2-4 Wochen, in die falsche Richtung gelaufen. Was für eine Zeitersparnis gegenüber klassischen Methoden!

Im zweiten Feedback-Meeting, der Retrospektive, geht es um das Feedback von und nach innen! Als Scrum Master versuchen wir einen geschützten Raum zu bereiten, in dem es uns als Team gelingt, ohne Anschuldigungen, böse Worte oder großen Frust über die Zusammenarbeit im Team zu reden. Es geht um persönliche und methodische Aspekte, um Toolings, Planung, Vorbereitung und Durchführung der Dinge, die im vergangenen Sprint passiert sind.

Ach so, wird der erfahrene klassische Projektleiter sagen, so ein „lessons learned“-Gedöns. Nein! Gerade nicht! Denn genau diese Meetings am Ende eines Projektes haben zum schlechten Ruf dieser Workshops beigetragen. POST MORTEM würde ich so etwas nennen, also nach dem Tod des Projekts. Selbst wenn man noch etwas Wertvolles herausarbeiten würde, man würde die Früchte dessen nicht mehr ernten können, denn das Projekt ist ja vorbei und die Wahrscheinlichkeit, dass man im nächsten Projekt eine ähnliche personelle oder fachliche Struktur wiederfindet, ist ja nun wirklich verschwindend gering.

Retrospektiven hingegen finden am Ende jedes Sprints statt und es gibt ein festes Muster, nach dem solche Retrospektiven ablaufen sollten. In den Literaturtipps am Ende des Beitrags findet ihr Blaupausen dafür. Im Wesentlichen gibt es 5 Schritte:

1. Herstellen einer Atmosphäre des Vertrauens („Setting the stage“)
2. Wertfreies Sammeln von Daten („Gather Data“)
3. Zusätzliche Informationen sammeln („Generate insights“)
4. Maßnahmen ableiten („Decide what to do“)
5. Abschluss („Closing the retrospective“)

Ohne zu sehr ins Detail gehen zu wollen (das findet man wirklich gut in der Literatur und im Netz), ist doch der Schlüssel zu einer guten Retrospektive der Blick nach vorne: was nützt es, wenn man lamentiert, was schief gegangen ist, wenn man keinen Plan hat, was man besser machen möchte?

Wichtig an der Stelle: die Ideen kommen alle aus dem Team selbst und es ist enorm wichtig, dass zumindestens einige der beschlossenen konkreten Maßnahmen auch direkt im nächsten Sprint umgesetzt werden. Passiert dies nicht, wird man unglaubwürdig und das Team wird im weiteren Verlauf des Projekts keine weiteren Verbesserungen mehr vorschlagen, schließlich passiert ja ohnehin nichts.

Tipps & Tricks

• Ergebnisse: Erarbeitete Ergebnisse müssen umgesetzt werden! Wie in der „normalen“ Arbeit in agilen Projekten gilt auch hier: die Teammitglieder sind die Experten in dem, was sie tun und wissen ziemlich gut, wie sie noch besser werden könnten, wenn man sie nur ließe. Lasst dieses Potenzial nicht ungenutzt! Frust entsteht, wenn offensichtliche gute Ideen nicht umgesetzt werden, Erfolg hingegen entsteht, wenn jedes Teammitglied das Gefühl bekommt, seine Meinung ist wertig und trägt zur Verbesserung der Gesamtsituation bei.
• Abwechslung: Das Format von Retros kann bisweilen schablonenhaft wirken. Während einige Teams Gewohntes schätzen, finden andere es langweilig, immer das gleiche Retro-Format machen zu müssen. Deshalb: schaut in den Literaturtipps nach neuen Formaten und probiert einfach mal Neues aus. Die Ergebnisse werden euch Recht geben!
• Durchhalten: Manche Ideen wirken auf den ersten Blick albern oder funktionieren einfach nicht beim ersten Mal. Bleibt am Ball! Jeder Verbesserungsvorschlag sollte mindestens einen Sprint lang durchgehalten werden, um dann frühestens in der nächsten Retro „abgewählt“ zu werden. Es passiert allzu oft, dass Maßnahmen erst nach einiger Zeit ihre Wirkung entfalten.
• Einbinden des Product Owners: Maßnahmen zur Verbesserung kosten auf jeden Fall mal Zeit. Dieses geht kurzfristig immer zu Lasten der Performance des nächsten Sprints. Deshalb sollte sehr zeitnah der PO sein Ok zu den Maßnahmen geben. Sein Interesse gilt vordergründig zwar den geplanten Story Points der nächsten Sprints, aber ein guter PO wird die mittel- bis langfristige Chance zur Verbesserung erkennen, die am Ende auch ihm zu Gute kommt.
• Literaturtipps:
  • Derby/Larsen: Agile Retrospectives: Making Good Teams Great
    DER Klassiker zum Thema.
  • Patrick Kua: The Retrospective Handbook: A Guide for agile teams
  • retrospectivewiki.org
    Eine Sammlung von verschiedenen Retro-Formaten. Von Coaches für Coaches. Ein ewiger Quell neuer Ideen ;-)

Das Fazit

Einer der Scrum-Werte ist Fokus. Man tut als Team gut daran, sich innerhalb des Sprints auf das Wesentliche zu konzentrieren, nämlich die Arbeit im Sprint. Alles „Weiterdenken“ würde die Performance des Sprints behindern. Trotzdem darf dieser Aspekt nicht völlig unter den Tisch gekehrt werden:

Wer nur in die Ferne schaut, stolpert gerne über seine eigenen Füße, wer nur nach unten schaut, rennt gegen eine Wand.

Dies ist nur eines der Sprichwörter, das die Situation in agilen Projekten gut beschreibt. Ständige Weiterentwicklung, KVP, Kaizen, Inspect-and-adapt, all dies sind Aspekte, die agile Vorgehensweisen so mächtig machen, wie sie nun mal sind. Ließe man die Retrospektiven weg, befände man sich immer nur im strengen Fokus auf den Sprint: man würde sich nicht als Team entwickeln und am Ende immer wieder die gleichen Fehler begehen, die man schon am Anfang des Projektes gemacht hat. Warum sollte man so etwas Dummes tun? Das Team weiß, was zu tun ist. Frag es!