Wenn Du mich kennst dann weißt Du, dass ich ein großer Fan von Retrospektiven bin. Warum also nicht mal wieder was über Retrospektiven machen? Gesagt getan, in diesem Artikel stelle ich Dir typische Fehler vor, die mit immer wieder in Retrospektiven begegnen. Du hast keine Lust zu lesen? Kein Problem, hör Dir das ganze einfach hier an:
Für alle die lieber lesen geht es hier los. Was sind also die Dinge, die Du in Deinen Retros besser vermeiden solltest?
Immer neue Aktivitäten
Ja, ich weiß. Jeden Sprint die gleichen Retros zu moderieren kann auf Dauer echt langweilig werden. Die Frage ist nur: wer langweilt sich? Du oder das Team? In der Regel liegt es nicht an den Aktivitäten, dass Deine Retros nicht die gewünschten Effekte bringen. Als ich vor 10 Jahren auf der ACE!Conference ich Krakau, Polen einen Vortrag zum Thema Retrospektiven gehalten habe, bin ich dieselbe Falle getappt. In meinem Vortrag ging es darum, wie man seine Retros spannender und abwechslungsreicher gestalten kann. Nach dem Vortrag kam ich dann mit Bob Marshall ins Gespräch, der mich darauf hinwies, dass das vermutlich nicht (immer) zielführend ist. Er sagte: "You are doing the wrong thing righter", also man macht das Falsche richtiger (Inject Purpose Into Retrospectives). Den Vortrag kann man sich übrigens immer noch hier ansehen.
Anstatt also immer neue Aktivitäten aus dem Retr-O-Mat auszuprobieren, sollte man sich überlegen, ob man nicht etwas anderes grundlegend ändern sollte. Was das sein könnte kommt im weiter unten.
Zu wenig Zeit
In Scrum ist für einen 4-wöchigen (1 Monat) langen Sprint eine Retrospektive von bis zu 3 Stunden vorgesehen. Bei einem 2-wöchigen Sprint wären das 90 Minuten. Das ist meiner Meinung nach die Zeit, die man sich auf jeden Fall nehmen sollte. Natürlich kann man auch mal eine kürzere Retro machen, aber gerade bei frischen Teams sind 60 Minuten einfach zu kurz. Dies führt dann häufig dazu, dass die Ergebnisse eher eine mindere Qualität haben.
Keine klaren Timeboxen
Häufig kann man beobachten, dass für die letzte Phase, in der es darum geht die Experimente (Maßnahmen) für den nächsten Sprint zu definieren, zu wenig Zeit bleibt. Deshalb sollte man sich für jede Phase eine Timebox überlegen. In meinem Buch "Retrospektiven in der Praxis", schlage ich dafür die folgenden Timeboxen vor (um es einfacher zu rechnen, nehme ich eine Stunde für die Retro an):
- 5 Minuten (1/12): Gesprächsklima schaffen
- 5 Minuten (1/12): Hypothesen überprüfen
- 10 Minuten (1/6): Daten sammeln (die wichtigsten Themen kommen sowieso zu erst)
- 20 Minuten (1/3): Einsichten gewinnen
- 15 Minuten (1/4): Experimente und Hypothesen definieren
- 5 Minuten (1/3): Abschluss
"Grüne Wiese" Retros
Viele Retros fangen immer damit an (neue) Daten zu sammeln. Dabei ist es viel wichtiger zu überprüfen, ob die Experimente des letzten Sprints den gewünschten Effekt hatten. Wenn nein, dann muss es in der Retro darum gehen, neue Experimente zu entwicklen, da das Thema der letzten Retro noch nicht gelöst wurde.
Sollte es sogar so sein, dass keines der Experimente durchgeführt wurde, dann sollte man diskutieren woran das lag und was man machen kann, damit es im nächsten Sprint gelingt.
Nur wenn sich alle Hypothesen der letzten Retro bewahrheitet haben, macht es Sinn wieder "auf der grünen Wiese" zu starten. Eventuell macht es auch Sinn mit zielgerichteten Retrospektiven zu arbeiten und sich z.B. für ein Vierteljahr auf das Thema Softwarequalität zu fokussieren.
Zu viele Ergebnisse
Hier kommt der beste Tipp überhaupt. Fokussiere Dich darauf ein (!) gutes Experiment zu definieren, als drei Fadenscheinige. Zum einen hat man in der Regel garnicht die Zeit an vielen Experimenten gleichzeitig zu arbeiten und zum anderen ist die Gefahr groß, dass die Experimente nur sehr ungenau definiert sind. Am besten nutzt Du das berühmte SMART-Akronym, um ein gutes Experiment zu definieren.
Keine Hypothesen
Jedes Experiment am Ende der Retrospektive, braucht eine messbare Hypothese. Du musst klar definieren, was Du mit dem jeweiligen Experiment erreichen möchtest, um in der nächsten Retrospektive zu kontrollieren, ob Dein Experiment den gewünschten Effekt hatte.
