Retrospektiven und Streitkultur (2)

Retrospektiven als Basis agilen Projektmanagements oder: gelebte Streitkultur »
Alexander Maisch

Veränderung
Veränderung ist unausweichlich
Agile Methoden begrüßen Veränderungen
Alle Projektbeteiligten lernen und setzen dieses
     Wissen für den Projekterfolg ein

5 Schritte:
Voraussetzungen schaffen
Daten sammeln 
Einsichten generieren
Entscheiden, was zu tun ist
Abschluß der Retrospektive
Techniken zur Unterstützung
Zeitleiste
Team-Radar
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
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.
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.
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.
Retrospektiven
Streitkultur
Häufig wird Streit als etwas grundsätzlich Negatives angesehen 

Die kreative Auseinandersetzung mit anderen Standpunkten hilft:

die ausgetretenen Wege zu verlassen
einen neuer Blick auf bestehende Probleme zu entwickeln 
Konstruktiver Umgang mit Streit
Anerkennen der Existenz von  
unterschiedlichen Wahrnehmungen,
Meinungen und 
Folgerungen 

Erfordert Sicherheit
Vereinbarte Regeln für den Umgang mit Streit
Moderation von Streit-Gesprächen 

Streitregeln
Retrospektiven: gelebte Streitkultur
Sie können direkt aus dem agilen 
Manifest / Prinzipien abgeleitet werden:

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



“Regardless what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills, and abilities, the resource available and the situation at hand”
Man kann nicht zweimal in denselben Fluss steigen
(Heraklit)
Fischgrättechnik
(ein ganz persönliche Auswahl)
Streiten ist erlaubt
Es gibt ein Zeitlimit für den Streit
Jeder Beteiligte kann den Streit verschieben
Nicht Schuld, sondern Lösungen suchen
Ist der Streit beigelegt, soll die Beziehung zwischen den Beteiligten nicht nachhaltig gestört sein
Konflikte ansprechen, den richtigen Zeitpunkt zur Lösung finden
Streit ist kein Sport
Beim Überschreiten einer gewissen Eskalationsstufe müssen andere Mechanismen in Kraft treten
Die Regeln sind allen Beteiligten bekannt und anerkannt
Retrospektiven werden von einem Moderator geführt und begleitet (Scrum Master).
Retrospektiven schaffen ein gemeinames Bild der vergangenen Iteration und bilden so eine Basis für die Akzeptanz von anderen Standpunkten.
Ein fester und verlässlicher Rahmen für das Team. Die Regeln sind allen Beteiligten bekannt und werden auch öffentlich gemacht. 
Retrospektiven folgen immer einer konkreten Zielsetzung. Dadurch ergibt sich eine Fokussierung weg von der Schuldfrage hin zu  möglichen Lösungen.
Oberste Direktive
alexander.maisch@interface-ag.com
bernhard.findeiss@interface-ag.com

http://www.interface-ag.de/blog/
http://www.scrum-poster.de/

Loading comments...

Please log in to add your comment.

Report abuse