Die vorliegende Abschlussarbeit entstand im Zuge der Ausbildung zum systemischen Master Business Coach (ECA) an der Internationalen Akademie Berlin für innovative Pädagogik, Psychologie und Ökonomie gGmbH (INA). Sie beleuchtet, inwieweit die in der agilen Softwareentwicklung bewährte sogenannte agile Retrospektive als Intervention zur kontinuierlichen Prozessverbesserung dem Muster der Theorie-U von Otto Scharmer, sowie dem Ablauf einer Coaching-Sitzung folgt, und wie sie sich mittels der Theorie-U sowie Methoden aus dem systemischen Business Coaching planen und als Kurzzeit-Teamcoaching durchführen lässt. Im Rahmen der Arbeit werden einleitend die Begriffe Agile Retrospektive, sowie Theorie-U und systemisches Business Coaching erläutert. Anschließend werden die Phasen der agilen Retrospektive den Phasen der Theorie-U und dem Ablauf einer typischen Coaching-Sitzung gegenübergestellt. Im letzten Teil wird eine beispielhafte agile Retrospektive als Kurzzeit-Teamcoaching konstruiert. Dazu werden exemplarisch bekannte Tools für agile Retrospektiven in das Phasenmodel der Theorie-U einsortiert und ein vollständiger Ablauf gebildet.

Agile Retrospektive

Im folgenden Abschnitt wird erläutert, was unter dem Begriff der agilen Retrospektive verstanden wird, wo diese Methode angewendet wird und welches Ziel sie verfolgt. Zusätzlich wird der typische Ablauf einer solchen Sitzung dargestellt.

Was sind agile Retrospektiven

Die Retrospektive ist ein regelmäßiges Team-Meeting, bei dem die Teammitglieder gemeinsam zurückblicken (retrospectare ist Latein für “zurückblicken”), um Problemfelder zu identifizieren und Wege zu finden, die Arbeit zu verbessern. Sie können auch verstanden werden als ein “[...]Mini-Post-Mortem, nur dass das Objekt der Reflexion noch lebt.” (Pichler 2008, S. 111). Sie hat also einen rückwärtsgewandten Teil, nutzt aber die gewonnen Erkenntnisse, um wieder in die Zukunft zu blicken. R. Davies und L. Sedley empfehlen daher in ihrem Buch (Davies and Sedley 2009, S. 262) folgendes Vorgehen:

Nehmen Sie eine Hälfte der Retrospektive, um auf die vergangene Iteration zurückzuschauen, um Erkenntnisse darüber zu gewinnen, was geschehen ist und warum. Schauen Sie anschließend nach vorn und entwickeln Sie Ideen, wie man die Dinge verbessern kann sowie Aktionspläne, um diese Ideen umzusetzen.

Die Sinnhaftigkeit für den Einsatz von Retrospektiven erschließt sich mehr als deutlich durch die Aussage des Autors Henrik Kniberg, der in (Davies and Sedley 2009) wie folgt zitiert wird:

Ohne Retrospektiven würde das Team den gleichen Fehler immer wieder machen.

Im SCRUM, einer agilen Vorgehensmethode zur Softwareentwicklung, sind Sprint Retrospektiven fester Bestandteil und finden nach jeder Entwicklungsiteration statt. Dem Scrum Guide¹ nach wird der Zweck der Retrospektive darin gesehen “[...] Wege zur Steigerung von Qualität und Effektivität zu planen.” (Schwaber and Sutherland 2020, S. 10).

Gefolgt wird dabei dem agilen Grundsatz “Inspect and Adapt”, bei dem nicht nur Produkte und Prozesse immer wieder überprüft und durch Anpassung verbessert werden sollen, sondern auch die Zusammenarbeit in einem Team. Immer wieder soll dabei der Fokus darauf gelegt werden, wie das Team arbeitet und interagiert (vgl. (Derby, Larsen, and Schwaber 2006) xv-xvi).

Im folgenden Kapitel wird auf den Prozess und den Ablauf kurz eingegangen, damit sich Leserinnen und Leser eine bessere Vorstellung machen können. Zur ausführlicheren Darstellung sei auf gängige Literatur verwiesen, wie beispielsweise “Agile Retrospectices - Making Goot Teams Great” von E. Derby und D. Larsen ((Derby, Larsen, and Schwaber 2006)).

Struktur einer agilen Retrospektive

Eine Retrospektive folgt immer mehr oder weniger strikt dem gleichen Muster (entnommen aus (Derby, Larsen, and Schwaber 2006) und durch den Autor frei übersetzt):

1. Set the stage (Intro).

2. Gather data (Daten Sammeln).

3. Generate insights (Einsichten erzeugen).

4. Decide what to do (Entscheiden, was zu tun ist).

5. Close the retrospective (Abschluss).

Üblicherweise werden in jeder Phase spezielle Aktivitäten ² verwendet, um den Gedankenfluss und den Austausch zu unterstützen. So besteht eine Phase aus eine weitgehend stillen Einzel- oder Gruppenarbeit mit anschließendem gegenseitigen Vorstellen und optional einer Diskussion der eingebrachten Punkte.

Die zugrundeliegende Idee für den Einsatz solcher Aktivitäten während einer Retrospektive liegt darin, eine vorhandene Teamdynamik aufzubrechen und sowohl eine gleichberechtigte Teilnahme zu fördern, als auch den Fokus der Gespräche zu lenken, sodass ein Abdriften zumindest gehemmt wird. Zusätzlich geben Aktivitäten einen guten Gesamtüberblick und ermöglichen einen Perspektivenwechsel. Zu guter Letzt begünstigen sie das Entwickeln neuer Ideen, da die Personen außerhalb ihrer alltäglichen Routinen gebracht werden. (vgl. (Derby, Larsen, and Schwaber 2006, S. 21-22)).

Die Gestaltung und die Moderation des Meetings liegt in den meisten Fällen beim Agile Coach, welcher das Team der die Organisation betreut und begleitet. Die moderierende Person ist neutral und sollte sich nicht an der Ideenfindung zum Erzielen von Verbesserungen beteiligen. Es kann dennoch nützlich sein, den “Elefanten im Raum” vorsichtig anzusprechen, wenn “[...] sich das Team in der Retrospektive um ein Thema drückt [...]”(Davies and Sedley 2009, S. 270)

Was genau geschieht in jeder Phase?

Set the stage (Intro)

In der ersten Phase geht es um das Ankommen und gemeinsame Einsteigen in den Arbeitsmodus. Hier werden grundlegende Vereinbarungen zu Vertraulichkeit und einem respektvollen Miteinander getroffen, damit ein offenes Gespräch erst möglich wird. Sofern bereits eine Retrospektive durchgeführt wurde, können die vergangenen Ziele durchgegangen und überprüft werden (vgl. (Derby, Larsen, and Schwaber 2006, S. 23)).

Gather data (Daten Sammeln)

Da eine relativ große Zeitspanne überblickt werden muss, geht es in dieser Phase darum, Daten aus der betrachteten zurückliegenden Entwicklungsiteration zu sammeln und gegebenenfalls Verbindungen zwischen Ereignissen zu erkennen (vgl. (Derby, Larsen, and Schwaber 2006, S. 23)).

Generate insights (Einsichten erzeugen)

Nachdem in der vorhergehenden Phase Daten gesammelt wurden, geht es jetzt um die Auswertung selbiger. Dazu wird geschaut, ob bestimmte Muster erkennbar sind oder ob spezielle Geschehnisse auf die behandelten Probleme einzahlen. Im nächsten Schritt wird gemeinsam nach der Ursachen, möglichen Faktoren und Ereignissen gesucht, welche für ein Problem verantwortlich sein könnten (vgl. (Derby, Larsen, and Schwaber 2006, S. 23)).

Decide what to do (Entscheiden, was zu tun ist)

In der vorletzten Phase werden gemeinsam Ideen entwickelt, wie dem zuvor analysierten Problem und seinen Ursachen begegnet werden kann. Es werden recht konkrete Vorschläge als Experimente definiert, die in der folgenden Iteration dann ausprobiert werden können. Sie bilden damit eine selbst geschaffene Handlungsempfehlung mit dem Ziel, eine Verbesserung zu erzielen (vgl. (Derby, Larsen, and Schwaber 2006, S. 24)).

Close the retrospective (Abschluss)

Den Abschluss bilden Aktivitäten zur Verbesserung der Retrospektive selbst. In diesem letzten Schritt wird überprüft, wie effektiv und effizient die Retrospektive, die Mitarbeit aller war und ob sich die investierte Zeit tatsächlich gelohnt hat. Natürlich geht es hierbei auch um ein Anerkennen der Teamleistung. Die moderierende Person kann hier nützliches Feedback einsammeln.