Strukturierte Nachbetrachtung eines abgeschlossenen Vorhabens: vier Leitfragen, ehrlich und ohne Schuldzuweisung, mit nachverfolgbaren Aktionspunkten.
Lege für jedes abgeschlossene Vorhaben oder jede getroffene Entscheidung einen eigenen Review an. Alles bleibt ausschließlich in diesem Browser (localStorage, Schlüssel after-action-review.v1) — nichts wird übertragen.
Änderungen werden automatisch gespeichert, sobald du ein Feld verlässt oder tippst.
↩️ Titel, „Was war geplant?“ und „Was ist passiert?“ wurden aus dem Entscheidungstagebuch übernommen.
Worum ging es? Ein bis zwei Sätze reichen als Bezugspunkt für den ganzen Review.
Beschreibe den Plan, das Ziel oder die erwartete Vorgehensweise so, wie er vorher vereinbart war — nicht im Licht des tatsächlichen Ausgangs umgeschrieben.
Beschreibe die Fakten, so nüchtern wie möglich — beobachtbar statt gedeutet, unabhängig davon, was geplant war.
Was hat gut funktioniert und sollte beim nächsten Mal genauso wieder gemacht werden?
Was sollte sich beim nächsten Mal konkret ändern?
Mach aus den Erkenntnissen etwas Verbindliches: Wer tut bis wann was?
Tipp: Mit 🤝 einen Aktionspunkt zusätzlich in die „Gemeinsame Aktionspunkte“ weiter unten übernehmen.
Erzeugt eine saubere Zusammenfassung dieses Reviews — zum Ausdrucken oder Einfügen in Protokoll, Wiki oder E-Mail.
Alle Reviews liegen nur in diesem Browser. Exportiere regelmäßig ein JSON-Backup oder übertrage deine Daten damit auf ein anderes Gerät.
Import ergänzt vorhandene Reviews; Reviews mit gleicher ID werden durch die importierte Fassung ersetzt. Die Datei muss ein Export dieses Werkzeugs sein.
Wird lokal auf diesem Gerät zwischen den Onthology-Werkzeugen geteilt.
Diese Werkbank folgt der militärischen After-Action-Review (AAR): ein Format, das gezielt auf System- und Prozessursachen zielt statt auf persönliche Schuld. Die vier Leitfragen oben folgen dieser Struktur; die Haltung dahinter stützt sich auf die Forschung zu psychologischer Sicherheit.
Die AAR wurde vom US-Heer als strukturiertes Nachbereitungsformat für Übungen und Einsätze entwickelt und in der Feldanweisung „A Leader's Guide to After Action Reviews“ (Training Circular TC 25-20, U.S. Department of the Army, 1993) kodifiziert. Sie entstand am National Training Center aus der Erfahrung, dass Einheiten aus Übungen erst dann wirklich lernen, wenn Plan und Wirklichkeit offen nebeneinandergestellt werden — ohne dass daraus eine Bewertung der beteiligten Personen wird.
Die AAR ist ausdrücklich keine Manöverkritik im Sinne einer Benotung („critique“), sondern eine professionelle, von allen Beteiligten mitgestaltete Diskussion. TC 25-20 nennt vier Kernfragen, denen diese Werkbank folgt:
Quelle: U.S. Department of the Army: A Leader's Guide to After-Action Reviews, Training Circular TC 25-20, Washington, D.C., 1993.
Damit eine AAR ehrliche Antworten liefert, müssen Beteiligte unbequeme Wahrheiten sagen dürfen, ohne Sanktionen zu fürchten. Amy Edmondson zeigte in ihrer vielzitierten Studie zu Teams in Krankenhäusern, dass Teams mit höherer psychologischer Sicherheit — der geteilten Überzeugung, Fehler, Fragen und Bedenken offen ansprechen zu können, ohne bloßgestellt zu werden — mehr Fehler melden und zugleich mehr daraus lernen (Edmondson, 1999).
John Allspaw übertrug diese Haltung in die Praxis von Störfall-Nachbesprechungen der Software-Technik: „Blameless PostMortems“ unterscheiden bewusst zwischen Verantwortlichkeit auf Systemebene (welche Prozesse, Annahmen oder Schnittstellen haben den Fehler ermöglicht?) und der Suche nach einer schuldigen Person. Wer fragt, warum eine Handlung im jeweiligen Moment nachvollziehbar erschien, erhält belastbarere Ursachen als bei einer Schuldsuche (Allspaw, 2012).
Praktisch heißt das für die Ursachen-Frage in dieser Werkbank: Formuliere Ursachen so, dass sie auch bei Personalwechsel im Team noch etwas erklären — „die Übergabe-Checkliste deckte diesen Fall nicht ab“ statt „X hat nicht aufgepasst“.
Quellen: Edmondson, Amy C. (1999): Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383. — Allspaw, John (2012): Blameless PostMortems and a Just Culture. Code as Craft, Etsy-Engineering-Blog.
Alle drei Formate strukturieren das Nachdenken über Arbeit im Team — aber zu unterschiedlichen Zeitpunkten und mit unterschiedlichem Fokus. Diese Werkbank ist bewusst schmal geschnitten: keine Retro-Formate, kein Blick in eine noch nicht getroffene Entscheidung.
| After-Action-Review | Team-Retrospektive | Pre-Mortem | |
|---|---|---|---|
| Zeitpunkt | Nach Abschluss eines konkreten Vorhabens oder einer Entscheidung | Wiederkehrend, meist am Ende eines Arbeitszyklus (Sprint, Quartal) | Vor einer Entscheidung, bevor sie umgesetzt wird |
| Fokus | Soll/Ist-Abweichung einer einzelnen, abgeschlossenen Sache | Zusammenarbeit und Arbeitsweise des Teams über die Zeit | Mögliche Ursachen eines noch nicht eingetretenen Scheiterns |
| Format | Vier feste Leitfragen, eine Sitzung | Vielfältige Formate (Mad-Sad-Glad, Start-Stop-Continue, …) | Hypothetischer Rückblick aus der Zukunft |
| In der Suite | Diese Werkbank | Retro-Generator | Entscheidungs-Werkstatt |
Die Formate schließen sich nicht aus: Ein Pre-Mortem vor dem Start kann später zur Blaupause für die Ursachen-Frage dieser AAR werden — welche der vorher befürchteten Gründe sind tatsächlich eingetreten, welche nicht?
Redlichkeitshinweis: Diese Werkbank ist ein Reflexions- und Protokollwerkzeug, keine wissenschaftliche Methode mit garantiertem Ergebnis. Sie strukturiert das Gespräch — die Qualität der Erkenntnisse hängt von der Offenheit der Beteiligten ab.