Was vorher fertig sein muss
Eine klar abgegrenzte Aktion (Release, Kampagne, Incident, Mission) ist abgeschlossen oder unmittelbar nach einer Phase reviewbar.
Psychologische Sicherheit ist etabliert oder wird zu Beginn der AAR ausdruecklich eingefordert.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit vier Quadranten (Plan, Was passierte, Warum Abweichung, Lessons); Timeline der Aktion; Daten und Artefakte (Logs, Reports, Output).
Ein Facilitator mit AAR-Erfahrung; alle Beteiligten der Aktion ohne Rangordnung; ein Scribe; optional ein neutraler Beobachter aus anderem Team.
Urspruengliches Ziel und Plan; tatsaechliche Ereignisse mit Zeitstempeln; Kennzahlen vor und nach der Aktion; bekannte Beschwerden oder Auffaelligkeiten; relevante Entscheidungspunkte.
45-90 min, je nach Komplexitaet
Quadranten sichtbar machen. Regel ansagen: Rang gilt nicht in der AAR, jeder spricht, Fokus auf System statt Personen. Timeline der Aktion an einer Seite des Boards aufbereiten.
Die eine Frage, die diese Methode beantwortet
Was war beabsichtigt, was ist tatsaechlich passiert, warum gibt es eine Differenz, und was lernen wir fuer das naechste Mal?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Was sollte passieren | 10-15 min | Ziel und Plan der Aktion rekonstruieren: Was war das Outcome-Ziel, welche Schritte waren geplant, welche Annahmen lagen zugrunde. | Wenn das urspruengliche Ziel im Raum unklar ist, ist das schon das erste Lessons Learned. Schriftliche Ziele vor Aktionen einfordern. |
2Phase 2: Was ist tatsaechlich passiert | 15-20 min | Faktische Timeline entlang der Aktion. Belegt mit Daten, Logs, Beobachtungen. Keine Interpretation, nur Beobachtungen. | Wenn die Gruppe sofort in „weil X“ verfaellt, zurueck auf Fakten. Erst Phase 3 ist Interpretation. |
3Phase 3: Warum gibt es Abweichungen | 15-25 min | Pro Abweichung Plan vs. Realitaet die Ursachen sammeln. 5 Whys oder Fishbone bei wichtigen Abweichungen. Beitragende Faktoren von Hauptursachen trennen. | Nicht nur negative Abweichungen analysieren. Wenn etwas besser lief als geplant, ist das auch Lerngegenstand. Glueck und Koennen trennen. |
4Phase 4: Lessons und Massnahmen | 10-15 min | Pro Hauptursache eine Lesson formulieren (Was haben wir gelernt) plus eine konkrete Massnahme (Was tun wir kuenftig). Owner und Frist pro Massnahme. Maximal drei Massnahmen. | Lessons ohne Massnahme verstauben in einer Wiki-Seite. Massnahme muss in den naechsten 2-4 Wochen pruefbar sein. |
Was am Ende rauskommt
Strukturiertes Markdown- oder Wiki-Dokument mit Aktion-Header, Plan, Faktischer Verlauf, Ursachenanalyse, Lessons Learned und Massnahmenliste mit Owner und Frist. Ergaenzt um Teilnehmerliste und Verweis auf Daten/Artefakte.
Pro Aktion eindeutige ID und Datum. Lessons Learned in zentraler Knowledge Base mit Tags taggen, sodass Folgeaktionen sie finden. Massnahmen-Status ueber Zeit nachhalten, nicht nur am AAR-Tag.
Kompakte Arbeitsvorlage für After-Action Review mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# After-Action Review Arbeitsvorlage
## Ziel
Kurzer Review dazu, was beabsichtigt war, was passiert ist und warum.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Lessons Learned:
- Action Items:
- Event Summary:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## After-Action Review - Frontend-Deployment v4.12, 12.05.2026
**Beteiligte**: 4 Engineers, 1 Release Manager, 1 SRE.
**Plan**: Frontend-Release v4.12 am 12.05. um 18:00 mit Blue-Green-Deployment, Rollout in 30 min, Verifikation in 60 min, gesamt 90 min.
**Faktischer Verlauf**
- 18:03 Deployment gestartet.
- 18:14 Green-Pool aktiv, Traffic-Switch begonnen.
- 18:22 Spike 5xx-Errors auf 4.8% (Schwelle 1.5%), automatischer Rollback ausgeloest.
- 18:31 Rollback abgeschlossen, Errors normalisiert.
- 19:45 Ursache identifiziert (Cache-Header-Wechsel), Fix vorbereitet.
- 21:20 Redeploy erfolgreich.
**Abweichungen und Ursachen**
- Geplant 90 min, real 3 h 20 min. Ursache: Cache-Header-Aenderung war nicht im Staging gespiegelt, weil Staging-CDN andere Konfiguration hatte.
- Automatischer Rollback funktionierte (positiv, ueber Plan).
**Lessons**
- Staging-CDN muss Produktions-Konfig 1:1 spiegeln. Bisher Abweichung toleriert.
- Cache-Header-Aenderungen brauchen explizite Pre-Deploy-Checkliste.
**Massnahmen**
- AAR-001: Staging-CDN-Config als Code an Production-Config koppeln. Owner: @marcus, bis 22.05.
- AAR-002: Pre-Deploy-Checkliste um Cache-Header-Item erweitern. Owner: @anna, bis 19.05.
- AAR-003: Smoke-Test fuer Cache-Header-Konsistenz in CI. Owner: @lisa, bis 30.05.Symptome erkennen, gegensteuern
Niemand kann den urspruenglichen Plan klar nennen, jeder erinnert sich anders.
Erstes Lessons Learned: schriftliche Ziele und Plaene vor Aktion. Aktuelle AAR mit best verfuegbarem Konsens fuehren, naechste AAR hat Plan-Dokument.
Phase 2 wird zur Ursachendiskussion, Phase 3 dann oberflaechlich.
Facilitator trennt strikt. Bei „weil X“ Aussagen sofort: „erst die Beobachtung, das warum kommt gleich.“ Trennung erzeugt klarere Ursachenkette.
AAR liest sich als Fehlerprotokoll, positive Abweichungen werden nicht analysiert.
Explizit nach positiven Abweichungen fragen. Was lief besser als geplant und warum. Verstaerkende Massnahmen genauso wichtig wie korrigierende.
Drei Wiki-Seiten mit Lessons existieren, nichts hat sich geaendert.
Pro Lesson eine Massnahme mit Owner und Frist. Wenn keine Massnahme moeglich, Lesson loeschen oder als Information taggen, nicht als Lesson.
Aussagen drehen sich um „wer hat verbockt“, Sicherheit kippt.
Facilitator unterbricht, formuliert in Systemaussage um. Wenn Person trotzdem im Fokus bleibt, AAR pausieren. Erst Sicherheit, dann Analyse.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.