Wie die Retrospektive auch asynchron stattfinden kann

Stellen Sie sich folgende Situation vor: Ihr Team ist über mehrere Zeitzonen verteilt oder die Arbeitszeiten der Teammitglieder unterscheiden sich aufgrund von Teilzeit, Kinderbetreuung oder ähnlichem sehr stark voneinander. Sie als ScrumMaster möchten die kontinuierliche Verbesserung der Zusammenarbeit vorantreiben, indem Sie Retrospektiven durchführen. Jedoch finden Sie keinen Zeitpunkt, zu dem das gesamte Team gleichzeitig wach, geschweige denn am Arbeiten ist.

Dann eignet sich eine Taktik, die in diesem Team aufgrund der gegebenen Umstände sowieso schon vollkommen verinnerlicht wurde: asynchrone Kommunikation.

Die Idee

Bei einer asynchronen Retrospektive werden die einzelnen Schritte (Daten sammeln, Einblicke generieren und Entscheidungen treffen) über mehrere Tage verteilt, jedoch von den Teammitgliedern einzeln mit der gleichen Timebox pro Schritt durchgeführt. So kann jedes Teammitglied teilnehmen, auch wenn es keinen gemeinsamen Termin für die Retrospektive gibt. Dieses Vorgehen braucht allerdings etwas mehr Vorbereitung als eine synchrone Retro.

Vorbereitung

  1. Wählen Sie ein Kollaborations-Werkzeug nach Ihrem Belieben und den Möglichkeiten, die Ihnen Ihre Organisation zur Verfügung stellt. Setzen Sie beispielsweise ein geteiltes Notizbuch in OneNote auf, ein Whiteboard in Miro oder nutzen Sie das Chat-Tool Ihrer Organisation. Hauptsache ist, dass alle Teammitglieder einen Zugriff darauf haben und dem Team die Nutzung leichtfällt, sodass die Hemmschwelle für die Teilnahme möglichst niedrig ist.
  2. Bestimmen Sie das Retrospektiven-Format, wie zum Beispiel „I like …/I wish …“-, Seestern-Retrospektive oder andere. Ich empfehle, eine leicht verständliche oder dem Team schon vertraute Retrospektiven-Form zu nutzen, die wenig Erklärung Ihrerseits benötigt.
  3. Machen Sie die Regeln zu den einzelnen Schritten explizit, um ein einheitliches Verständnis zu schaffen, was nun das Ziel der jeweiligen Aufgabe und wie diese umzusetzen ist. Schließlich sind auch Sie nicht rund um die Uhr für Nachfragen verfügbar!
  4. Laden Sie Ihr Team ein, Feedback zum Vorgehen zu geben und aufkommende Bedenken zu äußern. Dies wird die Akzeptanz steigern.

Tipps aus der Praxis

  • Legen Sie sich Erinnerungen in Ihrem Kalender an, um Ihr Team nochmals auf die jeweiligen Phasen und Timeboxen hinzuweisen, sobald es in die Umsetzung geht.
  • Eine Erfahrung meinerseits: Wenn Sie den Teammitgliedern keine individuellen Terminblocker für die einzelnen Retro-Schritte zusenden, werden sie sich mehr auf ihre operativen Aufgaben fokussieren und sich weniger Zeit für die Retrospektive nehmen als vorgesehen. Ob das nun gut oder schlecht ist, hängt von der Situation ab und ich möchte mir nicht herausnehmen, das zu bewerten. Sollten Sie die Retrospektive mehr in den Vordergrund rücken wollen, dann empfehle ich Ihnen, den Teammitgliedern einen Terminblocker zuzusenden. Während dieses Termins sollen sie sich selbstständig mit der Retrospektive beschäftigen.

Ablauf

Tag 1: Informationen sammeln. Jedes Teammitglied füllt die Vorlage, die Sie gewählt haben, aus. Achten Sie darauf, dass die Teammitglieder einander möglichst nicht beeinflussen, indem sie beispielsweise keine Namen auf den Antworten vermerken. Ich lasse die Teammitglieder ihre Rückmeldungen noch während des Ausfüllens thematisch gruppieren. Sie wissen am besten, mit welchen Themen gewisse Probleme zusammenhängen. So können eventuelle Überschneidungen aufgezeigt werden und die Problemfelder werden klar. Dabei gebe ich weder bestimmte Themen noch bestimmte Arbeitsschritte vor, um die Rückmeldungen nicht in eine Richtung zu lenken: Das Team ordnet die Themen selbstorganisiert und kontinuierlich einander zu.

Tag 2: Wichtige Themen ermitteln. Dazu können Sie auf eine einfache Abstimmung, beispielsweise mittels Dot-Voting oder der Daumen-hoch-Funktion ihres Chattools, zurückgreifen. Die Teammitglieder verteilen eine fixe Anzahl an Stimmen pro Person (z. B. drei, wenn Sie maximal drei Themen angehen möchten) auf jene Themencluster, die ihnen am wichtigsten sind. Anhand der Rückmeldungen schlägt der ScrumMaster vor, für welche Themen an Tag 3 konkrete Maßnahmen gefunden werden sollen.

Wenn sich mehr als 40 % der Rückmeldungen auf ein Thema beziehen, ist eine Fokussierung darauf jedenfalls lohnenswert. Ich würde dem Team aber nicht von vorneherein Restriktionen auferlegen, damit es sich, statt um die Einhaltung von Regeln, um die eindeutige und möglichst umfängliche Formulierung der Themen kümmern kann.

Tag 3: Mögliche Schritte für die kontinuierliche Verbesserung. Jedes Teammitglied notiert seine Verbesserungsvorschläge zu den Themen mit der höchsten Bewertung vom Vortag. Meiner Erfahrung nach ist es gut, sich maximal drei Themen vorzunehmen, um den Fokus zu halten und die Maßnahmen wirklich durchzuführen.

Tag 4: Commitment einholen. Abschließend stimmt das Team wie an Tag 2 über die Themen nun darüber ab, zu welchen Maßnahmen es sich committen möchte. Das Endergebnis wird durch den ScrumMaster in das Team kommuniziert und so explizit gemacht. Mit diesem Schritt wird die asynrchone Retrospektive abgeschlossen und die Maßnahmen zur Umsetzung verbindlich festgelegt.

The Good…

Die asynchrone Retrospektive ermöglicht allen Teammitgliedern unabhängig von ihrer Arbeitslast, Terminen und Zeitzone teilzunehmen.

Auch, wenn eine gemeinsame Retrospektive mehr in die Tiefe geht und das Team zusammenschweißt, so birgt die asynchrone Retrospektive weitere Vorteile: Die Teammitglieder können sich selbstorganisiert die Zeit nehmen, um an der kontinuierlichen Verbesserung zu arbeiten und werden noch autonomer in ihrer Arbeitsweise.

Dadurch, dass die Teammitglieder mehr Zeit haben, um sich auf die einzelnen Schritte vorzubereiten, können kreativere, effizientere Ansätze entstehen. Zusätzlich haben sie bereits Zeit gehabt, die bestehenden Inhalte zu reflektieren, was die Maßnahmenfindung deutlich effizienter macht, auch wenn Studien zeigen, dass die Teamarbeit meist weitergedachte Lösungsansätze zutage bringt.

… the Bad…

Das asynchrone Vorgehen verlängert die eigentliche Durchlaufzeit der Retrospektive und macht es schwieriger, mögliche Punkte, die während des Sprints auffallen, in die Verbesserung und den darauffolgenden Sprint einzuarbeiten. Nehmen wir an, dass beim Review die Kund:innen nicht zufrieden waren, da die Akzeptanzkriterien falsch interpretiert wurden. Das wäre ein Punkt, den es zu verändern gilt. Das Team hat jedoch die dafür entscheidenden Phasen der Retrospektive für diesen Sprint bereits durchgeführt oder führt sie erst während des kommenden Sprints durch. Es entsteht ein zeitlicher Versatz zwischen den benötigten Verbesserungen und der tatsächlichen Umsetzung. Diesen Effekt versuche ich in der nachfolgenden Zeichnung darzustellen.

Zusätzlich geben Sie als ScrumMaster einen wichtigen Aspekt der Facilitation aus der Hand, denn: Sie sind nicht in der Lage, das Vorgehen und die Dynamik des Systems „Team“ persönlich zu erkennen. Das bedeutet, dass Sie nicht beobachten können, wie das Team zu Entscheidungen kommt oder wie die allgemeine Stimmungslage im Team ist. Es gehen somit entscheidende Aspekte für die Führung des Teams verloren.

Ein weiterer Nachteil ist, dass das Team während seiner laufenden Arbeit die Zeit finden muss, um den Retrospektive-Aufgaben nachzugehen. In meiner Erfahrung wird aber der Fokus auf die Lieferung von Produktinkrementen höher priorisiert als die Verbesserung der Zusammenarbeit. Zusätzlich fehlt der gegenseitige Austausch darüber, was den Teammitgliedern wichtig ist.

… and the Ugly

Der wohl schwerwiegendste Kritikpunkt, für mich zumindest, ist der folgende: Mögliche Probleme im System können unerkannt bleiben. Ein Beispiel ist, dass Meetings, die eine synchrone Retrospektive unmöglich machen, unerkannt bleiben. Dazu zählen beispielsweise ganztägige Workshops, die am selben Tag stattfinden, an dem ansonsten die Meetings zum Sprintwechsel stattfinden würden. Dadurch wird die Lieferfähigkeit beeinträchtigt, ohne dass dies Aufmerksamkeit erregt und die Konsequenzen früh spürbar werden.

Geschrieben von

Thilo Münz Thilo Münz Thilo Münz hat als Softwareentwickler Agilität hautnah erlebt und bringt dadurch als Berater ein besonderes Verständnis für die Herausforderungen in der Entwicklerrolle mit. Im täglichen Miteinander ist ihm eine Zusammenarbeit auf Augenhöhe besonders wichtig, weil jeder Standpunkt einen wertvollen Beitrag zur Entwicklung eines Teams leistet. Außerdem fasziniert ihn, wie Agilität die Kultur verändert: Dank der gelebten Prinzipien Transparenz, Fehlertoleranz und freiwilliges Teilen von Wissen hat Thilo eine Arbeitsweise gefunden, die mit seiner Persönlichkeit im Einklang steht. Dabei helfen ihm seine Wissbegier und sein Tatendrang, passende Lösungen für die individuellen Probleme der Versicherungsteams, mit denen er arbeitet, zu finden.

Teammitgliedsprofil

TEILE DIESEN BEITRAG

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email