Fra Scrum til Kanban: trenger vi iterasjonene?
De fleste Scrum teamene har veldig god nytte av iterasjonene. Ingen tvil om at dette har en rekke gode effekter. Det gir et formidabelt fokus. Det gir teamet muligheten for å gi ganske presise estimater for et begrenset omfang. Vi klarer å innarbeide gode, effektive rutiner for rask planlegging og avslutning av iterasjonene. 
Dette er gode synkroniseringspunkter, noe de som kjører flere paralelle team på samme produkt får mye nytte av. Men først og fremst institusjonaliserer dette læring. Vi oppsummerer iterasjonen vi akkurat har vært igjennom, ser tilbake, og så gjør vi små grep for å bli bedre.
I tillegg til dette gir skal vi jo lage et inkrement av produktet som er av en slik kvalitet at det kan leveres. Er vi heldige er resultatet av iterasjonen en MMF (Minimal Marketable Feature (set)) slik at vi faktisk kan levere noe til ekte brukere og derigjennom få verdifull feedback på det arbeidet vi har gjort og den retningen vi har staket ut for produktet.
Fra tid til annen møter jeg team som ikke helt får dette med iterasjoner til å passe inn i deres hverdag. Hva er det som kjennetegner disse? Jeg tror det er to kategorier:
Kategori 1: De som ikke klarer å planlegge én uke fram i tid – de er hendelsesstyrte. Dette er som oftest de som drifter systemer i utstrakt bruk og som egentlig jobber med support. Sakene de jobber med dreier seg i stor grad om hastesaker som bare må løses i en fart. Bugs og tilpasninger med høy prioritet. Vi er i brannslokkingsmodus.
Kategori 2: De som er underlagt tidskonstanter som ikke harmonerer med én måneds horisont. Dette er nok hardware/elektronikk/mekanikk-utvikling med noe prgramvare oppå. Vi må bare erkjenne at muligheten til å stykke opp i delleveranser ikke alltid er fysisk mulig når vi utvikler hardwaren sammen med softwaren. Denne kategorien lar vi ligge i denne omgang.
Hvor mye brenner det egentlig?
Vi ønsker jo at Scrum teamet skal kunne detaljplanlegge Sprintene og ha stor grad av forutsigbarhet slik at de fleste Sprintene går på plan og leverer god funksjonalitet. Dette kan vi ikke forvente av et team som ikke har særlig kontroll på tiden sin! Hvordan kan teamet committe seg til en Sprint backlog om de stadig erfarer at ikke planlagt arbeid og avbrytelser slår bena under estimater og forpliktelser?
Det første man kan spørre seg er “hvordan kan vi begrense andelen brannslokking?” Her kan det være mye å hente ut. Bare en bevisstgjøring kan mange steder hjelpe litt. “Er du helt sikker på at dette ikke kan løses på vanlig måte i løpet av neste iterasjon?” Her hjelper det selvsagt med så korte iterasjoner som mulig.
Vi kan kanskje redusere andelen brannslokkingen gjennom bedre filtrering i tidlig linje support. Et Scrum team bør ikke belemres med trivielle saker som kunne vært tatt hånd om på telefonsupport.
Og så må vi selvsagt redusere antall hendelser ved å lage pålitelige og brukervennlige produkter som treffer brukernes behov. Dette er det langsiktige tiltaket som kan redusere denne effekten betraktelig.
Smidig brannslokking?
OK, vi har redusert andelen brannslokking til et minimum, men hverdagen minner allikevel om slukking av småbranner. Vi er her i “ITIL-land”; vi håndterer ulike strømmer av problemer som kan være underlagt ulike nivåer av servicegrad. En forholdsvis stor andel av disse problemene MÅ løses umiddelbart. Vi må “release” – eller “patche ut” – fortløpende. Iterasjonene virker unødvendige – rett og slett i veien.
Spørsmålet er – kan vi jobbe smidig uten iterasjoner? En ting er sikkert – Scrum har iterasjoner. Der er Scrum veldig klar. Men kanskje vi kan gå tilbake til røttene og finne løsninger i Toyota Production System? Toyota bruker Kanban for å sørge for at innkommende arbeid ikke overstiger ledig kapasitet – og for å sørge for å minimalisere ting i arbeid. Saker under arbeid er definert som waste og skal stadig utfordres.
Hva er Kanban?
Kanban er et signalleringssystem Toyota – og andre som bekjenner seg til Lean – bruker for å sikre at gjennomstømningen av arbeid er optimal og at antall saker i arbeid holdes på et minimum. Selve signalet er ofte implementert med et slags fysisk kort som styrer mengden innkommende arbeid.
Kanban Eksempel: Mengden ferskvarer i en butikkdisk. Vi ønsker å vise fram at vi har en del flotte varer, men vi må også passe på at ikke for mange eksemplarer ligger framme og blir dårlige. Når vi har solgt en del signallerer vi til kjølelageret at vi trenger påfyll – men ikke mer enn at vi har kontroll på kvaliteten. Dette styrer vi best etter at vi vinner erfaring og blir bedre og bedre til å prediktere hvor stor etterspørselen er.
Fra Scrum til Kanban
Scrum har tre faser som vi repeterer om igjen og om igjen: Planlegging, gjennomføring og avslutning. Hver iterasjon skal da ende opp med noe som er fullstendig ferdig i henhold til en definisjon. Dette fungerer veldig godt når vi har et team som forplikter seg til et definert scope i begynnelsen av hver iterasjon. 
Dette betinger igjen at teamet har noenlunde kontroll på tiden sin. Mange team styrer Sprinten ved at de bruker Task Board (kort som representerer det arbeidet de har tatt på seg som og så følger de den sekvensen som de definerer). Det er mye Kanban tankegang bak dette. Selv om Scrum ikke sier noe om det, vil rutinerte Scrum team vite at det lønner seg å begrense antall saker under arbeid. Vi fullfører så langt det er mulig en og en sak. 
Nå er virkeligheten som sagt ikke helt sånn for en del team. De er nødt til å planlegge med at en andel av tiden går med til ikke planlagt arbeid. Vi kan i løpet av få iterasjoner bygge opp godt erfaringsgrunnlag på hvor stor denne andelen er. Vi ser av figuren at vi også da må planlegge med en ekstra tilstand for lappene, nemlig I Produksjon. Hastesakene som kommer inn er ofte slik at de må deployes så fort som mulig. Dette er vel og bra, men det er ikke heldig for teamet å måtte håndtere to slike køer med ulik flyt. All erfaring viser at blir andelen ikke planlagt arbeid for stor, blir det tilsvarende vanskelig for teamet å gi gode forpliktende estimater under planleggingen. Dette blir lett som et sammensurium av asynkron og synkron signallering – hvilket sjelden er vellykket!
Vi forsøker her å presse det som er viktigst inn i en prosessmodell som det ikke er egnet for. Kanskje vi skulle tenke motsatt? Kanskje ad hoc-strømmen av vedlikeholdssaker skulle få bestemme flyten? Da kan vi tenke oss innkommende arbeid som en jevn støm av nyutvikling, tilpasninger og hastesaker. 
Vi må da være gode til å prioritere løpende. Her kan SLA avtaler være til god hjelp. Og så må vi være gode på å deploye ofte – på en trygg måte. Forsøke å komme vekk fra “patche-kulturen” og heller gjøre trygg og god deployment oftere og oftere slik at man etter hvert klarer å automatisere maksimalt av dette. I en slik prosess må vi også være nøye på at vi ikke har for mange ting i arbeid. Det bør finnes regler for hva som er høyeste tillatte antall i både In Progress, To Be Verified og DONE kolonnene.
Hva taper vi med ren Kanban-flyt?
Først og fremst taper vi rytmen. Det blir antageligvis vanskeligere å stoppe opp og lære av erfaring uten iterasjonene. Og det blir nok også vanskeligere å prediktere fremover i tid. Velocity er helt avhengig av iterasjoner. Når det er sagt, vi mangler erfaring med slik fremgangsmåte. Kanskje det ligger uoppdagete muligheter i denne framgangsmåten? Kanskje noen der ute har erfaringer å dele?
Det er ganske stor interesse for Kanban for tiden. Henrik Kniberg skriver for tiden en artikkel om temaet. Og David Anderson har en veldig inteerssant presentasjon fra sin tid i Microsoft på infoQ. Denne casen er fra et sustaining team i India på CMMI nivå 5 som trengte å forbedre gjennomløpstiden. Det klarte de til gangs!
In: inkrementell utvikling, Kanban, Scrum · Tagged with: Kanban, Lean, Scrum