Post-mortem retrospective

Leer van een incident zonder dat het een schuldvraag wordt.

Probeer deze retrospective live eens

Grondoorzaken

Hoe zou je de tijdlijn van de gebeurtenissen beschrijven?

De deployment ging om 14:20 live en ongeveer acht minuten later gingen de eerste foutmeldingen af.
Klanten meldden al inlogproblemen voordat onze monitoring het oppikte.
We hebben om 15:05 teruggedraaid, maar het duurde nog 20 minuten voordat de cache helemaal leeg was.
Wat ging goed?

Wat werkte en hielp ons om effectief te reageren?

Onze alerting ving de piek in fouten bijna meteen op.
Het team zat binnen een paar minuten in de incidentcall en bleef rustig.
Dankzij een duidelijke rollbackprocedure hebben we veel tijd bespaard.
Wat ging er mis?

Waar liep het vast of schoten we tekort?

We hadden geen geautomatiseerde test voor dit configuratiepad.
De monitoring dekte niet de dependency die daadwerkelijk faalde.
Het escalatiepad was onduidelijk, waardoor de juiste mensen te laat werden opgeroepen.
Actiepunten

Wat gaan we doen om dit in de toekomst te voorkomen?

Geautomatiseerde tests toevoegen voor de configuratiewijziging die misging.
Het runbook bijwerken en de rollbackstappen volgende week controleren.
Een deploymentstop op vrijdag invoeren voor risicovolle wijzigingen.

Wat is de post-mortem retrospective?

Een post-mortem retrospective is een evaluatie zonder schuldvraag van een incident, project of release, nadat het voorbij is. Je team zoekt uit wat er gebeurde, waarom het gebeurde en wat er moet veranderen, zodat hetzelfde probleem niet terugkomt. Het werkt voor productie-incidenten en storingen, maar net zo goed voor een gemiste deadline of de afronding van een groot initiatief. Het bord heeft vier kolommen. Grondoorzaken begint met de tijdlijn: het team zet op een rij wat er gebeurde en wanneer, voordat iemand gaat analyseren, zodat iedereen vanuit dezelfde feiten werkt. Wat ging goed? legt vast wat hielp, zoals alerts die snel afgingen of een rollback die werkte. Wat ging er mis? gaat over de hiaten en frictie die de situatie erger maakten. Actiepunten zet de discussie om in concrete verbeteringen met een eigenaar en een datum. In TeamRetro voegt iedereen tegelijk observaties toe, groepeert het team verwante punten, stemt het op de problemen met de meeste impact en worden vervolgacties toegewezen voordat de meeting afloopt. Blameless post-mortems zijn standaardpraktijk binnen site reliability engineering en incidentmanagement. Als het team een fout ziet als informatie over het systeem en niet als iemands schuld, vertellen mensen wat er echt gebeurde, en zo vind je de zwakke plekken in een proces. Bewaar het verslag, dan heb je iets om op terug te vallen de volgende keer dat er iets vergelijkbaars misgaat.

Post-mortem retrospective format

Grondoorzaken

Hoe zou je de tijdlijn van de gebeurtenissen beschrijven?

Begin met een gedeeld, feitelijk overzicht van het incident of project, nog vóór er geanalyseerd wordt. Vraag het team om de gebeurtenissen op volgorde te zetten en zich te beperken tot wat er gebeurde en wanneer, niet wie wat deed. Door eerst de tijdlijn af te stemmen voorkom je misverstanden en heeft iedereen hetzelfde vertrekpunt om de oorzaken te vinden.

Wat ging goed?

Wat werkte en hielp ons om effectief te reageren?

Zelfs bij een vervelend incident zijn er meestal dingen die het behouden waard zijn. Gebruik deze kolom om de acties, tools en beslissingen te benoemen die hielpen, zodat het team weet wat het moet blijven doen. Beginnen met wat werkte haalt bovendien wat spanning uit het gesprek dat volgt.

Wat ging er mis?

Waar liep het vast of schoten we tekort?

Deze kolom gaat over de problemen, hiaten en frictie die het incident of de uitkomst erger maakten. Houd de discussie bij processen en systemen, niet bij personen, en herinner het team eraan dat het doel leren is. Zoek naar hiaten waardoor meerdere dingen tegelijk misgingen, zoals ontbrekende monitoring of een onduidelijk escalatiepad.

Actiepunten

Wat gaan we doen om dit in de toekomst te voorkomen?

Zet de discussie om in concrete verbeteringen, elk met een eigenaar en een deadline. Houd ze realistisch genoeg om ze echt af te ronden. Zet de wijzigingen die een herhaling het meest waarschijnlijk voorkomen bovenaan de lijst.

Wanneer dient u deze retrospective te gebruiken?

  • Na een productie-incident of storing, om de oorzaak te begrijpen en te voorkomen dat het opnieuw gebeurt
  • Bij de afronding van een groot project of release, om lessen vast te leggen zolang de details nog vers zijn
  • Als een deadline is gemist of een initiatief tekortschoot en het team een eerlijke evaluatie nodig heeft
  • Als hetzelfde probleem steeds terugkomt en je de echte oorzaak wilt vinden
  • Als je wilt dat je teams fouten zien als iets om van te leren, niet als iemand om de schuld te geven

Voorstellen voor ijsbrekers

  • Wat is je meest memorabele 'oeps'-moment dat uiteindelijk een waardevolle les opleverde?
  • Als dit incident een film was, wat zou dan de titel zijn?

Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →

Ideeën en tips voor uw retrospectievevergadering

  • Zeg vooraf dat de sessie zonder schuldvraag is, zodat mensen zich veilig voelen om te vertellen wat er echt gebeurde
  • Stel eerst een gedeelde, feitelijke tijdlijn op voordat iemand begint met analyseren
  • Gebruik de 5 Waaroms om voorbij de symptomen bij de onderliggende oorzaak te komen
  • Geef elk actiepunt een eigenaar en een deadline, zodat het ook echt gebeurt
  • Nodig de betrokkenen uit, maar houd de groep klein genoeg om gefocust te blijven
  • Leg de uitkomst vast en controleer eerdere actiepunten in latere sessies om te zien of de oplossingen blijvend zijn

Veelgestelde vragen

Wat is een blameless post-mortem?
Het is een evaluatie die kijkt naar de systemen, processen en omstandigheden achter een incident in plaats van individuen de schuld te geven. Mensen zijn eerlijker als ze zich niet hoeven te verdedigen, waardoor het team de echte oorzaken vindt en die kan oplossen.
Wanneer houd je een post-mortem retrospective?
Houd er een na een belangrijk incident, een storing, een gemiste deadline of het einde van een groot project. Plan hem kort na de gebeurtenis, zolang de details nog vers zijn.
Hoe lang duurt een post-mortem retrospective?
De meeste duren 60–90 minuten, afhankelijk van hoe complex het incident was. Reken op extra tijd voor de oorzaakanalyse en om het eens te worden over duidelijke actiepunten.
Wat is het verschil tussen een post-mortem en een sprintretrospective?
Een sprintretrospective evalueert een vaste werkperiode en hoe het team heeft samengewerkt. Een post-mortem kijkt naar één incident of gebeurtenis, begint bij de tijdlijn en werkt terug naar de oorzaken.
Wie moet er bij een post-mortem retrospective zijn?
De mensen die direct bij het incident of project betrokken waren, plus iedereen die context kan toevoegen of eigenaar wordt van een vervolgactie. Houd de groep klein genoeg zodat iedereen aan het woord komt.
Hoe voorkom je dat een post-mortem een zoektocht naar een schuldige wordt?
Zeg aan het begin dat de sessie zonder schuldvraag is, houd het gesprek bij processen en systemen in plaats van bij mensen en behandel fouten als informatie. Een neutrale facilitator helpt om de toon constructief te houden.

Gerelateerde sjablonen

Moederdagreflectie

Bedank de moeders en verzorgers die je team hebben gevormd.

Spookhuis Halloween-retrospective

Bespreek je sprint via vijf griezelige kamers

Zoete Succeswinkel retrospective

Een snoepwinkel-retro voor successen, zure momenten en geheime recepten

Kwartaalretrospective

Stap terug uit de sprints en kijk naar het hele kwartaal.

Bent u klaar om deze retrospective te houden?Probeer deze retrospective live eens