Blameless Post Mortem har blitt et ganske kjent begrep innenfor moderne produktutvikling. Samtidig vil jeg påstå at metoden sjeldent brukes til sitt fulle potensial.
Jeg føler at den største årsaken til dette er at det gjøres for sjeldent. Man sparer det liksom til alt går skikkelig skeis. Derfor, gjør Post Mortemer! Men enda viktigere, gjør det ofte! Det trenger ikke være voldsomme greier, men ved å gjøre øvelsen også på småting blir man bedre på det. Jeg opplevde også at det var når vi gjorde det ofte, at vi fikk en del sterke ringvirkninger. Spesielt det å bygge en kultur for å reflektere sammen og gjøre små justeringer underveis. Det er ikke kun Post Mortemer som står for dette, men det er et fint verktøy i jakten på en delings- og læringskultur.
Det var egentlig det viktigste jeg hadde på hjertet. Hvis du likevel vil lese noen erfaringer fra en som bryr seg en del om Post Mortemer, eller er litt nysgjerrig på en konkret måte å gjennomføre det på, har jeg prøvd å skrive litt om det under her!
Ørteåførti slag
Først av alt, Post Mortem har mange variasjoner. Jeg har hørt at det kom fra ambulanse-verdenen hvor de satte seg ned, kanskje med en kopp kaffe, etter at en pasient døde for å se hva de kunne forbedre til neste gang. Jeg veit ikke om det er sant, men synes uansett det fremhever noen viktige elementer ved Post Mortem, så jeg beholder denne potensielle skrønen med glede.
- Det handler ikke kun om teknologi og tekniske greier.
- Det handler om å fokusere på det å lære, reflektere og forbedre seg.
- Det handler om å løfte blikket ut av den bobla man sitter i når feil skjer og det koker bra.
- Det handler om å ta ansvar. At feil skjer er en naturlig del av jobben/livet/endring, men vi skal ikke la det gjenta seg.
- Det handler om å dele lærdommene sine med de rundt seg.
Så har du dette med blameless. Det viktige her er at det handler ikke om skyld. Eller å fordele skyld. Hvis du legger opp til en kultur hvor man fordeler skyld legger du indirekte også opp til en kultur hvor det lønner seg å skjule feil man gjør. Det kan man vel trygt si at jobber mot en delings- og læringskultur.
Dette er en del av prinsippene jeg synes er viktigst når vi tenker på hvorfor.
Hvordan
La oss nå se litt på hvordan. Jeg er egentlig ikke så kresen på nøyaktig hvordan man gjør Post Mortem. Det er mange maler og metoder. Jeg tror også veldig mange av de fungerer brillefint, så lenge man tenker på hva man skal få ut av det og husker på noen prinsipper om hvordan man tar vare på hverandre i en slik prosess. Hvis jeg får velge så vil jeg nok foretrekke de mindre omfangsrike variantene, bare for å senke terskelen, men det er ikke så farlig for meg.
Likevel er det greit å ha et eksempel! Du finner et eksempel på en mal og et par pekere til hvordan avholdet Post Mortemen (møtet) nederst i artikkelen.
Tommelfingerregel og noen andre regler på kjøpet
KJØR POST MORTEM PÅ ALT! Hvis det er en ting jeg ønsker at folk tar med seg fra denne artikkelen er det å kjøre post mortem oftere. Ikke bare de virkelig store hendelsene. Det er en kjempefin prosess for å drive med kontinuerlig forbedring. Gikk noe nesten galt, men man fanga det i tide? Topp! Da har man en mulighet til å ta ut litt rask læring med null impact, det er jo win-win. Sleng sammen en kort tidslinje på 5 minutter og kjør en 30-minutters post mortem med noen andre i teamet, så sørger man for at det som nesten gikk galt denne gangen ikke skjer igjen.
Triage: Det kan være lurt å kategorisere hvor stor hendelsen er. Var det en nesten-feil eller gikk absolutt alt ned. Mest for å senke terskelen når det egentlig ikke gikk så galt.
Smi mens liket er varmt. Det er ikke bare en Øystein Sunde-låt. Det å utsette en Post Mortem er sjelden positivt. Prøv å avholde den så tidlig det lar seg gjøre for at de viktigste personene skal være med.
Muskelen må trenes. Hvis du gjør det jevnlig går det raskere. Det er heller ikke så ubehagelig etter hvert som det kanskje er i starten.
Produktleder bør melde seg på. Dette er en gyllen mulighet til litt innsikt i dine kollegaers hverdag med produktet. I tillegg har det en sterk signaleffekt for at man bryr seg om hele produktet. Jeg har i hvert fall aldri opplevd det som negativt at en produkteier/leder er med, så lenge de følger spillereglene.
Kultur og kvalitet. Som mye her er det kanskje litt selvsagt, men jeg sier det likevel. Reflekterer man over feil hyppig og tar læring av dette, bygger du også en kultur hvor folk er trygge på hverandre og man jobber sammen for å bli bedre. Ringvirkningene er mange, alt fra at folk ansvarliggjøres for jobben de gjør til å synliggjøre verdien av å bygge robuste tjenester, som igjen gir høyere kvalitet på tjenestene dine.
Post Mortem er et stort tema, jeg håper likevel at jeg klarte å trekke frem noen nyttige erfaringer som man kan bruke til å teste litt nye ting i teamet. Lykke til i jakten på kontinuerlig forbedring! 🚑
Oppskriften
Mal
Del 1:
Kort beskrivelse av hendelsen (en setning eller to):
Incident-eier (dette avhenger litt av hvordan dere håndterer feilsituasjoner hos dere):
Involverte:
Tidslinje:
19:12 : Første alarmen gikk
19:15 : Vakt sjekket opp og så omfanget
19:18 : Kundeservice hadde lagt ut statusmelding på nettsider osv.
Del 2:
Rotårsak: Hva skjedde?
Hva gikk bra?
Hva gikk ikke så bra?
Hvor var vi heldige?
Konkrete tiltak:
Liste med oppgaver med hvem som er ansvarlig for hver.
Post Mortem prosess
Først, hvordan dere håndterer en hendelse er opp til dere. Det avhenger av rutiner, har man vakt eller ikke, hva slags kunder og produkt har man, osv. Her legger jeg bare til grunn at noen har ansvar for å følge opp en post mortem i etterkant.
Det kan være lurt å fylle ut spesielt tidslinjen samtidig som hendelsen pågår eller kort tid etter. Hvis ikke glemmer man fort noe. Alt i del 1 kan fylles ut før man avholder Post Mortemen.
Det fysiske møtet: Når ting er under kontroll kjører man en Post Mortem! Det vil si, vi setter oss ned i et rom sammen, fysisk er absolutt å foretrekke her. Mest fordi det kan skape litt større nærhet i og med at en slik prosess kan føles ganske sårbar for noen. Da er det fint å gjøre det man kan for å skape trygghet.
Del 1 i møtet: Aller først diskuterer man tidslinjen for å sørge for at den er riktig, og legger til og endrer ting til man er fornøyd. Hvor detaljert man skal være varierer litt her, og er litt smak og behag. Poenget er at vi skaper en felles enighet om hva som har skjedd. Husk også at det andre tenker på som det viktigste kanskje ikke er det samme for deg. Vi er jo tross alt forskjellige folk med forskjellig ansvar. Jeg anbefaler å legge til det meste som tas opp her, det skader ikke å ha et punkt ekstra i tidslinja!
Del 2 i møtet: Det er her rosinen i pølsa er, læringen. Personlig liker jeg å snakke om hva som gikk bra, hvor det ikke fungerte så bra og ikke minst hvor vi var heldige. Her er blameless-biten ekstremt viktig. Jeg synes møteleder kan være ganske streng på å arrestere blameful oppførsel hvis det dukker opp. Bedre å stoppe det tidlig enn å la det sette røtter. Ikke fokuser på feil en person har gjort, men heller se på hvordan man kan unngå dette neste gang. Man bør diskutere metodikk, rutiner og overvåkning vel så mye som tekniske detaljer.
Oppfølgning: Den som avholdt Post Mortemen eller noen andre er ansvarlig for å følge opp alle oppfølgningspunktene. De bør være små, konkrete oppgaver. Jeg anbefaler også å prioritere disse på toppen av backloggen, så de ikke blir liggende lenge.