Grondoorzaken

Hoe zou je de tijdlijn van gebeurtenissen beschrijven?

De deployment ging om 14:20 live en de eerste foutmeldingen kwamen ongeveer acht minuten later.
Klanten begonnen inlogfouten te melden voordat onze monitoring het oppikte.
We rolden om 15:05 terug, maar de cache had nog eens 20 minuten nodig om volledig leeg te raken.
Wat ging goed?

Wat werkte en hielp ons effectief te reageren?

Onze alerting ving de piek in fouten vrijwel onmiddellijk op.
Het team sprong binnen enkele minuten op de incident-call en bleef kalm.
Een duidelijke rollback-procedure hebben bespaarde ons veel tijd.
Wat ging mis?

Waar liepen dingen vast of schoten ze tekort?

We hadden geen geautomatiseerde test die dit configuratiepad afdekte.
Monitoring dekte de afhankelijkheid die daadwerkelijk faalde niet af.
Het escalatiepad was onduidelijk, dus de juiste mensen werden te laat opgepiept.
Actiepunten

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

Voeg geautomatiseerde tests toe die de configuratiewijziging dekken die kapot ging.
Werk de runbook bij en verifieer de rollback-stappen volgende week.
Voer een deployment-bevriezing op vrijdag in voor risicovolle wijzigingen.

Wat is de Post-Mortem Retrospective

Een post-mortem retrospective geeft teams een gestructureerde, blaamvrije manier om een incident, project of release te onderzoeken nadat het is afgerond, en om precies vast te leggen wat er gebeurde, waarom het gebeurde en wat er moet veranderen. In plaats van met de vinger te wijzen, ligt de focus op het begrijpen van de tijdlijn van gebeurtenissen, het blootleggen van de bijdragende factoren en het vertalen van die inzichten naar concrete acties die voorkomen dat dezelfde problemen zich opnieuw voordoen. Het werkt even goed voor engineering-incidenten en storingen, gemiste deadlines, of de afronding van een groot initiatief. Het format leidt deelnemers door een gezamenlijke reconstructie van gebeurtenissen, een eerlijke blik op wat goed ging en wat misging, een verkenning van de grondoorzaken, en ten slotte een reeks afgesproken verbeteringen met duidelijk eigenaarschap. Door alles op één plek te documenteren, bouwt het team een institutioneel geheugen op waar het op kan terugvallen en van kan leren in de loop van de tijd. Het uitvoeren van de sessie in TeamRetro houdt iedereen in realtime op één lijn, maakt het eenvoudig om gerelateerde observaties te groeperen, de meest impactvolle problemen te prioriteren en vervolgacties toe te wijzen voordat de vergadering eindigt. De echte waarde van een post-mortem ligt in de toewijding aan psychologische veiligheid en continue verbetering. Wanneer teams falen als data behandelen in plaats van als schuld, leggen ze systemische zwaktes bloot, versterken ze processen en reageren ze de volgende keer sneller. Gepopulariseerd door site reliability- en incident-managementpraktijken bij bedrijven zoals Google, is de blaamvrije post-mortem een essentieel ritueel geworden voor goed presterende teams die sterker willen worden bij elke gebeurtenis.

Post-Mortem retrospective format

Grondoorzaken

Hoe zou je de tijdlijn van gebeurtenissen beschrijven?

Dit onderwerp legt een gedeeld, feitelijk verslag van het incident of project vast voordat enige analyse begint. Moedig het team aan om de volgorde van gebeurtenissen objectief uiteen te zetten, met focus op wat er gebeurde en wanneer, in plaats van wie wat deed. Het eerst opbouwen van deze gemeenschappelijke tijdlijn voorkomt misverstanden en geeft iedereen hetzelfde startpunt voor het diepere gesprek.

Wat ging goed?

Wat werkte en hielp ons effectief te reageren?

Zelfs tijdens lastige incidenten zijn er meestal zaken die het vieren en versterken waard zijn. Gebruik dit onderwerp om het gedrag, de tools en de beslissingen te benadrukken die hielpen, zodat het team weet wat het moet blijven doen. Het vastleggen van de positieve punten balanceert ook het gesprek en houdt het moreel gezond.

Wat ging mis?

Waar liepen dingen vast of schoten ze tekort?

Dit onderwerp brengt de problemen, hiaten en wrijvingspunten naar boven die hebben bijgedragen aan het incident of het slechte resultaat. Houd de toon constructief en richt je op processen en systemen in plaats van op individuen. Stimuleer eerlijkheid door het team eraan te herinneren dat het doel leren is, geen schuld toewijzen.

Actiepunten

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

Zet de discussie om in specifieke, toegewezen en tijdgebonden verbeteringen. Zorg ervoor dat elke actie een duidelijke eigenaar heeft en realistisch genoeg is om daadwerkelijk te worden voltooid. Prioriteer de wijzigingen die de grootste impact hebben op het voorkomen van een herhaling.

Wanneer u deze retrospective gebruikt

  • 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 een grote release, om geleerde lessen vast te leggen terwijl de details nog vers zijn.
  • Wanneer een deadline werd gemist of een initiatief te weinig opleverde en het team een eerlijke review nodig heeft.
  • Telkens wanneer een terugkerend probleem blijft opduiken en je tot de echte grondoorzaak wilt komen.
  • Om een cultuur van blaamvrij leren en continue verbetering tussen teams op te bouwen.

Voorgestelde vragen voor ijsbrekers

  • Wat is het meest memorabele 'oeps'-moment dat je hebt gehad en dat in een geweldige les veranderde?
  • Als dit incident een filmtitel was, hoe zou je het noemen?

Ideeën en tips voor uw retrospective vergadering

  • Zet vanaf het allereerste begin een blaamvrije toon zodat mensen zich veilig voelen om te delen wat er werkelijk gebeurde.
  • Bouw een gedeelde, feitelijke tijdlijn op voordat je in de analyse duikt, om iedereen op één lijn te houden.
  • Gebruik de Vijf Waaroms om voorbij de symptomen te komen en echte grondoorzaken bloot te leggen.
  • Maak elk actiepunt specifiek, toegewezen en tijdgebonden zodat opvolging daadwerkelijk gebeurt.
  • Nodig de juiste mix van betrokken mensen uit, maar houd de groep klein genoeg om gefocust te blijven.
  • Documenteer de uitkomst en bekijk eerdere actiepunten opnieuw in toekomstige sessies om te bevestigen dat oplossingen stand hielden.

Veelgestelde vragen

Wat is een blaamvrije post-mortem?
Een blaamvrije post-mortem richt zich op het begrijpen van de systemen, processen en omstandigheden die tot een incident leidden, in plaats van schuld toe te wijzen aan individuen. Deze aanpak moedigt eerlijkheid aan en legt de echte grondoorzaken bloot zodat het team ze kan oplossen.
Wanneer moet je een post-mortem retrospective uitvoeren?
Voer er een uit na een significant incident, storing, gemiste deadline of de afronding van een groot project. Het is het meest effectief wanneer het kort na de gebeurtenis wordt gehouden, terwijl details en context nog vers zijn.
Hoe lang duurt een post-mortem retrospective?
De meeste post-mortems duren 60 tot 90 minuten, afhankelijk van de complexiteit van het incident. Reserveer extra tijd voor een grondige root cause analyse en om duidelijke actiepunten af te spreken.
Hoe verschilt een post-mortem van een sprint retrospective?
Een sprint retrospective beoordeelt een vaste periode van werk en het teamproces, terwijl een post-mortem zich richt op een specifiek incident of gebeurtenis, met de nadruk op tijdlijnreconstructie en root cause analyse.
Wie moet er aanwezig zijn bij een post-mortem retrospective?
Betrek de mensen die direct betrokken waren bij het incident of project, samen met eventuele belanghebbenden die context kunnen bijdragen of vervolgacties kunnen bezitten. Houd de groep gefocust genoeg zodat iedereen betekenisvol kan deelnemen.
Hoe voorkom je dat een post-mortem in een schuldspel verandert?
Stel vooraf de verwachting dat de sessie blaamvrij is, richt het gesprek op processen en systemen in plaats van op mensen, en kader fouten als leermomenten. Een neutrale facilitator kan helpen de toon constructief te houden.

Nieuw bij retrospectives? Lees onze gids over het uitvoeren van een retrospective →