S. H.

Agile Mythen Teil 4: Retrospektiven nur nach Bedarf: völlig ausreichend!

Geschrieben von Sven Hary veröffentlich am in der Kategorie Agiles Arbeiten
Letzte Woche habe ich mit einem ehemaligen Kollegen telefoniert - wir tauschen uns unregelmäßig zu Themen wie Scrum und Team-Building aus. Bei dem Team, zu dem er gehört, habe ich Scrum eingeführt und es lange als Scrum Master begleitet. Vor einiger Zeit habe ich das Team in einem - wie ich finde - "agilen" Zustand verlassen, in dem es regelmäßig gut performed hat und die Stimmung sehr gut war. Bei den letzten Gesprächen ging es immer wieder darum, dass "es" schwierig geworden ist. 

Die Velocity ist schlechter geworden, die Stimmung sehr schwankend und einzelne Stakeholder werden unzufrieden. Die Dailys werden täglich, pünktlich abgehalten und sind meistens nach 10min zu Ende. Plannings finden statt, über das Backlog beschwert sich schon lange keiner mehr.

"Klingt eigentlich ganz gut", dachte ich. Warum also wird das Team offensichtlich schlechter?

Ich kürze das Gespräch hier mal ab: das Team (!) hatte entschieden, dass es keine regelmäßigen Retrospektiven mehr benötigt, da es ja gut zusammengearbeitet hat und die Velocity viel höher, als am Anfang war. Retrospektiven wollte das Team nur noch nach Bedarf durchführen, wenn es Probleme gibt.

 

Eine Retrospektive nur nach Bedarf durchzuführen funktioniert nicht!

Meine fünf wichtigsten Argumente, warum es nicht funktioniert, eine Retro nach Bedarf durchzuführen:

  1. Eine Retro als Extra-Termin passt nie in den normalen Ablauf. Langeweile herrscht ja nicht, warum also noch ein Meeting?
  2. Eine Retro über einen Zeitraum von mehr als 3-4 Wochen (oder gar länger) kann nicht die Tiefe einer regelmäßigen 2-wöchigen Retro haben, da in dieser Zeit zu viel passiert ist, als dass man sich noch an alles Wichtige erinnern könnte.
  3. Unregelmäßige Retros führen dazu, dass das Team sich immer wieder neu sortieren muss: versteckte Rollen im Team, "neue" Methoden, langsameres Sortieren/Reflektieren der letzten Zeit: all das behindert eine gute Retro.
  4. Fortschritte können nicht überprüft werden: Ergebnis von jeder Retro sollten ein oder mehrere Entscheidungen, Experimente oder Absprachen/Teamregeln sein. Wenn diese Ergebnisse/Absprachen nicht nach kurzer Zeit überprüft werden können, werden sie entweder vergessen, oder bleiben, ohne dass sie dem Team helfen.
  5. Der wichtigste Punkt: Den Retro-Termin einzuberufen bekommt zu viel Gewicht.
    Wer sollte sich warum "trauen", eine Retro einzufordern? "Gibt es etwa Probleme?", "Weshalb soll das JETZT nötig sein?", "Habe ich etwas verpasst? Hat jmd. Probleme mit MIR?" – Die Retro einzuberufen verkommt zu einem sensiblen, brisanten Thema, dass an sich schon zum Problem wird.

 

Warum sollte ich Retrospektiven regelmäßig durchführen?

Es ist unbestritten, dass es sinnvoll ist, ein Team zu entwickeln. Kein Team der Welt wird sich aus sich selbst heraus verbessern. Dazu drei verschiedene Quellen, die regelmäßige Retrospektiven für sinnvoll erachten:

  1. Das Agile Manifest – "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." (agilemanifesto.org)
  2. Scrum als empirisch getriebenes Framework – "Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known" (scrumguides.org)
  3. Teamentwicklung allgemein – auch abseits von agiler Entwicklung gilt Reflexion und Selbstanalyse schon seit Jahrzehnten als Schlüssel für eine gute Teamentwicklung (http://bfy.tw/DErB)

 

Wozu ist eine Retrospektive da? Warum ist sie wichtig?

Wenn ich schon dafür plädiere, die Retro regelmäßig und in kurzen Abständen durchzuführen: wozu eigentlich? Warum die Retro denn so wichtig?

Aus meiner Sicht gibt es unzählige positive Effekte einer regelmäßig durchgeführten, professionell moderierten Retrospektive. Hier meine Top 6:

  1. Kontinuierliche Entwicklung (=Verbesserung) des Teams.
  2. Versteckte Differenzen oder Frust kommen an die Oberfläche.
  3. Die Zusammenarbeit verbessert sich, weil man sich besser kennen/verstehen lernt.
  4. Jede Retrospektive stößt einen Lernprozess an.
  5. Risiken im Prozess/Projektablauf werden früh sichtbar.
  6. Das gesamte Team übernimmt nach und nach mehr Verantwortung für sich selbst und das Projekt.

 

Damit diese Punkte zum Tragen kommen, ist es wichtig, dass die Retro ein geschützter Raum ist. "What happens in the retro, stays in the retro" (auch die "Vegas-Regel" genannt ) ist essentiell, damit eine Retro funktioniert. Nur wenn das Team (bei Scrum inkl. Product Owner(!)) beschließt, dass etwas nach außen dringen darf, darf dieses eine Thema außerhalb der Retro angesprochen werden.

Einige sind der Meinung, dass eine Retro nur dann Sinn ergibt, wenn es konkrete Outcomes (=Beschlüsse, Absprachen, Experimente) gibt. Dem stimme ich zu 95% zu, aber von Zeit zu Zeit sind Retros auch dafür sinnvoll, dass "Elefanten im Raum" angesprochen werden können oder einfach mal "Luft abgelassen" werden kann. Manchmal ist das profane "Drüber-sprechen" mehr wert, als alle Methoden und konkreten Ergebnisse!

Wichtig ist auch, dass das Team die Themen bestimmen kann und dass ein neutraler Moderator (Scrum Master oder jmd. ganz externes) die Retrospektive moderiert, damit der Ablauf und die Methoden neutral sind. Auch beugt das Problemen durch unausgesprochene Hierarchien zwischen Teammitgliedern vor.

Bei allem Fokus auf Verbesserung: ich halte es für genauso wichtig, regelmäßig auf das zu gucken, was gut läuft – Entwicklungen sichtbar zu machen; festzustellen, wo man wirklich gut ist; das wird leider zu häufig vergessen, ist aber ein wichtiger Punkt, um das Selbstvertrauen im Team zu stärken und zu merken, dass "sich wirklich etwas tut". Nicht erst ein Mal habe ich erstaunte Gesichter gesehen, wenn wir die Ergebnisse/Experimente der letzten Retros reflektiert haben und festgestellt haben, wie viel positives passiert ist.

Trotzdem: der Fokus bei den Retrospektiven sollte stets auf dem Prozess und die Zusammenarbeit liegen. Es geht um Verbesserung, nicht um ein gemütliches Beisammensein. Auch hier ist ein externer Moderator hilfreich, damit es nicht dazu kommt, dass das Team im eigenen Saft sitzt und nicht bemerkt, dass es sich nicht weiterentwickelt.

Das Ergebnis hat einen hohen Einfluss

Ziel jeder Retrospektive ist es, Verbesserungen zu entwickeln. Diese können als „Experimente“ angesehen werden. Kein Ergebnis / keine Maßnahme in einem agilen Projekt ist in Stein gemeißelt. Wenn es nicht 100% Zustimmung zu einer Maßnahme gibt, kann es helfen, diese zeitlich oder umfänglich zu begrenzen und spätestens bei der nächsten Retrospektive deren Effekt zu überprüfen (Falsche Entscheidungen müssen nicht bis zur nächsten Retrospektive getragen werden, sondern können vom Team im Daily gekippt werden)

Ergebnisse aus einer Retrospektive können das Backlog beeinflussen, wenn z. B. strukturelle oder inhaltliche Probleme angesprochen wurden und neue User Stories oder Impediments aufgenommen werden müssen.

Auch das nächste Planning – direkt an die Retrospektive angrenzend - kann durch die Retrospektive beeinflusst werden. Evtl. will das Team die geplante Velocity heruntersetzen, oder hat die Definition of Done verschärft, was neue Tasks nötig macht usw.

 

Ergebnisse jeder Retrospektive

  • Impediments für das Team
  • Impediments für den Scrum Master
  • Konkrete, messbare, terminierte / zeitlich begrenzte Maßnahmen, die im nächsten Sprint ergriffen werden sollen.
  • Ursprüngliche Vereinbarungen, die obsolet geworden sind. Entweder weil sie zeitlich begrenzt waren oder keinen/nicht den erhofften Effekt hatten.

 

 

Dieser Beitrag ist Teil der Reihe Agile Mythen

Teil 1 - Wir sind doch heute alle agil!
Teil 2 - Das Daily ist Zeitverschwendung
 
Teil 3 - Bei Scrum wird nicht geplant (Chaosgefahr)
 
Teil 4 - Retrospektiven nur nach Bedarf