Retrospektivet är ett förbättringsmöte

Meningen med retrospektivet i Scrum är att det ska vara ett förbättringsmöte. Detta riskerar vi hela tiden att glömma bort. Det kan vara namnets fel: retrospektiv betyder återblick, när det borde heta framåtblick. Syftet med mötet är att ta reda på hur vi ska jobba framöver, inte att vi ska stanna vid funderingar kring hur det hittills har gått. Det heter om scrummötena att de allesammans är planeringsmöten. Först när vi planerat en förändring i arbetssättet har vi genomfört ett retrospektiv fullt ut. Allt annat är spill.

I mötet mellan bl a Taiichi Ohnos idéer om hur man bedriver verkstadsproduktion, och William Demings föreläsningar om metodiskt kvalitetsarbete, föddes handgreppen och tänkesätten runt ständig förbättring. Ständig förbättring bygger på ett par komponenter:

Riktning: Vi måste veta vart vi är på väg, annars kan vi inte veta vad som är bättre än någonting annat. Vanliga riktningar är till exempel: färre defekter, kortare omloppstid från idé till genomförande, större kunskapsspridning, och bättre mående.

Processer: Vi måste veta hur vi gör saker för att systematiskt kunna förbättra oss. Man talar om standardiserade arbetssätt: att vi försöker förhindra dålig variation i hur vi jobbar genom att ha formulerat vår process. För att förhindra processröta ser man till att processbeskrivningen är enkel och kortfattad och kan sättas upp på en vägg.

Orsaksanalys: När vi beslutat oss för att ta ett kliv i rätt riktning behöver vi ta bort det som idag hindrar oss. Vi behöver formulera hindret som ett problem och genomföra någon sorts orsaksanalys där vi genom att hela tiden ställa oss frågan "varför" tar reda på vilka orsakskedjor som orsakar hindret.

Motmedel: När vi tittar på orsakerna till vårt problem brukar man kunna se att man har olika sorters inflytande över dem:

• Man kan vara direkt orsak till problemet, ha all makt över det, och på så sätt kunna komma på ett sätt att göra annorlunda, så att problemet försvinner.
• Man kan vara förhindrad att upphäva orsaken, men man kan hitta ett sätt att göra annorlunda, så att effekten av problemet mildras.
• Man kan veta vem som har makt att upphäva orsaken, och hitta ett sätt att göra annorlunda, så att man visar på problemet.

Experimenterande: När man hittat ett sätt att göra annorlunda än vad de nuvarande processerna säger så skulle man kunna bestämma att man från och med nu arbetar enligt det nya sättet. Men det är inte ett evidensbaserat sätt att arbeta på. Istället bör man planera det som ett experiment (steget Plan i PDCA-cirkeln), genomföra det ändrade arbetssättet under nästföljande sprint (steget Do i PDCA), och sedan utvärdera det och basera nästa steg utifrån det (stegen Check och Act).

Självstyre: Både för att kunna genomföra experimentet och sedan bestämma om den prövade ändringen i arbetsprocesserna ska permanentas, behövs det självstyre. Brist på självstyre yttrar sig gärna i att resultatet från alla förbättringsmöten är beslut om att eskalera olika förslag om ändrade arbetssätt till högre ort. Det blir ett slags förslagslåda istället för förbättring. Brist på självstyre är ett mycket vanligt problem bland företag som velat införa smidiga arbetsmetoder inspirerade av japanska företag. De imiterar handgreppen med kvalitetscirklar och förbättringsmetoder, men glömmer att delegera mandatet. Då bör de tänka på att Taiichi Ohno, när han drog igång förbättringsmötena på fabriksgolvet, sa: "Nu har ni era standardiserade arbetsprocesser att arbeta efter. Om en vecka kommer jag tillbaks, och då ska ni ha ändrat dem!"

Kärnan i retrospektiven är att driva ständig förbättring. Kommer ni inte fram till ett ändrat arbetssätt har ni inte lyckats uppnå någonting. Då blir retrospektiven meningslösa. Inspiration till hur ni kan jobba finns i två böcker jag rekommenderar mycket varmt: Agile Retrospectives, making good teams great, samt Toyota Kata.