Die Retrospektive als Workshop
Es gibt für Retrospektiven kein kategorisch richtiges oder für alle Situationen passendes Format, jedes Team kann seine eigene Variante entwickeln. Umgekehrt gibt es aber Verhaltensmuster, die besser zu vermeiden sind. Ein leider immer wieder anzutreffendes besteht daraus, Probleme nur zu identifizieren, für ihre Lösung aber später stattfindende Folgetermine einzurichten (oder noch schlimmer: sich lediglich vorzunehmen, derartige Termine zu planen).
Dabei ist es natürlich nicht so, dass es gar keine Konstellationen gäbe, in denen dieses Vorgehen Sinn macht. Wenn für eine Problemlösung z.B. Fachexperten oder Kooperationspartner anwesend sein müssen, die nicht zum Team gehören, dann muss man selbstverständlich vorher deren Verfügbarkeit und Bereitschaft in Erfahrung bringen. Aber bei Team-internen Themen, wie z.B. der Überarbeitung der eigenen Definition of Done, ist diese Sinnhaftigkeit nicht gegeben.
Dass trotzdem immer wieder so vorgegangen wird hat verschiedene Gründe. Ein häufiger ist der, dass auf diese Weise (scheinbar) mehr Themen erledigt werden können: nur Fünf Folgetermine zu planen geht schneller als Fünf Themen zu besprechen und zu Ergebnissen zu kommen. Auch dass das Thema für einen Teil der Anwesenden von nur wenig Interesse ist, ist ein häufiger Grund. Und ein ebenfalls häufiger (wenn auch keineswegs Guter) ist der, dass man schon immer so vorgegangen ist.
Die Folgen dieser Vorgehensweise sind zum einen, dass die Kalender immer voller werden, und zum anderen, dass die angestrebten Lösungen und Ergebnisse immer später entstehen. Diese Phänomene stehen sogar in Beziehung zueinander. Weil für zusätzliche Meeting nicht unbegrenzt Zeit (und Lust) vorhanden sind, kann nur eine begrenzte Zahl zeitnah stattfinden. Schlimmstenfalls können sie sogar erst so weit in der Zukunft stattfinden, dass bis dahin schon die nächste Retrospektive stattgefunden hat.1
Ein deutlich besseres Vorgehen ist es, die aufgekommenen Themen direkt in dem Termin zu behandeln, in dem sie zum ersten Mal thematisiert wurden. Um beim oben genannten Beispiel zu bleiben: wenn eine Überarbeitung der eigenen Definition of Done nötig ist, dann ist das etwas, was sofort angegangen und erledigt werden kann. Das Gleiche gilt auch für zahlreiche weitere Themen, von Coding Standards über zwischenmenschliche Unstimmigkeiten bis zur Planung des nächsten Team-Events.
Bleiben noch die gerade genannten Einwände. Einfach zu entkräften ist der Erste: mehrere Themen nur kurz anzudiskutieren und dann Folgetermine zu vereinbaren, sorgt eben nicht dafür, dass insgesamt mehr erledigt werden können. Es führt nur dazu, dass die Arbeit an mehreren parallel begonnen wird (ein wichtiger Unterschied). Nur an wenigen zu arbeiten, dafür aber richtig, lässt natürlich andere Themen unbehandelt - aber wenn sie wichtig bleiben, können sie nächstes Mal erneut eingebracht werden.
Dass bei manchen Themen nicht alle Mitglieder eines Teams nicht alle bei allen Themen in gleicher Tiefe mitreden können ist schon ein besseres Argument, aber auch kein wirklich Gutes. Zum einen bietet ein sofortiges und gemeinsames Angehen die Möglichkeit, neue Themen kennenzulernen und in ihnen besser zu werden. Und sollte der Extremfall zweier extrem unterschiedlicher Teilteams gegeben sein, lassen sich ggf. auch zwei Arbeitsgruppen bilden, von denen jede an jeweils einem Thema arbeitet.
So oder so sollten die Vorteile einer sofortigen Problembehandlung durch eine Workshop-artige Retrospektive klar sein. Schnelle Ergebnisse, kein Aufschieben der Lösungsfindung auf zukünftige Zeitpunkte, keine zusätzlichen Meetings, kein paralleles Herumwerkeln an mehreren Themen. Warum nicht alle Teams das so sehen ist mir schleierhaft, aber immerhin ist es meine Erfahrung, dass die meisten sich darauf hinweisen lassen und diesen Impuls dann auch verstehen und annehmen.
