Agile Retrospektiven (Teil 1)

Eines der wichtigsten Artefakte in allen agilen Methoden, und damit auch in Scrum, ist die Retrospektive.
Manche agilen Vertreter gehen sogar so weit zu sagen: „Starte ausschließlich mit Retrospektiven, der Prozess findet sich dann von ganz alleine“.

Was jedoch sind Retrospektiven, und wie führt man eine gute Retrospektive durch?

Retrospektiven lassen sich direkt aus dem agilen Manifest ableiten. In den 12 Prinzipien hinter dem Manifest steht wörtlich:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Dementsprechend heißt es auch im agilen Manifest:

Individuals and interactions over processes and tools

Das Team kommt also in regelmäßigen Abständen zusammen und denkt darüber nach, wie es noch effektiver werden kann und passt sein Verhalten dann dementsprechend an.
Dies bedeutet, daß bei agilen Vorgehensweisen das Team die vollständige Kontrolle über den Prozeß hat, und ihn bei Bedarf an die jeweiligen Gegebenheiten anpassen darf (bzw. sogar soll), denn die Personen und ihre Interaktionen zählen ja mehr als Prozesse und Tools.

Das ist natürlich ein ganz wesentlicher Unterschied zu schwergewichtigen Verfahren, wo der Entwicklungsprozeß selbst außer Frage steht und das Team sein Verhalten lediglich auf eine möglichst optimale Umsetzung hin optimieren kann.

Retrospektiven sind auch deswegen so wichtig, da es hier um die Verbesserung des Teams als Ganzes geht, und nicht um die Erhöhung der Produktivität der einzelnen Teammitglieder. In der Tat ist es sogar so, daß optimale Produktivität des Teams immer mit einer nicht-optimalen Produktivität der einzelnen Teammitglieder einhergeht. Ein alleiniger Fokus auf die Produktivität der Teammitglieder kann daher sogar kontraproduktiv sein.
Als Beispiel sei hier etwa die Kommunikation genannt: Eine erhöhte Kommunikation wird in vielen Fällen die Produktivität des Teams verbessern, für die einzelne Person jedoch verschlechtern, da sie sich jetzt nicht mehr alleine auf ihre Arbeit konzentrieren kann, sondern zusätzliche Zeit aufwenden muß.

Wann und wie sollte man also nun eine Retrospektive durchführen?

Nun, einerseits sollte schon eine gewisse Zeit seit der letzten Retrospektive vergangen sein (wenn seit dem letzten Mal nichts passiert ist brauchen wir auch nicht darüber sprechen, überspitzt gesagt). Andererseits darf er aber auch nicht zu lange sein, da ansonsten die Erinnerung an den Beginn des Zeitraums bereits zu verblassen beginnt.
Zudem sollte sie noch während der eigentlichen Projektlaufzeit stattfinden, damit die aus ihr gezogenen Lehren noch für das aktuelle Projekt verwendet werden können. Sie soll also gerade keine der berüchtigten „Post Mortem“-Analysen sein, bei der nur die Teammitglieder etwas lernen (vielleicht), das Projekt selber zu diesem Zeitpunkt aber bereits beendet ist.

Als ideal hat sich hier die denkbar einfachste Lösung herausgestellt: Man setzt eine Retrospektive immer zu Ende jeder Iteration an. So ist immer ein ganzer Zyklus seit dem letzten Mal vergangen, und trotzdem ist die Erinnerung daran noch frisch genug um darüber zu diskutieren.

Hat man nun also einen Termin für die Retrospektive angesetzt, gilt es nun, eine Agenda aufzustellen. Um das Rad nicht immer wieder neu erfinden zu müssen, möchte ich an dieser Stelle gerne auf das Buch „Agile Retrospectives: Making Good Teams Great!“ von Esther Derby and Diana Larsen verweisen, die eine Agenda mit 5 Punkten vorstellen:

• Die Voraussetzungen schaffen („Set the stage“):
  In dieser ersten Phase wird nochmal das Ziel der vergangenen Iteration und die heutige Agenda vorgelesen. Sofern notwendig trifft man noch weitergehende Absprachen über die Regeln der Retrospektive (z.B. keine Handys/Laptops, keine destruktive Kritik etc.). So soll eine möglichst hohe Teilhabe der einzelnen Teammitglieder erreicht werden.
• Daten sammeln („Gather data“):
  Hier werden objektive und subjektive Informationen über die letzte Iteration zusammengetragen. Dazu soll jede Person ihre Sicht auf die Ereignisse möglichst vollständig mit einbringen. So soll ein möglichst vollständiger Überblick über die Iteration geschaffen werden. Er dient als Datenbasis für den Rest der Retrospektive
• Einsichten generieren („Generate insights“):
  Aus dem vorher erstellten Gesamtüberblick werden nun Rückschlüsse gezogen. Dafür gibt es eine Reihe von Techniken. Für eine genaue Vorstellung sei hier aber auf Teil 2 des Artikels verwiesen, da dies ansonsten den Rahmen sprengen würde. Als Ergebnis erhält man eine Liste von Vorschlägen.
• Entscheide, was zu tun ist („Decide what to do“):
  Diese Liste wird nun priorisiert. Anschließend entscheidet das Team, wieviele Einträge der Liste in der folgenden Iteration umgesetzt werden können. Zusätzlich könnte man die daraus entstehenden Aufgaben gleich auf verschiedene Personen verteilen, so dies möglich ist.
• Schließen der Retrospektive („Close the retrospective“):
  Die Ergebnisse der Retrospektive werden nochmal kurz zusammengefasst. Das könnte z.B. auch eine Liste der ToDo’s für die einzelnen Teammitglieder sein. Anschließend dankt der Moderator noch allen Anwesenden für ihre harte Arbeit. Als Abschluß kann man noch eine kurze „Retrospektive der Retrospektive“ durchführen, damit auch der Moderator die Chance hat, sich zu verbessern.

Soweit also nun ein erster Überblick über Retrospektiven. Natürlich steht und fällt ihr Erfolg mit den Ergebnissen der Schritte 2 („Daten sammeln“) und 3 („Einsichten generieren“). Hierfür gibt es eine Reihe von (teils relativ einfachen) Techniken, die sich in der Vergangenheit hier bewährt haben.

Ein Überblick über solche Methoden wird daher Teil 2 dieses Artikels bilden.

BFI