Retrospektiven, die zu Verhaltensänderungen führen

Ein Produktteam führte im Laufe anderthalb Jahre 18 aufeinanderfolgende Retrospektiven durch. Jede produzierte ein Dokument: lief gut, lief nicht gut, Action Items. Jedes Dokument lebte in Notion. Keines wurde je wieder geöffnet.

Beim 19. Versuch nahm die Team-Leiterin eine Änderung vor. Am Ende der Retro, anstatt die Sitzung nach der Einigung auf Action Items zu schließen, bat sie jede Person mit einem Action Item, genau zu sagen, was sie tun würde und wann. Nicht "unseren Schätzprozess verbessern." Sie wollte Spezifika: "Ich führe am Mittwoch in der Planungssitzung eine Kalibrierungsübung mit dem besprochenen Ansatz durch." Sie setzte für jedes Element ein Zwei-Wochen-Check-in vor der nächsten Retro.

Drei Punkte wurden erledigt. Alle drei. In zwei Wochen. Das Team hatte in anderthalb Jahren kein einziges Retro-Action-Item erfolgreich abgeschlossen.

Das Format war nicht das Problem. Das Follow-through-System war es.

Warum die meisten Retrospektiven nichts ändern

Das Fehlermuster ist vorhersehbar. Ein Team verbringt 60 Minuten damit, Beobachtungen und Action Items zu generieren, dann schließt man das Meeting. Jemand fügt die Action Items in Slack ein. Niemand weist Eigentümer zu. Niemand setzt Fristen. Die Forschung der Harvard Business Review zum Team-Lernen und kontinuierlicher Verbesserung stellte fest, dass die Lücke zwischen der Identifizierung von Problemen und der tatsächlichen Verhaltensänderung fast immer ein Rechenschaftsproblem ist, kein Erkenntnisproblem. Drei Wochen später, bei der nächsten Retro, sagt jemand: "Ich glaube, wir haben letztes Mal etwas über die Verbesserung unseres Deployment-Prozesses gesagt?" Niemand findet die Notizen. Alles beginnt von vorne.

Es gibt zwei strukturelle Probleme. Erstens sind die meisten Retro-Action-Items vage: "Kommunikation verbessern" oder "das Schätzproblem beheben." Vage Punkte können nicht abgeschlossen werden, weil sie nicht spezifizieren, wie ein Abschluss aussieht. Zweitens gibt es keinen Follow-through-Mechanismus zwischen Retros. Ohne dass jemand den Fortschritt explizit vor der nächsten Sitzung prüft, zerfallen Action Items auf null, unabhängig davon, wie energiegeladen das Team am Ende des Meetings war.

Beide Probleme sind lösbar, und keines erfordert eine neue Methodik.

Schritt 1: Vorbereitung – die async-Reflexionsfrage

Die Qualität einer Retrospektive wird größtenteils vor ihrem Beginn bestimmt. Teams, die kalt in eine Retro gehen, ohne Vorbereitung und ohne spezifische Beobachtungen, verbringen die ersten 20 Minuten damit, vage Gefühle zu generieren, und die letzten 10 Minuten damit, hastig Action Items zu produzieren.

Eine async-Frage 24 Stunden vor der Retro senden. Drei Fragen:

  1. Was ist eine spezifische Sache, die in diesem Sprint/Zyklus gut lief? Das Ding benennen. Nicht "Kommunikation war besser", sondern "das Design-Review am Dienstag hat sich an die Zeit gehalten und eine klare Entscheidung produziert."
  2. Was hat nicht funktioniert? Spezifisch sein: "Das Deployment am Donnerstag dauerte 3 Stunden, weil wir keinen Rollback-Plan bereit hatten", nicht "Deployments sind langsam."
  3. Was soll bis zum Ende unseres nächsten Sprints/Zyklus anders sein?

Die Spezifitätsaufforderung ist entscheidend. "Spezifisch sein: einen bestimmten Moment, ein Meeting, ein Artefakt oder eine Interaktion benennen" produziert konsistent besseren Retro-Input als offene Reflexion. Wenn Menschen konkret denken, sind die resultierenden Beobachtungen umsetzbar. Wenn sie in Verallgemeinerungen denken, sind die resultierenden Beobachtungen als Treiber von Veränderungen wertlos.

Ein einfaches Slack-Poll, ein geteiltes Notion-Dokument oder ein Tool wie Monday, ClickUp oder Rework verwenden, wenn das Team eines davon für Retrospektiven nutzt. Das Format ist egal. Die 24-stündige Vorlaufzeit und die Spezifitätsaufforderung zählen.

Schritt 2: Das 60-Minuten-Retro-Format

Abschnitt Zeit Zweck
Letzte Retro-Actions reviewen 10 Min Status-Check zu den Commitments
Lief gut 15 Min Was funktioniert, verstärken
Lief nicht gut 20 Min Root Causes von 2 Problemen identifizieren
Action Items 15 Min 2-3 spezifische, zugewiesene Commitments produzieren

Die 10-minütige Action-Review am Anfang ist nicht verhandelbar. Mit "Was haben wir uns letztes Mal vorgenommen, und was ist tatsächlich passiert?" zu beginnen, stellt klar, dass Retros Konsequenzen produzieren, nicht nur Listen. Wenn Punkte erledigt wurden, das sagen. Wenn nicht, das auch sagen, und 2 Minuten damit verbringen zu erklären warum, bevor man weitergeht.

Diesen Abschnitt nicht überspringen oder kürzen, wenn der Sprint schlecht war. Die Teams, die die Action-Review in schwierigen Phasen überspringen, sind die Teams, die 18 Retros ohne Veränderung durchführen.

Schritt 3: Der "lief gut"-Abschnitt, der nicht nur Lob ist

Die meisten "lief gut"-Abschnitte werden zu kurzen Runden gegenseitigen Lobens, und dann bewegt sich das Team mental zum "echten" Teil der Retro. Das ist eine verpasste Chance.

Das Ziel ist nicht, nette Dinge zu sagen. Es ist zu verstehen, was etwas gut gemacht hat, damit man es bewusst wiederholen kann. "Das Dienstags-Design-Review lief gut" ist Lob. "Das Dienstags-Design-Review lief gut, weil wir die Mockups 48 Stunden vorher verschickt haben und alle mit schriftlichem Feedback kamen, anstatt in Echtzeit zu reagieren" ist eine Praxis, die man kodifizieren kann.

Bei den top 2 Punkten aus der "lief gut"-Diskussion eine Ebene tiefer gehen: "Was genau hat das funktionieren lassen?" Wenn die Antwort ein spezifisches Verhalten oder ein Prozess ist, aufschreiben. Erwägen, es zur Team-Betriebsvereinbarung oder Team-Dokumentation hinzuzufügen, damit es über diese Retro hinaus bestehen bleibt.

Schritt 4: "Lief nicht gut" auf Root Causes reduzieren

Der "lief nicht gut"-Abschnitt ist, wo Retros Listen generieren, die nirgendwo hinführen. Acht Personen, die 12 Dinge auflisten, die schiefgelaufen sind, produzieren 12 Punkte mit je 2 Minuten Aufmerksamkeit. Nichts wird in der Tiefe behandelt, die erforderlich ist, um das Verhalten tatsächlich zu ändern.

Die Lösung ist, die top 2 Punkte aus der Liste zu identifizieren und bei jedem ein 5-Why-Drill durchzuführen. Nicht die gesamte Liste. Zwei.

Der 5-Why-Drill: weiter "Warum?" fragen, bis man die zugrunde liegende Ursache erreicht, nicht das Oberflächensymptom.

Beispiel:

  • "Unser Deployment dauerte 3 Stunden" → Warum?
  • "Wir hatten keinen Rollback-Plan" → Warum?
  • "Der Ingenieur, der normalerweise den Rollback-Plan schreibt, war nicht da" → Warum war es von einer Person abhängig?
  • "Wir haben keine Dokumentation für den Prozess" → Warum nicht?
  • "Niemand besitzt die Dokumentation für Deployment-Prozesse"

Root Cause: unzuständige Deployment-Dokumentation. Jetzt hat man etwas Umsetzbares.

Der 5-Why kann sich unangenehm anfühlen, wenn er Systeme oder Personen impliziert, über die das Team nicht sprechen möchte. Dieses Unbehagen ist in der Regel ein Zeichen dafür, dass man sich etwas Echtem nähert. Die Aufgabe des Moderators ist es, die Frage neutral zu halten: "Warum ist das passiert?" nicht "Wessen Schuld ist das?"

10 Minuten für jeden der zwei Punkte aufwenden. Bei einer langen Liste abstimmen, welche zwei man vertiefen möchte. Das verhindert, dass die Gruppe 20 Minuten damit verbringt zu diskutieren, welche Probleme priorisiert werden sollen.

Schritt 5: Der Action-Item-Filter

Jedes vorgeschlagene Action Item muss drei Fragen beantworten, bevor es zur Liste hinzugefügt wird:

  1. Wer ist der Eigentümer? Der Name einer Person. Nicht "das Team", nicht "wir". Eine Person, die dafür verantwortlich ist, dass es passiert.
  2. Was genau ändert sich? Ein spezifisches Verhalten, Artefakt oder Prozess, der nach diesem Punkt anders sein wird. Nicht "unseren Deployment-Prozess verbessern", sondern "bis Donnerstag eine Rollback-Checkliste zu unserer Deployment-Vorlage hinzufügen."
  3. Wie verifizieren wir es in 2 Wochen? Woran erkennen wir, dass es passiert ist? Eine Checkliste existiert, ein Meeting lief anders ab, eine Metrik hat sich verändert. Wenn es keine Möglichkeit gibt, es zu verifizieren, ist das Action Item nicht spezifisch genug.

Diesen Filter strikt anwenden. Wenn jemand ein Action Item vorschlägt, das eine der drei Fragen nicht besteht, es nicht hinzufügen. Die Folgefrage stellen, die es bestehbar machen würde. "Schätzung verbessern" → Wer ist der Eigentümer, konkret? "Marcus führt am Mittwoch in der Planungssitzung eine Kalibrierungsübung durch und berichtet, wie die Schätzungen mit der tatsächlichen Zeit übereinstimmen."

Das Ergebnis ist eine kürzere Liste spezifischer, zugewiesener Punkte. Eine Retro, die mit 2 Punkten endet, auf die alle drei Fragen beantwortet werden können, ist produktiver als eine, die mit 12 Punkten endet, auf die keine dieser Fragen beantwortet werden kann.

Action Items auf 3 begrenzen. Das ist eine harte Grenze, kein Richtwert. Wenn das Team 8 gute Action Items generiert, über die top 3 abstimmen. Die anderen 5 können dokumentiert werden, sollten aber keine Eigentümer-Commitments bekommen. Zu viele Action Items sind der zweitschnellste Weg, die Retro-Wirksamkeit zu zerstören.

Schritt 6: Start/Stop/Continue als Format-Alternative

Das Standard-"lief gut / lief nicht gut"-Format funktioniert gut für die meisten Teams. Aber manche Teams, insbesondere solche mit hoher zwischenmenschlicher Reibung oder Teams, die dasselbe Format seit 18+ Monaten verwenden und eine Änderung benötigen, profitieren von einer Start/Stop/Continue-Struktur:

  • Start: Dinge, mit denen das Team anfangen sollte, die es derzeit nicht tut
  • Stop: Dinge, mit denen das Team aufhören sollte. Nicht weil sie prinzipiell schlechte Ideen sind, sondern weil sie für dieses Team nicht funktionieren
  • Continue: Dinge, die funktionieren und explizit aufrechterhalten werden sollten, nicht nur stillschweigend angenommen

Der Vorteil von Start/Stop/Continue ist, dass es "was wir tun sollten" von "was schiefgelaufen ist" trennt, was das Gespräch weniger wie eine Post-mortem-Analyse und mehr wie eine Planungsdiskussion anfühlen lässt. Teams, die dazu neigen, in Schuldzuweisungszyklen stecken zu bleiben, reagieren oft besser auf dieses Format.

Derselbe Action-Item-Filter aus Schritt 5 gilt unabhängig vom Format. Eigentümer, spezifische Änderung, Verifizierungsmethode.

Schritt 7: Der 2-Wochen-Action-Check

Die Retro endet. Action Items stehen in Notion oder in Rework oder in einer Slack-Nachricht. Und dann passiert das Leben: ein Sprint beginnt, ein Release wird ausgeliefert, ein dringendes Kunden-Issue landet. Zwei Wochen gehen vorbei. Niemand schaut auf die Action Items, bis zur nächsten Retro, wo der Zyklus sich wiederholt.

Der 2-Wochen-Check ist kein Meeting. Es ist eine Slack-Nachricht an jeden Action-Item-Eigentümer, die 5 Arbeitstage nach der Retro gesendet wird.

Drei Fragen:

  1. Wo stehst du bei [spezifischem Action Item]?
  2. Blockiert dich irgendetwas?
  3. Wird es bis [Datum vor der nächsten Retro] fertig sein?

Das dauert 5 Minuten zum Versenden und kostet den Empfänger etwa 2 Minuten zum Antworten. Aber es verändert die sozialen Dynamiken rund um Retro-Commitments: Eigentümer wissen, dass jemand fragen wird, was ändert, wie ernst sie das Commitment zum Zeitpunkt der Übernahme nehmen.

Wenn ein Punkt blockiert ist, sofort entsperren. Nicht auf die nächste Retro warten. Ein 10-minütiges Gespräch jetzt ist besser als eine 45-minütige "Warum wurde das nicht erledigt"-Retrospektive später.

Häufige Fehler

Zu viele Action Items: Die Grenze ist 3. Wenn Teams 8 Action Items zustimmen, committen sie sich effektiv auf keines davon. Die Aufmerksamkeit verteilt sich zu weit und niemand spürt die Dringlichkeit individueller Eigenverantwortung. Wenn 8 gute Dinge aufgetaucht sind, die behoben werden müssen, gnadenlos priorisieren.

Keine Eigentümer: "Wir werden alle versuchen, besser zu kommunizieren" produziert keine Veränderung. "Marcus ist verantwortlich für die Verbesserung des Standup-Formats, beginnend am Montag" produziert eine andere Beziehung zum Commitment. Namen, keine Teams.

Retros, die zu Status-Updates werden: Wenn der "lief nicht gut"-Abschnitt zu einem Sprint-Status-Review wird ("wir haben X nicht geliefert, Y wurde verzögert"), ist man nicht mehr in einer Retro. Umleiten: "Das können wir im Sprint-Review besprechen. Was mich hier interessiert: Was an unserer Arbeitsweise hat das schwieriger gemacht als nötig?"

Die Retro überspringen, wenn der Sprint schlecht war: Das ist das häufigste und kontraproduktivste Muster. Wenn alles schiefgelaufen ist, will das Team keine weitere Stunde damit verbringen. Der Atlassian State of Teams Report stellte fest, dass hochperformante Teams Retrospektiven in schwierigen Phasen konsequenter durchführten, nicht weniger – die Disziplin der Reflexion unterscheidet Teams, die sich verbessern, von denen, die dieselben Fehlermuster wiederholen. Aber schlechte Sprints sind genau dann, wenn die nützlichsten Diagnoseinformationen verfügbar sind. Die Norm sollte sein: Je schlechter der Sprint, desto wichtiger die Retro. Nicht überspringen, aber auf 30 Minuten kürzen statt 60, mit einem engen Fokus auf eine Root Cause und ein Action Item.

Was als nächstes zu tun ist

Vor der nächsten Retro die async-Vorbereitungsfrage aus Schritt 1 senden. 24 Stunden vorher senden. Die drei spezifischen Fragen verwenden: eine Sache, die funktioniert hat, eine Sache, die nicht funktioniert hat, eine Sache, die man anders haben möchte.

Den Unterschied in der Spezifität der Antworten im Vergleich zu früheren Retros bemerken, bei denen man kalt gestartet ist. Wenn die Qualität des Inputs höher ist, hat man bereits die wirkungsvollste Änderung am Retro-Prozess identifiziert: eine einzige Slack-Nachricht am Tag davor.

Mehr erfahren