Samenvatting
Hoe een blameless postmortem helpt bij cultuurverandering in SAFe-organisaties. Van fixed naar growth mindset, met praktische tips en inzichten.
Incidenten horen bij IT. Hoe goed je processen ook zijn ingericht, hoe volwassen je teams ook werken: ergens knapt er een keer iets. De manier waarop je als organisatie omgaat met dat moment — en vooral met de mensen die erbij betrokken zijn — zegt alles over je cultuur.
In veel organisaties wordt het afhandelen van incidenten gezien als een technische activiteit. Iets voor monitoring, voor DevOps-teams, of voor een after-action review aan het eind van een sprint. Maar wie alleen naar het incident kijkt, en niet naar de mindset erachter, mist de belangrijkste les.
In deze blog laat ik zien waarom ‘blameless postmortems’ niet alleen nuttig zijn na een incident, maar fundamenteel zijn voor de manier waarop je als organisatie kijkt naar groei. En waarom die groei niet begint bij tooling of processen, maar bij cultuur.
Wat bedoelen we met een ‘blameless postmortem’?
Een postmortem is een terugblik op een incident. Wat is er gebeurd? Waarom? Wat kunnen we ervan leren?
Dat doen veel organisaties al — of in ieder geval: ze zeggen dat ze het doen.
Een blameless postmortem gaat een stap verder. Daarin staat niet de schuldvraag centraal, maar het begrijpen van het systeem. Niet: “Wie heeft dit veroorzaakt?” maar: “Wat maakte dat deze fout kon ontstaan en kon doorwerken?”
Het idee is eenvoudig: als mensen bang zijn om afgerekend te worden, zullen ze fouten verzwijgen of verhullen. En als je dat doet, kun je nooit leren. Dan blijf je hetzelfde incident herhalen, met misschien net een ander ticketnummer.
Blameless betekent niet dat je fouten goedpraat. Het betekent dat je fouten ziet als signaal: iets in je proces, je afspraken, je tooling of je aannames klopte niet. Daar wil je naar kijken. Zonder vingerwijzen. Met een open houding.
De fixed mindset bij incidenten
In organisaties met een zogeheten fixed mindset zie je dat incidenten worden behandeld als uitzonderingen. Dingen die “niet hadden mogen gebeuren”, en dus zo snel mogelijk onder het tapijt moeten.
Kenmerken van een fixed mindset bij incidenten:
- Er wordt gezocht naar een schuldige
- Incidenten worden niet breed gedeeld
- Root cause analysis wordt overgeslagen
- Herstelacties zijn quick and dirty
- Mensen voelen zich niet veilig om fouten te melden
Het gevolg? Fouten worden duurder. Incidenten keren terug. Mensen worden defensief. En het vertrouwen in het systeem én in elkaar neemt af.
In deze cultuur is falen een zonde. Iets wat je moet vermijden, ontkennen of afschermen.
De kracht van een growth mindset
Daar tegenover staat de growth mindset: de overtuiging dat fouten een onderdeel zijn van leren. Hier is een fout niet het einde van iets, maar het begin van verbetering.
Kenmerken van een growth mindset:
- Incidenten worden gedeeld en besproken
- De analyse richt zich op systeem en context
- Er is ruimte voor reflectie, ook als dat tijd kost
- Leren is belangrijker dan snelheid
- Er is psychologische veiligheid om fouten toe te geven
“Een fout is geen falen, maar onderdeel van het vinden van de oplossing.”
Juist dát is de houding die je wil aanmoedigen. Niet alleen in DevOps-teams, maar in je hele organisatie.
Leiderschap is zichtbaar en dienend
Een veilige cultuur ontstaat niet vanzelf. Leiders spelen hierin een sleutelrol. Niet door controle of afrekening, maar door transparantie en voorbeeldgedrag.
Een leider met een growth mindset:
- Is open over eigen fouten
- Verduidelijkt het waarom achter besluiten
- Deelt informatie over zaken die hoger in de organisatie spelen
- Maakt de stap van “ik regel het” naar “ik ondersteun jullie om het zelf te doen”
Binnen SAFe (Scaled Agile Framework) wordt veel gesproken over decentraliseer besluitvorming. Dat werkt alleen als mensen ook echt snappen waaróm iets moet gebeuren. Transparantie is daarvoor cruciaal. Als leider geef je dus niet alleen richting, maar ook context. Zodat anderen met vertrouwen zelf keuzes kunnen maken.
Processen moeten ruimte geven voor leren
Een goede cultuur vraagt ook structuur. Je kunt als organisatie zeggen dat je fouten wil bespreken, maar als er nergens in je PI-planning of teamritme tijd voor is, blijft het bij intentie.
Wat helpt:
- Plan tijd in voor gezamenlijke postmortems
- Gebruik een vast format (zoals “incident, impact, oorzaak, lessen, opvolging”)
- Houd de drempel laag: ook kleine incidenten verdienen aandacht
- Zorg dat uitkomsten worden opgevolgd en niet verdwijnen in een backlog die nooit wordt opgepakt
- Laat ook andere teams meekijken om kennis te delen
In SAFe is de Inspect & Adapt-workshop hier bij uitstek geschikt voor. Maar het werkt alleen als je het serieus neemt. Zonder PowerPoints, zonder maskering. Gewoon open, eerlijk en met elkaar.
Incidenten als thermometer van je cultuur
Een incident laat niet alleen zien wat er technisch fout ging. Het laat vooral zien hoe je organisatie reageert als het spannend wordt.
- Wordt er defensief gereageerd?
- Wordt er iemand aangewezen als schuldige?
- Is er ruimte om de échte oorzaak te achterhalen?
- Wordt het incident besproken met anderen, of stilgehouden?
Hoe je omgaat met een incident, zegt alles over hoe je met elkaar werkt. Je ziet in één moment terug of de organisatie gericht is op beheersen of op verbeteren.
De rol van architectuur en structuur
Ook als architect kun je bijdragen aan een lerende cultuur. Niet alleen door systemen robuuster te maken, maar juist door transparantie te faciliteren. Bijvoorbeeld:
- Zorg dat logs en monitoring beschikbaar zijn voor teams
- Maak systeemgedrag uitlegbaar: waarom faalt iets, wat gebeurt er dan?
- Werk mee aan incidentmodellen die de context zichtbaar maken (zoals incident heatmaps of afhankelijkheidsdiagrammen)
Je rol is niet om fouten te voorkomen, maar om te zorgen dat je ervan kunt leren. Dat begint bij zichtbaarheid.
En nu?
Cultuurverandering is geen project. Er is geen template, geen KPI, geen implementatieplan. Het is een houding. Een reeks keuzes, iedere dag opnieuw.
De verantwoordelijkheid daarvoor ligt niet bij “de organisatie”, maar bij iedereen. Teamleden. Leidinggevenden. Architecten. RTE’s. Scrum Masters. Developers.
Voor iedereen geldt: lead by example.
Laat zien dat fouten bespreekbaar zijn. Dat leren belangrijker is dan gelijk krijgen. En dat een fout niet het einde is, maar het begin van iets beters.
Afsluitende gedachte
In een fixed mindset is een incident een probleem. In een growth mindset is het een kans.
De keuze is aan jou.