After Action Review (AAR)
Strukturierte Team-Reflexion nach Ereignissen, um Ursachen, Ergebnisse und Verbesserungen systematisch zu erfassen.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Schuldzuweisungen statt Lernen
- Unverbindliche Maßnahmen ohne Follow-up
- Wiederholung gleicher Fehler bei fehlender Umsetzung
- Kurz und fokussiert: Agenda und Zeitbox einhalten
- Moderation durch neutrale Person fördern Offenheit
- Ergebnisse sichtbar machen und in Tools nachverfolgen
I/O & Ressourcen
- Fakten, Logs und Metriken zum Ereignis
- Zieldefinitionen und erwartete Ergebnisse
- Teilnehmer mit direkter Beteiligung
- Priorisierte Maßnahmenliste mit Verantwortlichen
- Kurzbericht mit Erkenntnissen und Empfehlungen
- Übertragbares Lernmaterial für andere Teams
Beschreibung
Das After Action Review (AAR) ist eine strukturierte Technik zur kollaborativen Reflexion nach Projekten oder Ereignissen. Teams analysieren Ziele, Ergebnisse, Ursachen und Verbesserungsmöglichkeiten. Ziel ist kontinuierliche Verbesserung durch konkrete Maßnahmen, Verantwortlichkeiten und dokumentierte Erkenntnisse für Stakeholder bereitzustellen.
✔Vorteile
- Schnelle Identifikation von Ursachen und Verbesserungen
- Erhöhte Transparenz und Team-Lernen
- Dokumentation von Entscheidungen und Verantwortlichkeiten
✖Limitationen
- Ergebnis hängt stark von Moderation und Teamkultur ab
- Kann zeitaufwendig werden, wenn nicht fokussiert
- Nicht geeignet ohne verlässliche Faktenbasis und Daten
Trade-offs
Metriken
- Anzahl umgesetzter Maßnahmen
Misst wie viele abgeleitete Maßnahmen innerhalb einer Frist umgesetzt wurden.
- Wiederholungsrate gleicher Vorfälle
Gibt Aufschluss, ob AAR-Maßnahmen nachhaltig wirken.
- Zufriedenheit der Teilnehmer
Erfasst Wahrnehmung von Nutzen und Sicherheit während des AAR.
Beispiele & Implementierungen
Postmortem eines Datenbank-Ausfalls
Team analysiert Ablauf, identifiziert Konfigurationsfehler und plant Rollback- und Monitoring-Verbesserungen.
Sprint-Retrospektive zur Lieferqualität
Fokus auf Testabdeckung, CI-Pipeline und Deployment-Prozesse; konkrete Maßnahmen definiert.
Release-Retro mit Stakeholdern
Ergebnisse und Nutzerfeedback werden verglichen; Prioritäten für Nacharbeiten abgeleitet.
Implementierungsschritte
Vorbereiten: Fakten sammeln und Teilnehmer benennen
Durchführen: Timeline, Fakten, Ursachen, Maßnahmen diskutieren
Dokumentieren: Ergebnisse und Verantwortlichkeiten festhalten
Nachverfolgen: Umsetzung und Wirkung prüfen
⚠️ Technische Schulden & Engpässe
Tech Debt
- Nicht integrierte Dokumentation erschwert Transfer
- Manuelle Nachverfolgung von Aktionen ist fehleranfällig
- Fehlende Automatisierung von Metriken reduziert Evidenz
Bekannte Engpässe
Beispiele für Missbrauch
- AAR als Show-Event vor Stakeholdern ohne echte Reflexion
- Maßnahmen sammeln, aber nie nachverfolgen
- Kritik wird persönlich, Lernen wird verhindert
Typische Fallen
- Zu breite Agenda führt zu oberflächlichen Ergebnissen
- Fehlende Datenbasis verzerrt Ursachenanalyse
- Kein Ownership für Maßnahmen bedeutet keine Wirkung
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Zeitliche Begrenzung in Meetings
- • Vertraulichkeit sensibler Informationen
- • Unterschiedliche Erwartungshaltungen von Stakeholdern