Am gestrigen Montag fand der 3. Agile Monday Schwäbisch Hall im Brauersaal des Gasthof Goldener Adler statt. Thema diesmal: Nachhaltige Retrospektiven, vorgestellt von Daniel Hommel.
Die Sprint Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. (…) Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein.
Zwar ist dies die Definition nach Scrum, allerdings ist das »Lessons Learned«-Konzept im Grunde nichts anderes. Entscheidender Unterschied: innerhalb von Scrum findet dieses Meeting in regelmäßigen Abständen am Ende jedes Sprints – statt nur lediglich am Projektende – statt.
Ziel jeder Lessons Learned / Retrospektive ist letztlich aber immer sich auf mindestens eine Verbesserung zu einigen, die in Zukunft vom Team umgesetzt wird. Gleichzeitig gibt es zwei Regeln, die auf jeden Fall eingehalten werden sollten:
- Prime Directive: »Regardless of 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 resources available, and the situation at hand.«
Sprich: Der zu ermittelnde Fehler ist ein Fehler im System, nicht der Fehler einer einzelnen Person. Den Schwarzen Peter zuzuschieben ist also unbedingt zu vermeiden. - Las Vegas Regel: »What happens in Vegas, stays in Vegas.«
Was das Team innerhalb seiner Retrospektiven bespricht, sollte auch innerhalb des Teams bleiben und nicht an Kunden, Stakeholder und andere weiter getragen werden.
Für den Ablauf einer Retrospektive gibt es keine verbindlichen Vorgaben, jedoch haben sich fünf Punkte als hilfreich heraus kristallisiert:
- Opening / Setting the stage
Wiki: »Zuerst werden die Voraussetzungen für eine offene Atmosphäre geschaffen. Die Teilnehmer sollen sich wohl dabei fühlen, offene Punkte zu diskutieren. Dabei gilt die Annahme, dass jeder die bestmögliche Arbeit geleistet hat, die er oder sie leisten konnte, und zwar unabhängig davon, welche offenen Punkte identifiziert werden.« - Sammeln
Wiki: »Zweitens werden Informationen gesammelt. Dies geschieht oft, indem man zurückblickt und identifiziert, was gut gelaufen ist und was nicht.« - Sortieren, Auswahl treffen, Ursachenanalyse
Wiki: »Im dritten Schritt werden Erkenntnisse entwickelt. In dieser Phase identifizieren Teams normalerweise, warum Dinge geschehen sind, damit nicht nur Symptome kuriert, sondern die tatsächlichen Ursachen identifiziert werden.« - Entscheidungsprozess
Wiki: »Viertens entscheidet man, was zu tun ist. Das umfasst Vereinbarungen über sinnvolle und realistische Schritte, die im nächsten Sprint umgesetzt werden sollen.« - Closing
Wiki: »Zu guter Letzt wird die Retrospektive abgeschlossen.«
Für alle Retros gilt:
Man muss die Welt nicht an einem Tag retten.
Nimmt man sich zu viele Dinge vor, die man ändern möchte, übernimmt man sich in der Regel. Wie es schon im ersten Ziel heißt: eine Veränderung kann (je nach Sprint-Länge) bereits ausreichen.
Schön – und jetzt?
Ist man einmal soweit, dass man die typischen Dysfunktionen herausgearbeitet hat, stellt sich nun die Frage welche dieser Dysfunktionen man angeht und wie man das tut.
Hierfür gibt es unterschiedliche Herangehensweisen. Zunächst sollte man sich aber über seinen Einflussbereich im Klaren sein.
- Welche Lösungen kann man direkt beeinflussen?
- Welche nur indirekt?
- Auf welche hat man keinen Einfluss?
Für diese drei Einflussbereiche gibt es drei einfache Reaktionen:
- Direkt —> machen!
- Indirekt —> beeinflussen!
- Kein Einfluss —> abhaken!
Um letztlich noch herauszuarbeiten, welche der Dysfunktionen überhaupt angegangen werden sollen, gibt es unterschiedliche Ansätze. Denkbar sind hier:
- Low Hanging Fruits
Einfach zu erledigende Aufgaben, die zuerst erledigt werden sollen. - Cost of Ignorance / Cost of Delay
Welchen Nachteil hat das Team, wenn es das Problem nicht angeht? - MoSCoW-Priorisierung
M – MUST (unbedingt erforderlich)
S – SHOULD (sollte umgesetzt werden, wenn alle MUST-Anforderungen trotzdem erfüllt werden können)
C – COULD (kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird)
W – WON’T (wird diesmal nicht umgesetzt, aber für die Zukunft vorgemerkt)
Als zusätzlichen Anreiz hat Daniel außerdem das Prinzip »Solution Focus« vorgestellt. Dieses Konzept kommt aus der Gesprächstherapie und versucht Lösungen für ein bestimmtes Ziel zu ermitteln – nicht für eventuell existierende Probleme. In vier Schritten soll so der Weg zum Ziel ermittelt werden:
- Preferred Future: Wie stellt man sich das Idealbild der Zukunft vor?
- Skalenfrage (Auf einer Skala von X bis Y): Wie viel des Weges ist man eigentlich schon gegangen?
- Was ist schon da?
- Was kommt als nächstes?
Buchempfehlung hierzu: Agile Teams lösungsfokussiert coachen von Veronika Kotrba & Ralph Miarka
TL;DR
Der dritte Stammtisch »Agile Monday« war diesmal stärker auf die Teilnahme der Anwesenden ausgelegt. Jeder sollte sich zum Prinzip »Retrospektive« seine eigenen Gedanken machen und konnte im weiteren Verlauf seine bereits gemachten Erfahrungen mit den anderen austauschen und Lösungsansätze diskutieren.
Wer in der Nähe und im Bereich des »Agilen« unterwegs ist bzw. Interesse daran hat, sollte einfach selbst mal vorbei schauen. Der nächste findet am 5. September statt. Infos gibt es in der Xing-Gruppe »Agile Monday Schwäbisch Hall«.