Was ist die Post-Mortem-Retrospektive?
Eine Post-Mortem-Retrospektive ist eine Nachbetrachtung ohne Schuldzuweisung, die nach einem Vorfall, einem Projekt oder einem Release stattfindet. Ihr Team arbeitet heraus, was passiert ist, warum es passiert ist und was sich ändern sollte, damit dasselbe Problem nicht wieder auftritt. Das Format eignet sich für Produktionsvorfälle und Ausfälle, aber genauso für eine verpasste Deadline oder den Abschluss einer großen Initiative. Das Board hat vier Spalten. Grundursachen beginnt mit der Timeline: Das Team hält fest, was wann passiert ist, bevor irgendjemand analysiert. So arbeiten alle mit denselben Fakten. Was lief gut? sammelt, was geholfen hat, etwa Alerts, die schnell ausgelöst haben, oder ein Rollback, der funktioniert hat. Was lief schief? umfasst die Lücken und Reibungspunkte, die die Lage verschlimmert haben. Maßnahmen macht aus der Diskussion konkrete Verbesserungen mit verantwortlicher Person und Termin. In TeamRetro tragen alle ihre Beobachtungen gleichzeitig ein, gruppieren zusammengehörige Punkte, stimmen über die Themen mit der größten Wirkung ab und legen noch vor Ende des Meetings Folgemaßnahmen fest. Post-Mortems ohne Schuldzuweisung sind gängige Praxis im Site Reliability Engineering und im Incident Management. Wenn das Team einen Fehler als Information über das System betrachtet und nicht als Versagen einer Person, schildern die Leute, was wirklich passiert ist. Genau so findet man die Schwachstellen in einem Prozess. Halten Sie die Ergebnisse schriftlich fest, dann haben Sie eine Grundlage zum Nachschlagen, wenn das nächste Mal etwas Ähnliches kaputtgeht.
Post-Mortem-Retrospektive Format
Grundursachen
Wie würdest du den zeitlichen Ablauf beschreiben?
Beginnen Sie mit einer gemeinsamen, sachlichen Darstellung des Vorfalls oder Projekts, bevor irgendetwas analysiert wird. Bitten Sie das Team, die Ereignisse der Reihe nach aufzuschreiben und dabei bei dem zu bleiben, was wann passiert ist, nicht wer was getan hat. Wenn sich alle zuerst auf die Timeline einigen, vermeiden Sie Missverständnisse und schaffen einen gemeinsamen Ausgangspunkt für die Ursachensuche.
Was lief gut?
Was hat funktioniert und uns bei der Reaktion geholfen?
Selbst ein schlimmer Vorfall hat meist Dinge, die es wert sind, beibehalten zu werden. Nutzen Sie diese Spalte, um die Handlungen, Tools und Entscheidungen zu benennen, die geholfen haben, damit das Team weiß, was es weiter so machen sollte. Wer mit dem Positiven beginnt, nimmt außerdem etwas Spannung aus dem anschließenden Gespräch.
Was lief schief?
Wo ist etwas schiefgegangen oder hat nicht gereicht?
In dieser Spalte geht es um die Probleme, Lücken und Reibungspunkte, die den Vorfall oder das Ergebnis verschlimmert haben. Halten Sie die Diskussion bei Prozessen und Systemen, nicht bei einzelnen Personen, und erinnern Sie das Team daran, dass es ums Lernen geht. Achten Sie auf Lücken, durch die mehrere Dinge gleichzeitig schiefgehen konnten, zum Beispiel fehlendes Monitoring oder ein unklarer Eskalationsweg.
Maßnahmen
Was tun wir, um das künftig zu verhindern?
Machen Sie aus der Diskussion konkrete Verbesserungen, jeweils mit einer verantwortlichen Person und einem Fälligkeitsdatum. Halten Sie sie so realistisch, dass sie tatsächlich umgesetzt werden können. Stellen Sie die Änderungen an den Anfang der Liste, die eine Wiederholung am ehesten verhindern.
Wann sollte diese Retrospektive durchgeführt werden?
- Nach einem Produktionsvorfall oder Ausfall, um die Ursache zu verstehen und eine Wiederholung zu verhindern
- Zum Abschluss eines großen Projekts oder Releases, um Erkenntnisse festzuhalten, solange die Details noch frisch sind
- Wenn eine Deadline verpasst wurde oder eine Initiative hinter den Erwartungen zurückgeblieben ist und das Team eine ehrliche Bilanz braucht
- Wenn dasselbe Problem immer wieder auftritt und Sie die eigentliche Ursache finden wollen
- Wenn Ihre Teams Fehler als Lernchance sehen sollen und nicht als Anlass, Schuldige zu suchen
Vorschläge für Fragen zum Icebreaker
- Was war dein denkwürdigster „Hoppla“-Moment, aus dem eine wertvolle Lektion wurde?
- Wenn dieser Vorfall ein Film wäre, wie würde der Titel lauten?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Sagen Sie gleich zu Beginn, dass es keine Schuldzuweisungen gibt, damit sich alle sicher fühlen, offen zu schildern, was wirklich passiert ist
- Erstellen Sie eine gemeinsame, sachliche Timeline, bevor jemand mit der Analyse beginnt
- Nutzen Sie die 5-Why-Methode, um über die Symptome hinaus zur eigentlichen Ursache vorzudringen
- Geben Sie jeder Maßnahme eine verantwortliche Person und ein Fälligkeitsdatum, damit sie auch wirklich umgesetzt wird
- Laden Sie die Beteiligten ein, aber halten Sie die Gruppe klein genug, damit sie fokussiert bleibt
- Dokumentieren Sie das Ergebnis und prüfen Sie frühere Maßnahmen in späteren Sessions, um sicherzugehen, dass die Verbesserungen Bestand haben
Häufig gestellte Fragen
Was ist ein Post-Mortem ohne Schuldzuweisung?
Wann sollte man eine Post-Mortem-Retrospektive durchführen?
Wie lange dauert eine Post-Mortem-Retrospektive?
Worin unterscheidet sich ein Post-Mortem von einer Sprint-Retrospektive?
Wer sollte an einer Post-Mortem-Retrospektive teilnehmen?
Wie verhindert man, dass ein Post-Mortem zur Suche nach Schuldigen wird?
Verwandte Vorlagen
Dankt gemeinsam den Müttern und Bezugspersonen, die euer Team geprägt haben.
Retrospektive „Wanderung zum Wasserfall“
Auf den Anstieg zurückblicken, dann den nächsten Pfad planen.
Cyber-Security-Ops-Retrospektive
Vorfälle, Kontrollen und Lücken gemeinsam im Security-Team auswerten.
Sprint-Klinik-Retrospektive
Die Probleme eures Sprints diagnostizieren und die passenden Lösungen verordnen