Async Retrospective
Eine Async Retrospective ist eine Retrospektive, die schriftlich über mehrere Tage oder Wochen läuft statt in einem Meeting: Die Teammitglieder tragen ihre Beobachtungen nach eigenem Zeitplan in ein gemeinsames Issue oder Dokument ein, und eine Moderation führt die schriftliche Diskussion bis zu konkreten Maßnahmen. Das am besten dokumentierte Beispiel ist GitLab, dessen Handbuch empfiehlt, Retrospektiven-Feedback asynchron in einem Issue zu sammeln und nur dann einen Live-Videocall zu ergänzen, wenn eine Iteration schwierig war. Das Format eignet sich für Teams, die über Zeitzonen verteilt sind, und hinterlässt ein schriftliches, verlinkbares Protokoll.
Moderationsablauf
- 1
Moderation: Eröffne zu Beginn der Iteration das Issue oder Dokument aus der Vorlage, ergänze Kontext und Links, setze eine Frist und kündige es im Chat an.
10 Min. - 2
Alle Teilnehmenden: Ergänzt während der Iteration Kommentare unter den Fragen, sobald etwas passiert. Das verteilt sich über Tage oder Wochen.
15 Min. - 3
Moderation: Lies alle Beiträge, stelle Verständnisfragen und gruppiere zusammengehörige Kommentare. Schicke denen eine Erinnerung, die noch nichts beigetragen haben.
15 Min. - 4
Alle: Antwortet in den Threads, um Muster und Ursachen herauszuarbeiten.
10 Min. - 5
Alle: Schlagt Maßnahmen vor und stimmt darüber ab. Die Moderation legt Verantwortliche und Termine fest.
10 Min. - 6
Optionaler Live-Videocall für alles, was ein Gespräch braucht, bei Bedarf zu zwei Zeiten angeboten.
20 Min. - 7
Moderation: Danke den Beitragenden, schreibe die Zusammenfassung und veröffentliche die Notizen.
10 Min.
Tipps
Eröffne das Issue zu Beginn der Iteration; bis sie vorbei ist, haben die Leute die Details vergessen.
Die Moderation muss schriftlich aktiv sein: Nachfragen stellen, zusammengehörige Kommentare verbinden und Personen markieren, die noch nichts beigetragen haben.
Wer moderiert und sich auch inhaltlich beteiligen will, sollte dazusagen, dass der Kommentar als Teilnehmer:in gemeint ist, oder die Moderation an jemanden aus dem Team abgeben.
Schriftliche Kritik liest sich härter als gesprochene – verlege einen Thread also in einen Call, sobald er angespannt wird.
Typische Stolperfallen
Das Issue erst eröffnen, wenn die Iteration vorbei ist. Kommentare kommen spät und fallen dünn aus, weil alle schon bei der nächsten Aufgabe sind
Keine aktive Moderation. Die Threads bleiben bei Fakten und Beschwerden stehen und erreichen nie Ursachen oder Entscheidungen
Eine hitzige Meinungsverschiedenheit im Schriftlichen belassen, wo sie eskaliert und dauerhaft dokumentiert bleibt. Verlege sie früh in einen Call
Maßnahmen ohne verantwortliche Person oder Termin. Jede schriftliche Retrospektive wiederholt dann die vorherige, und die Beteiligung sinkt
Schweigen für Zustimmung halten. Schriftlich lässt sich das Issue leicht ganz übergehen – fehlende Stimmen müssen also direkt angesprochen werden
Variationen
Teams ohne Issue-Tracker können ein gemeinsames Dokument oder ein digitales Whiteboard mit einem Abschnitt pro Frage nutzen. Eine hybride Version sammelt den Input asynchron und nutzt einen 30-minütigen Call nur dafür, Erkenntnisse zu gewinnen und Maßnahmen zu beschließen. GitLab beschreibt außerdem, den Live-Call nicht aufzuzeichnen und ihn ohne die direkten Vorgesetzten abzuhalten, wenn das den Leuten hilft, offen zu sprechen. Die Agenda aus Einstieg, Daten sammeln, Erkenntnisse gewinnen, Maßnahmen beschließen und Abschluss folgt dem Phasenmodell aus dem Buch 'Agile Retrospectives' von Esther Derby und Diana Larsen.
Einsatzbereiche
Wann einsetzen
Die Teammitglieder arbeiten in Zeitzonen, die sich kaum oder gar nicht überschneiden
Live-Retrospektiven werden von wenigen Stimmen dominiert, und andere beteiligen sich schriftlich leichter
Du willst ein Protokoll, in dem Kommentare direkt auf die Tickets und Änderungen verlinken, auf die sie sich beziehen
Das Team arbeitet ohnehin überwiegend schriftlich und ist es gewohnt, in Kommentar-Threads zu diskutieren
Die Iterationen sind so lang, dass frühe Ereignisse bis zu einem Abschlussmeeting vergessen sind
Wann nicht einsetzen
Die Iteration lief schlecht, oder es gibt einen Konflikt im Team. Halte eine Live-Retrospektive ab, denn Ton und Emotionen kommen in schriftlichen Threads schlecht rüber
Das Team ist neu, und das Vertrauen ist gering. Führe zuerst Live-Retrospektiven durch, zum Beispiel Mad Sad Glad, und wechsle später ins Schriftliche
Das Team sitzt am selben Ort und kann sich leicht treffen. Eine normale Sprint Retrospective geht schneller und schafft mehr Verbindung
Niemand hat Zeit, schriftlich zu moderieren. Ohne Moderation füllt sich das Issue mit Kommentaren, aber ohne Schlussfolgerungen
Teammitglieder schreiben nicht gern in der Arbeitssprache des Teams – das bringt sie stärker zum Schweigen, als ein Meeting es täte
Ähnliche Methoden
Häufig gestellte Fragen
Was ist eine Async Retrospective?▾
Eine Async Retrospective ist eine Retrospektive, die schriftlich über einen Zeitraum von Tagen oder Wochen stattfindet statt in einem einzelnen Meeting. Die Teammitglieder tragen in ein gemeinsames Issue oder Dokument ein, was gut lief, was schieflief und was sich verbessern ließe, wann immer es ihnen passt. Eine Moderation führt die Diskussion bis zu Maßnahmen und einer veröffentlichten Zusammenfassung.
Wie führt GitLab seine Retrospektiven asynchron durch?▾
Das GitLab-Handbuch empfiehlt, Feedback asynchron in einem Issue auf Basis einer Retrospektiven-Vorlage zu sammeln, damit alle in ihrer eigenen Zeit nachdenken und schreiben können. Ein Beitrag von Engineering Manager Sean McGivern aus dem Jahr 2019 beschreibt geplante Pipelines, die das Issue automatisch am Ersten jedes Monats anlegen und später die Liste der ausgelieferten und verschobenen Punkte ergänzen. Der Engineering Manager veröffentlicht anschließend die relevanten Notizen.
Braucht eine asynchrone Retrospektive trotzdem eine Moderation?▾
Ja. GitLab gibt vor, dass jede Retrospektive eine unparteiische Moderation hat, normalerweise die Führungskraft, die das Gespräch durch eine klare Agenda führt. Schriftlich heißt das: Nachfragen stellen, zusammengehörige Kommentare verknüpfen und Threads von Beobachtungen zu Entscheidungen bringen. Ohne diese Rolle liefert das Format eine Liste von Anmerkungen.
Wann sollten wir einen Live-Call ergänzen?▾
Ergänzt einen Call nach einer besonders harten Iteration oder wenn die Emotionen voraussichtlich hochkochen. GitLab schlägt vor, ihn für Teams, die über Regionen verteilt sind, zweimal anzusetzen, damit jede Gruppe eine zumutbare Uhrzeit bekommt. Ein kurzer Call lässt sich auch routinemäßig für den Entscheidungsschritt nutzen, während das Sammeln asynchron bleibt.
Wie viel Zeit kostet es jede einzelne Person?▾
Das Format läuft über die gesamte Iteration, aber die aktive Zeit pro Person ist gering, typischerweise insgesamt 15 bis 30 Minuten für Schreiben und Antworten. Die Moderation braucht mehr, etwa eine Stunde über den Zeitraum verteilt. Ein optionaler Live-Call kommt mit 30 bis 60 Minuten dazu.
Plane deinen nächsten Workshop mit KI
Workshop Weaver kombiniert Methoden wie Async Retrospective zu einer vollständigen, zeitlich geplanten Agenda. In Minuten.
Kostenlos testenMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from GitLab Handbook, 'Group Retrospectives'.