Mejslas logga

Artiklar för Expert Network

Under åren 2016–2019 samarbetade IDG med ett antal utvalda experter inom IT. De skrev artiklar om "spaningar", och artiklarna publicerades i tidningar som CIO Sweden, Computer Sweden och TechWorld.

Karl Dickson - Expert Network

Under 2024 bytte IDG publicerings­system, och de flesta artiklarna plockades då bort från deras webbplatser. De artiklar som Mejsla bidrog med till Expert Network publiceras nu här på Mejslas webbplats med tillåtelse från IDG.

Tre tips för bra retrospektiv i Kanban

När man byter utvecklings­process är det lätt att slänga ut barnet med bad­vattnet. Flera av våra kunder har övergått till Kanban som är en utvecklings­process som passar organisationer med ständiga om­prioriteringar. En hörnsten i Kanban är kontinuerlig förbättring, men tyvärr har jag sett exempel på att man tappar detta just i över­gången från Scrum till Kanban.

Det påminner lite om vad som hände i övergången från tung­viktiga processer till agila metoder och processer som XP och Scrum. I det agila manifestet är en av punkterna ”fungerande programvara framför omfattande dokumentation”. En lysande sak med det agila manifestet är att alla punkterna är på formen ”x framför y”. Det betyder inte att y är oviktigt, bara att x är viktigare. Tyvärr verkar många ha miss­tolkat manifestet som att dokumentation inte är viktigt. Som en konsekvens har jag under det senaste decenniet stött på alltför många företag som sitter med mer eller mindre helt odokumenterade system — system som blir alltmer smärtsamma att underhålla. Vilka beroenden finns på den här databas­tabellen? Vad är tanken med det där del­systemet? Vilka ska komma åt de här tjänsterna? I över­gången från de tung­viktiga processerna till de lätt­viktiga slängde man ut dokumentationen med badvattnet.

I Scrum delas arbetet upp i sprintar som typiskt löper över några veckor, och varje sprint avslutas med ett retrospektiv där man tillsammans går igenom hur man kan förbättra sitt sätt att arbeta. Scrum passar dock inte alla organisationer, och ett vanligt problem är att sprintarna är svåra att förena med täta om­prioriteringar. I det läget vänder sig många till Kanban som inte låser utvecklings­arbetet till sprintar. När utvecklings­takten ökar och fel­rapporterna börjar brinna erbjuder Kanban en rimlig balans mellan att å ena sidan fokusera på det som för stunden har högst prioritet och å andra sidan se till att avsluta det man har påbörjat. En fara med att frångå sprintarna är dock att man tappar den rytm där retrospektiven passar in naturligt, och det är då som retrospektiven och den kontinuerliga förbättringen riskerar att åka ut med badvattnet.

Givetvis behöver man inte överge retrospektiven för att man överger sprintarna. Ett sätt är att, oberoende av flödena i Kanban, boka in regelbundna retrospektiv. Man kan till exempel bestämma att man har retrospektiv var fjärde torsdag. Ett annat alternativ är att man samlar på förbättrings­idéer och kallar till retrospektiv så snart man har fått ihop ett förut­bestämt antal idéer. Man kan till exempel ha ett ställe i anslutning till sin kanban­tavla där den som har kommit på en förbättrings­punkt kan sätta upp en lapp, och när man har det förut­bestämda antalet lappar bokar man in ett retrospektiv.

Just i övergången från Scrum till Kanban är det tre saker som jag vill lyfta fram för att retrospektiven ska bli bra.

Med bra retrospektiv har man goda möjligheter att få ordning på allt annat, och när man byter process är det extra viktigt att även hålla koll på att inget viktigt rinner ut med badvattnet.


Denna artikel publicerades ursprungligen hos IDG i februari 2018.
Författare: Karl Dickson