Beobachten, messen, reflektieren und daraus lernen gehören für Teams, die nach agilen Prinzipien arbeiten, zur täglichen Routine. Sie stellen damit sicher, dass sich ihr Produkt wie auch ihre Zusammenarbeit laufend an eine sich ändernde Umwelt anpassen. Stolz auf das entstehende Produkt und das Team und dennoch unermüdlich auf der Suche nach Verbesserungen. Ein bekanntes Element des Verbesserungszyklus sind die Retrospektiven. Populär wurden sie mit Scrum. Dort sind sie eines der offiziellen Ereignisse, durchzuführen an jedem Sprint-Ende. Aber auch in vielen anderen Teams haben sich Retrospektiven etabliert.
- Das Teamwork reflektieren
In Retrospektiven geht es nicht um das Resultat der Arbeit, das Produkt, sondern um die Team-Zusammenarbeit. Typischerweise werden in einer Retrospektive folgende Fragen gestellt:
Was ist in letzter Zeit geschehen? Welche positiven und negativen Ereignisse und Zustände sind eingetreten? - Weshalb haben wir dies beobachtet?
- Was wollen wir unbedingt beibehalten od. sogar noch verbessern, was müssen wir korrigieren?
- Wie wollen wir es verändern?
Daraus sollten einige wenige Massnahmen entstehen, die das Team im nächsten Sprint umzusetzen vermag, oder Anpassungen an den Teamregeln, zu denen sich das Team verpflichtet.
Die Realität hält sich nicht immer an die Theorie
Eine der Herausforderungen bei der Einführung von Retrospektiven ist immer wieder deren Häufigkeit. Arbeitet das Team in zweiwöchigen Sprints, finden die Retrospektiven alle zwei Wochen statt. Kaum ist eine Team-Reflexion vorüber, steht schon die nächste vor der Tür. Und damit ist der Scrum-Master (der "Moderator") gefordert, ein passendes - inspirierendes - Format zu kreieren. Es gibt hierfür jede Menge Tipps & Tricks, gute Bücher und zahllose Blogs im Netz. Bewährt hat sich ein Ablauf mit fünf Schritten, basierend auf dem Buch "Agile Retrospectives: Making good teams great" von Derby/Larsen. Passt das in jedem Fall? Meine Erfahrung lehrt mich etwas Anderes. Der Scrum-Guide legt ein starkes Gewicht auf die Verbesserung der Entwicklungsprozesse und Werkzeuge - aber nicht nur. Ganz prominent werden die Beteiligten und ihre Beziehungen erwähnt. Und interessanterweise kommen gerade diese weichen Faktoren bei standardisierten Agenden zu kurz. Wieso? Es gibt unterschiedlichste Team-Konstellationen, Reifegrade, spezifische Herausforderungen und Persönlichkeiten in Teams und deren Umfeld. Längst nicht alle Teams sind neu zusammengesetzt und entwickeln gemeinsam Software. Immer wieder begleite ich "untypische" agile Teams, z.B. Teams, die seit langem zusammen arbeiten, einfach bisher nicht agil und die vielleicht erstmals in kurzen Sprints vorgehen. Oder Teams, die keine SW entwickeln, aber dennoch die Transparenz und Resultate kurzer Zyklen schätzen. Häufig in traditionell strukturierten Umfeldern, vielfach auch mit Spezialisten die nur zu 40% mitarbeiten.
Mit Offenheit und Kreativität zurück zum Zweck
Retrospektiven mit strukturiertem Ablauf und klarem Fokus auf eine kurze Liste von Massnahmen sind toll, wenn die Mehrheit der Teilnehmer ihren Wert schätzen. Das eigentliche Ziel ist immer, die Zusammenarbeit im Team zu verbessern. Punkt. Langjährige Teams die recht offen über ihre Themen sprechen können, empfinden rigide Agenden oft unnatürlich oder das Kosten/Nutzen-Verhältnis als gering. Entsprechend gerät die ganze Praktik in Misskredit. Andererseits schätzen sie es, einmal eine Plattform zu haben, um darüber zu sprechen, was sie gerade beschäftigt, ohne fixe Agenda. Und da haben kreative Ideen Platz. Wie wäre es, das Meeting ins Freie zu verlegen, oder das Team auf einen Spaziergang mitzunehmen? Zum Beispiel mit dem Auftrag zu zweit oder zu dritt etwas übereinander zu lernen, ein (früheres) Hobby, seine Familie oder einen Lebenstraum. Oder ein bestimmtes Teamthema zu beleuchten. Da kommt häufig Überraschendes zum Vorschein. Zurück im Teamraum werden ggf. die Erkenntnisse gesammelt oder die Erkenntnisse einfach stehen gelassen. Auch ein Lean Coffee eignet sich als offenes Format, evtl. ergänzt mit einer Umfrage nach jedem Thema, ob das Team einen Follow-up wünscht. Auch die Häufigkeit von Retrospektiven darf kein Tabu sein. Wieso nicht: statt alle zwei Wochen ein belächeltes Meeting lieber alle vier Wochen eines mit Wirkung. Und noch ein Gestaltungselement: das Team entscheidet sich für eine freiwillige Teilnahme. Wer nicht dabei war, muss mit den Resultaten leben.
Den agilen Prinzipien treu bleiben
Und was, wenn die Einführung von Retrospektiven auf Widerstand stösst? Müsste dann der Moderator bzw. Scrum-Master einfach härter verkaufen oder ist er ein Weichei? Ja und nein. Natürlich gehört Frustresistenz und Verkaufen zu den Tugenden eines guten Moderators. Eine Praktik auch gegen initialen Widerstand der Betroffenen einmal einzuführen und sie eine Zeit lang auszutesten kann Augen öffnen, Probleme transparent machen, Erfahrungen verändern. Kulturwandel funktioniert aber nicht auf Befehl, sondern über die Veränderung des Kontextes. Die Menschen müssen das Neue wollen, es muss ein "Pull" entstehen - und es soll auch Spass machen! Im Idealfall werden sie Fans des Neuen und verkaufen es dann gleich weiter. Dein Team ist noch kein Fan von Retrospektiven? Mache die tagtäglich auftauchenden Fragen doch einfach mal in einem sichtbaren Themenspeicher transparent. Die Sinnfrage beantwortet sich dann von selbst. "Transparency, Inspect & Adapt" - die agilen Prinzipen sind nicht verhandelbar.
