Agile Retrospektiven (Teil 2)

Im ersten Teil dieses Artikels habe ich ein wenig über den grundsätzlichen Aufbau einer Retrospektive erzählt und dabei folgende 5 Schritte vorgeschlagen:

1. Voraussetzungen schaffen
2. Daten sammeln
3. Einsichten generieren
4. Entscheide, was zu tun ist
5. Schließen der Retrospektive

Um jedoch zu einem möglichst guten Ergebnis zu kommen ist eine solche Agenda alleine natürlich noch nicht ausreichend. Entscheidend nämlich auch die Auswahl der richtigen Technik, vor allem in den Schritten 2 und 3. Aus diesem Grund möchte ich nun gerne einige der am weitesten verbreiteten Techniken in diesem Bereich vorstellen. Die meisten davon kann man nochmal ausführlich im Buch „Agile Retrospectives: Making Good Teams Great!“ von Esther Derby und Diana Larsen nachlesen:

Zeitleiste

Wird dazu verwendet, sich einen möglichst umfassenden Überblick über die letzte Iteration zu verschaffen. Diese Technik fällt daher in Agendapunkt 2 „Daten sammeln“. Für die Durchführung sollte man, je nach Teamgröße und Iterationslänge, in etwa 30 bis 90 Minuten veranschlagen.

Wie funktionierts?

Jedes Teammitglied schreibt alle ihm in Erinnerung gebliebenen, persönlich bedeutsame oder auf sonstige Weise wichtige Vorkommnisse der Iteration auf Karten und hängt sie chronologisch sortiert auf eine Tafel. Eine Tafel muß dabei nicht unbedingt ein Whiteboard oder Flipchart sein. Ein an die Wand gehängter Streifen Papier von einer Endlosrolle reicht hier völlig aus.

Als Variation könnte man hier auch verschiedenfarbige Karten einführen, um die Ereignisse der Iteration izu kategorisieren. Als mögliche Kategorien bieten sich dabei etwa Gefühle (von traurig bis glücklich), Ereignisart (technisch, organisatorisch, persönlich), Funktion (Fachkonzept, Entwicklung, Test/QA) oder Themengebiet (Team, Ausrüstung, Kundenbeziehung etc.) an. Hat man keine verschiedenen Farben, so muß man auf eine solche genauere Betrachtung aber trotzdem nicht ganz verzichten: Eine zeilenweise Einteilung der Tafel hat dieselbe Funktion, ist aber optisch vielleicht nicht ganz so ansprechend.

Will man ein noch umfangreicheres Bild, so kann man unter die Zeitleiste noch eine graphische Darstellung der emotionalen Hochs und Tiefs anschließen. Hier zeichnet jedes Teammitglied (am besten mit einer eigenen Farbe) seine emotionale Verfassung über den Verlauf der Iteration ein. Hohe Ausschläge zeigen hier Momente an, die stark mit Gefühlen verbunden werden. Dies ist umso signifikanter, je mehr Teammitglieder im selben Zeitraum einen ähnlichen Ausschlag eingetragen haben. Hier findet sich also bereits ein guter Einstiegspunkt in die Diskussion. Um zu wissen, was an dem entsprechenden Moment vorgefallen ist reicht jetzt nur noch ein Blick auf die in diesem Bereich aufgehängten Karten – die Wahrscheinlichkeit, daß ein solch emotionaler Moment sich auch auf den Karten wiederfindet ist nämlich relativ hoch.

Ein Beispiel dafür ist in der untenstehenden Abbildung zu finden: Die rote, grüne und blaue Kurve zeigen jeweils Ausschläge am Anfang und am Ende der Iteration. Nur die orange Kurve hat einen anderen Verlauf. Ein Blick auf die Tafel zeigt hier, daß die „Dichte“ an Karten zu diesen Zeitpunkten in der Iteration am höchsten ist. Wenn man sich die betreffenden Karten nun genau ansieht, so wird man sicher bald auf die Ursache kommen. Interessant ist hier, daß die Gründe für den Ausschlag bei den verschiedenen Mitarbeitern nicht immer gleich sein müssen. Einer ärgerte sich z.B. immer über gebrochene Builds, während ein anderer zu diesem Zeitpunkt etwa nicht vernünftig testen konnte und dadurch in Rückstand geriet. Da die Zeitleiste aber einen umfassenden Blick auf die Iteration bietet (aus Sicht mehrerer Personen) kann man so auch komplexere Ursachen identifizieren.

Fischgrät-Diagramm

Diese Methode ist ebenfalls in Phase 2 „Daten sammeln“ zu sehen. Mit ihrer Hilfe kann man tiefere Einsichten auch in längere Iterationen erhalten. Man kann mit ihrer Hilfe hinter die Symptome schauen, um die einem Problem zugrundeliegenden Ursachen zu erkennen. Dazu identifiziert das Team die Faktoren, die ein spezifisches Problem verursachen, und sucht dann nach den wahrscheinlichsten Ursachen. Anschließend werden Mittel und Wege gesucht, wie man sie ändern bzw. beeinflussen kann. Fischgrät-Diagramme sind daher auch als „Ursache-und-Wirkung“-Diagramm bekannt. Für die Erstellung sollte man in etwa 30 bis 60 Minuten planen.

Wie funktionierts? Um ein solches Diagramm anzufertigen geht man nach den folgenden Schritten vor:

1. Man schreibt das zu untersuchende Problem an das Kopfende des Diagramms
2. Anschließend werden die „Gräten“ des Fisches mit den wichtigsten Einflussfaktoren überschrieben. Wenn man noch eine Stufe weitergehen will, so kann man sie auch noch nach Wichtigkeit sortieren: Ja näher am Kopf, desto wichtiger
3. Im Rahmen eines Brainstorming versucht man nun, für jede Kategorie (d.h. jede Gräte) Faktoren zu bestimmen, die Auswirkungen auf das Problem haben. Diese schreibt man dann entlang der jeweiligen Gräte auf (alternativ kann man aber z.B. auch Post-Its anbringen). Wenn nötig kann man noch weitere Unterzweige einführen. Man sollte aber nicht zu tief verzweigen, um die Übersichtlichkeit zu wahren.
4. Die letzten beiden Schritte wiederholt man nun solange, bis man sich sicher ist, aller Ursachen berücksichtigt zu haben. Man sollte jedoch aufhören, sobald man nur noch Ursachen identifiziert, die außerhalb des Einflussbereichs des Teams liegen, da das ansonsten zuviel Zeit kosten würde. Es soll ja nicht Ziel der Retrospektive sein, ein voll ausgestaltetes Diagramm zu produzieren, sondern Lösungen für die vorherrschenden Probleme zu finden. Ein Diagramm ist hierbei aber nur ein Hilfsmittel, kein Ergebnis.
5. Nun schauf man sich die gefundenen Einträge an. Tauchen einige davon gleich in mehreren Kategorien auf, so sollte man diese zuerst besprechen, da das die wahrscheinlichsten Ursachen sind. Man sollte jedoch darauf achten, daß sich die Diskussion vorwiegend um Dinge dreht, die das Team selbst unter Kontrolle hat, da ihre Lösung direkt angegangen werden kann.

Ist man damit fertig, so erhält man eine Liste von Ursachen für das gestellte Problem. Daraus kann man dann verschiedene zu erledigende Aufgaben ableiten, die man dann in der nächsten Phase der Retrospektive „Entscheide, was zu tun ist“ behandeln kann. Hier ein Beispiel für ein solches Diagramm:

Team-Radar

Auch diese Methode ist noch in Phase 2 der Retrospektive angesiedelt. Sie dient dazu, dem dem Team einen Überblick darüber zu geben, wie gut es in verschiedenen Disziplinen abschneidet, etwa Kommunikation, Feedback, Entwicklungspraktiken etc. Einen solchen Graphen zu erstellen dauert weniger lange als die beiden bisher vorgestellten Praktiken. 15 bis 20 Minuten sollten ausreichend sein.
Wie funktionierts?

Man malt die zu untersuchenden Disziplinen als jeweils eigene Achse in ein Koordinatensystem. Alle Achsen werden mit einer Skala versehen. Dann lässt man jedes Teammitglied seine Einschätzung zu jeder Achse direkt auf die Tafel eintragen. Sind alle damit fertig, so kann man daraus auf einen einzigen (gemeinsamen) Wert kommen, indem man z.B. das arithmetische Mittel berechnet, das Team ausdiskutieren lässt etc. Es ist aber trotzdem ganz interessant, trotzdem auch mal einen Blick auf die vom Team auf den Achsen eingetragenen Werte zu werfen. Gibt es hier nämlich große Abweichungen, so kann das ebenfalls auf einen Diskussionsbedarf hinweisen. Verbindet man anschließend die gefundenen Mittelwerte auf den verschiedenen Achsen miteinander, so erhält man einen Graphen, der ähnlich einem Radarbild ist. Übrigens lohnt es sich, ein solches Bild auch mal bis zur nächsten Retrospektive aufzubewahren, und das Team dann die selben Disziplinen nochmal schätzen zu lassen. So kann man die Veränderungen zum letzten Mal sehen und dann darauf eingehen. Hier ein Beispiel für einen Team-Radar-Graphen:

Kraftfeldanalyse

Diese Technik kommt in Phase 4 „Entscheide, was zu tun ist“ zum Einsatz und baut z.B. auf der oben vorgestellten Fischgrät-Technik auf. Es ist eine (relativ einfache) Methode, um die unterstützenden und bremsenden Kräfte in einer Situation zu analysieren. Für die Umsetzung sollte man sich dabei in etwa 45 bis 60 Minuten Zeit nehmen.

Wie funktionierts?

Das Team defniniert einen Zustand, den es zu erreichen gilt, und schreibt ihn als Überschrift über das Diagramm (alternativ würde auch ein beschrifteter Kasten in der Mitte gehen). Danach bildet man 2 Spalten, eine für unterstützende, eine für bremsende Faktoren. In jede Spalte trägt man dann die entsprechenden (in den vorherigen Phasen der Retrospektive identifizierten) Faktoren ein. Anschließend weist man noch jedem Faktor eine Stärke zu. Normalerweise verwendet man dazu verschieden dicke Pfeile, die immer in Richtung Mitte zeigen. Hat man dies beendet, so erhält man ein Bild, das in etwa so aussieht:

Um nun zum gewünschten Zielsituation zu kommen kann man nun an 2 verschiedenen Schrauben drehen:

1. Man kann die treibenden Faktoren verstärken
2. Man kann die bremsenden Faktoren abschwächen

Für das Beispiel oben würde das also bedeuten, daß man sich daran machen sollte, die Faktoren 2 und 3 wenn möglich zu verstärken, und die Faktoren 7 und 10 abzuschwächen. Natürlich muß man auch hier wieder abwägen, welche Faktoren überhaupt im Einflussbereich des Teams liegen und welche nicht. Viele Teams können zwar mehr beeinflussen als sie zunächst denken. Jedoch ist es auch hier ratsam, den Hebel zuerst an die Faktoren anzulegen, die den größten Erfolg versprechen. Man erhält aber auch so einen interessanten Einblick über die für und gegen einen arbeitenden Kräfte und kann dadurch auch in etwa abschätzen, wieviel Aufwand man in die Lösung dieses speziellen Problems stecken muß. So kann man besser entscheiden, ob dieser Aufwand gerechtfertigt ist oder nicht. Sieht man sich die oben beschriebenen Techniken mal in ihrer Gesamtheit an (v.a. hinsichtlich des Zeitbedarfs), so sollte einem nun auch klar werden, wieso Retrospektiven mindestens einen halben, besser aber einen ganzen Arbeitstag pro 4-wöchiger Iteration in Anspruch nehmen sollten. Das mag zwar auf den ersten Blick ein wenig hoch erscheinen (immerhin wird in dieser Zeit keine neue Funktionaliltät umgesetzt), macht sich aber durch die erreichbaren Produktivitätsverbesserungen meistens schon nach wenigen Wochen positiv bemerkbar. Außerdem, und das sollte man dabei auch nicht vergessen, trägt ein gelebter Verbesserungsprozeß auch zur Zufriedenheit des Teams bei. Bereits das alleine wäre schon die Mühe wert – denn nur ein zufriedenes Team ist ein produktives Team! BFI