Kurzüberblick
Eine Retrospektive ohne Schuldzuweisung geht davon aus, dass Menschen mit den Informationen, die sie hatten, vernünftige Entscheidungen getroffen haben. Das Meeting sucht die Bedingungen, die den Fehler wahrscheinlich gemacht haben: fehlende Alarme, ein verwirrendes Runbook, ein Deploy-Fenster, ein Review, das das Risiko nicht sehen konnte. Ihr benennt trotzdem, was passiert ist. Ihr benennt keinen Schuldigen als die Lösung.
Diese Definition umfasst zwei Meetings, die Menschen vermischen. Eine Sprint-Retro kann ohne Schuldzuweisung davon handeln, wie das Team gearbeitet hat. Eine Incident-Retro ist ohne Schuldzuweisung auf ein Versagen bezogen, und sie braucht eine Zeitlinie.
Was „ohne Schuldzuweisung“ bedeutet und was nicht
Es bedeutet nicht, dass niemand verantwortlich ist. Jemand verantwortet weiterhin die nächste Änderung am Alarm, am Runbook oder am Rollout. Es bedeutet, dass die Aktion eine Änderung am System ist. „Jordan sollte vorsichtiger sein“ ist Schuldzuweisung. „Produktions-Deploys brauchen freitags nach 16:00 eine zweite Person, verantwortet von der Bereitschaftsleitung, geprüft in zwei Wochen“ ist eine Aktion ohne Schuldzuweisung.
Es bedeutet auch kein weiches Meeting ohne Fakten. Ohne Zeitlinie wird eine Retro ohne Schuldzuweisung zu einem Gefühlszirkel, und derselbe Ausfall kommt zurück.
Norm Kerths Prime Directive ist der übliche Eröffnungssatz: Angesichts der Informationen, die sie hatten, haben die Menschen ihr Bestes getan. Sagt ihn am Anfang, wenn der Raum angespannt ist. Geht dann zur Zeitlinie. Der Satz ist nicht das ganze Meeting.
Ohne Schuldzuweisung in einer normalen Sprint-Retro
Ihr braucht keinen Ausfall. Nutzt Sprache ohne Schuldzuweisung, wenn Karten anfangen, Personen zu benennen:
- Ersetzt „Alex hat den Build kaputt gemacht“ durch „der Build blieb einen Tag rot, weil der fehlschlagende Check im Pull Request nicht Pflicht war“.
- Ersetzt „das Produkt ändert ständig den Scope“ durch „drei Stories haben die Akzeptanzkriterien geändert, nachdem die Entwicklung begonnen hatte“.
Dann stimmt ab und wählt eine Änderung am System. Der Rest der Agenda ist die normale Sprint-Retrospektive: stille Karten, eine Abstimmung, ein bis drei Aktionen.
So führt ihr eine Incident-Retrospektive ohne Schuldzuweisung durch
Führt sie innerhalb weniger Tage nach dem Incident durch, nicht in der nächsten Sprint-Retro. Ladet die Menschen ein, die an der Reaktion beteiligt waren, plus eine moderierende Person, die Schuldzuweisung stoppen kann. Haltet sie für einen Incident bei 45–60 Minuten.
1. Die Zeitlinie vor dem Meeting schreiben (15 Minuten, asynchron)
Eine geteilte Liste, das Älteste zuerst:
- wann das erste Signal ausgelöst wurde oder wann ein Kunde geschrieben hat
- wann eine Person es gesehen hat
- was nach ihrer Einschätzung gerade passierte
- was sie geändert hat
- wann die Auswirkung aufgehört hat
Bittet jede Person, die Schritte zu ergänzen, die sie unternommen hat. Macht das schriftlich, damit das Meeting kein Erinnerungswettbewerb wird. Anonyme Karten helfen bei der Zeile „was ich geglaubt habe“, wenn Menschen mit einer Strafe rechnen.
2. Die Regel öffnen (2 Minuten)
Sagt: Wir werden keine Person als Ursache festlegen. Wir gehen mit Änderungen an Erkennung, Entscheidung oder Wiederherstellung. Wenn ein Name fällt, schreibt stattdessen die Bedingung um diese Person herum.
3. Die Zeitlinie durchgehen (15 Minuten)
Lest sie der Reihe nach. Fragt nur: Was wussten wir in dieser Minute, und was haben die Werkzeuge gezeigt? Korrigiert die Zeiten. Springt noch nicht zu „was wir hätten tun sollen“.
4. Die beitragenden Bedingungen finden (15 Minuten)
Gruppiert die Notizen in drei Spalten:
- Erkennung: Alarm fehlt, Alarm ist verrauscht, Dashboard, das niemand öffnet
- Entscheidung: Runbook falsch, unklare Verantwortung, zwei Personen nehmen entgegengesetzte Änderungen vor
- Wiederherstellung: Rollback langsam, Flag bleibt hängen, Kundennachricht zu spät
Diese Spalten halten das Gespräch beim System. Eine Karte, die nur einen Namen nennt, bekommt keine Stimme.
5. Ein bis drei Korrekturen wählen (10 Minuten)
Jede Korrektur benennt die Bedingung, die Änderung, eine verantwortliche Person und ein Datum. Bevorzugt eine Korrektur bei der Erkennung. Incidents, die niemanden per Paging erreichen, passieren wieder, so vorsichtig die Person in der Entwicklung auch war.
Schickt die Zeitlinie und die Aktionen an das Team. Legt das Dokument nicht dort ab, wo nur die Moderation es findet. Prüft die Aktionen in der nächsten Sprint-Retro, in den ersten fünf Minuten.
Sprache, die ihr im Raum korrigieren könnt
| Schuldzuweisung | Ohne Schuldzuweisung |
|---|---|
| Wer hat das ausgeliefert? | Welcher Check ist vor dem Ausliefern nicht gelaufen? |
| Die hätten es wissen müssen | Was hat das Dashboard in dieser Minute gezeigt? |
| Menschliches Versagen | Welcher Schritt hatte keinen zweiten Blick, und warum war das normal? |
Häufige Fragen
Was ist eine Retrospektive ohne Schuldzuweisung?
Es ist eine Retrospektive, die das Versagen als Eigenschaft des Systems behandelt. Menschen beschreiben, was sie zu dem Zeitpunkt wussten. Die Aktionen ändern Alarme, Runbooks, Reviews oder Rollout-Regeln. Der Name einer Person ist nicht die Korrekturmaßnahme.
Wie führt man Incident-Retrospektiven ohne Schuldzuweisung durch?
Schreibt die Zeitlinie vor dem Meeting, verbietet „wer hat das verursacht“ als Ergebnis, sortiert die Notizen in Erkennung, Entscheidung und Wiederherstellung und geht mit ein bis drei Systemänderungen mit Verantwortlichen. Haltet sie von der Sprint-Retro getrennt.
Ist ein Postmortem ohne Schuldzuweisung dasselbe?
Ja, für diesen Zweck. Postmortem, Incident-Review und Incident-Retrospektive sind dasselbe Meeting, wenn sie eine Zeitlinie nutzen und Schuldzuweisung als Lösung ablehnen. Eine Sprint-Retrospektive ist ein anderes Meeting über den ganzen Sprint.
Ein kostenloses Board starten und setzt Erkennung, Entscheidung und Wiederherstellung auf die Spalten. Teilnehmende können über den Link ohne Konto beitreten.
