Hvorfor Kanban fungerer – og hvordan du vet om teamet ditt er klart for det

De fleste team tar i bruk Kanban fordi noen leste et blogginnlegg. Det smartere spørsmålet er om problemene Kanban løser, faktisk er problemene teamet ditt har.

Det finnes et øyeblikk de fleste team kjenner igjen, vanligvis når de passerer åtte–ni personer. Arbeidet blir gjort – e-poster sendes, funksjoner lanseres, kunder følges opp – men ingen har et klart bilde av hva alle andre holder på med. Prosjekter hoper seg opp. Ting blir lovet og så stille glemt. Du bruker tjue minutter før hvert møte på å finne ut hvor en arbeidsoppgave faktisk er. Svaret er som regel «et sted».

Det er dette problemet Kanban ble laget for å løse. Ikke problemet med å sette strategi, ansette riktige folk eller bygge en kultur – men det helt konkrete, slitsomme driftsproblemet med å vite hva teamet jobber med og hva som står i veien.

Det er et overraskende nøkternt verktøy for noe som har fått så mye oppmerksomhet. Kanban hevder ikke å fikse organisasjonen din. Det gjør bare arbeidet synlig. Og det viser seg at synlighet, brukt jevnt og trutt, endrer et bemerkelsesverdig antall ting videre nedover i kjeden.

Hvor Kanban egentlig kommer fra

Ordet er japansk – det betyr «skilttavle» eller «reklameskilt» – og systemet ble utviklet av Toyota på slutten av 1940-tallet for å styre lagerbeholdningen i fabrikkene. Ideen var enkel: I stedet for å produsere deler etter en fast plan skulle fabrikken bare produsere dem når en stasjon lenger ned i linjen ga signal om at den trengte dem. Et fysisk kort – kanban – gikk tilbake oppover linjen som en forespørsel. Ingenting ble produsert på spekulasjon. Ingenting hopet seg unødvendig opp.

Innsikten Toyota hadde, og som programvareteam senere lånte, er at det meste av ineffektiviteten i et system ikke kommer av at folk jobber for sakte, men av at feil arbeid blir gjort til feil tid. For mange ting påbegynt samtidig. Flaskehalser som ingen legger merke til før det er for sent. Arbeid som ligger ferdig ett sted mens neste ledd drukner et annet sted.

Programvareutviklere, særlig i selskaper som Microsoft tidlig på 2000-tallet, begynte å tilpasse disse ideene til kunnskapsarbeid. Kortene ble oppgaver. Fabrikkstasjonene ble trinn i en arbeidsflyt. Og skilttavlen ble en tavle – først fysisk, så digital – der alle i teamet med et blikk kunne se hva som var i gang, hva som ventet og hva som var ferdig.

Hva en Kanban-tavle faktisk viser deg

En enkel Kanban-tavle har tre kolonner: Å gjøre, Pågår og Ferdig. Det er nok for mange små team og et fint sted å starte. Men den virkelige verdien kommer når du begynner å tilpasse trinnene slik at de passer til hvordan arbeidet ditt faktisk flyter – ikke hvordan du skulle ønske det fløt.

Et innholdsteam kan bruke: Idé, Brief, Under utkast, Til gjennomgang, Planlagt, Publisert. Et programvareteam kan dele «Pågår» i egne kolonner for utvikling, kodegjennomgang og QA. Et konsulentteam kan følge: Behovsavklaring, Tilbud, Aktiv, Venter på kunde og Avsluttet. Trinnene bør gjenspeile reelle overleveringer og reell ventetid – steder der arbeid skifter hender, eller der det blir liggende til noe annet skjer.

Legg merke til kortet i den midterste kolonnen – revisjonsrapporten for lageret, åtte dager inne, merket som blokkert. I et system uten tavle kunne denne oppgaven blitt liggende i to uker til før noen skjønte at den ikke beveget seg. Noen venter på en tredjepart. Eller en beslutning må tas av en leder som ikke vet at han eller hun er flaskehalsen. Tavlen gjør blokkeringen synlig. Det er det meste av jobben.

Regelen som får det til å fungere: WIP-grenser

Hvis det finnes ett begrep som skiller team som bruker Kanban riktig fra team som bare har en penere gjøremålsliste, er det grenser for pågående arbeid – WIP-grenser (work in progress). Ideen er at hver kolonne har et maksimalt antall elementer som kan ligge der samtidig. Når en kolonne er full, kan du ikke legge til mer arbeid før noe flyttes ut.

Dette virker mot sin intuisjon. Betyr ikke flere oppgaver i gang at mer blir gjort? Nei. Det som faktisk skjer når folk jobber med for mange ting samtidig, er at alt tar lengre tid. Det koster mye å bytte mellom oppgaver. Halvferdig arbeid skaper ekstra koordineringsarbeid. Og når ti ting er «i gang», er det veldig vanskelig å se hvilke som faktisk beveger seg, og hvilke som bare står fast uten å være markert.

En WIP-grense på tre i kolonnen Pågår betyr at når den fjerde oppgaven lander på noens bord, må noen i teamet ta en beslutning: Hvilken av de eksisterende oppgavene skal ferdigstilles først? Det tvinger frem prioritering. Det tvinger frem samtale. Og det gir som regel raskere ferdigstilling av enkeltoppgaver, selv om takten for å starte nye går ned.

Kanban mot Scrum: spørsmålet team alltid stiller

Hvis du har vært borti programvareteam eller moderne driftstenkning, har du sannsynligvis støtt på Scrum – rammeverket som organiserer arbeidet i faste sprinter på to uker, med planleggingsmøter, retrospektiver og definerte roller som Scrum Master og Product Owner. Mange team ser på Scrum og Kanban som konkurrerende metoder og føler at de må velge. Forskjellen er faktisk enklere enn som så.

Mange team – særlig de som ikke er rene programvareutviklingsteam – synes Scrums seremonier er tunge og den faste sprintstrukturen klønete å bruke på løpende driftsarbeid. Markedsføringsteam, kundesuksessteam, driftsteam og gründere som styrer alt på én gang, har sjelden arbeid som passer pent inn i toukerssykluser. Kanbans modell med kontinuerlig flyt passer som regel bedre for dem.

Når det er sagt, kombinerer mange team begge deler. De bruker planlegging i sprintstil for produktutvikling og kjører samtidig en Kanban-tavle for drifts- og supportarbeidet som kommer inn uansett hvilken sprint du er i. Det er en fullt fornuftig hybrid.

De tre spørsmålene tavlen din bør svare på på tretti sekunder

En Kanban-tavle er mest nyttig når du kan se på den og raskt svare på disse tre spørsmålene uten å snakke med noen: Hva jobber teamet med akkurat nå? Hvor står arbeidet fast? Er det noe som burde vært gjort, men som ikke er startet?

Hvis du ikke kan svare på alle tre innen tretti sekunder etter å ha sett på tavlen, blir den sannsynligvis ikke vedlikeholdt skikkelig. Den vanligste feilen er en tavle der oppgaver blir opprettet, men aldri flyttet – den blir en kirkegård for gode intensjoner i stedet for et levende kart over faktisk arbeid. En tavle som ikke er oppdatert, er verre enn ingen tavle, fordi den gir en falsk følelse av oversikt.

Disiplinen som kreves for å holde en tavle oppdatert, er reell. Oppgaver må flyttes når arbeidet flyttes. Blokkerte elementer må flagges i det øyeblikket de stopper opp, ikke to uker senere. Kort må ha tydelige eiere, og eierne må oppdatere kortene sine. Ingenting av dette tar mye tid – en velfungerende Kanban-praksis kan ta fem til ti minutter per person per dag – men det krever jevnhet. Teamene som får mest ut av Kanban, er de som behandler tavlen som sannhetskilden, ikke som en tilleggsøvelse i journalføring.

Hva Kanban ikke gjør

Kanban er ikke et strategiverktøy. Det hjelper deg ikke med å finne ut hva du skal jobbe med – bare med å styre det du allerede har bestemt deg for å jobbe med. Hvis organisasjonen din har et problem med prioritering, uklart mandat eller et «vi starter for mange prosjekter før vi er ferdige med de gamle»-problem som stammer fra lederatferd og ikke fra prosess, vil en Kanban-tavle avsløre problemene, men ikke løse dem.

Det er heller ikke en erstatning for god ledelse. En tavle erstatter ikke samtaler mellom leder og medarbeider, gjennomtenkt delegering eller tydelig kommunikasjon om hvorfor visst arbeid er viktig. Team tar noen ganger i bruk prosessverktøy i håp om at prosessen skal gjøre det relasjonelle og organisatoriske arbeidet som egentlig er lederens jobb. Det gjør den ikke.

Det den derimot gjør, er å redusere den diffuse usikkerheten som bremser de fleste team. Spørsmålene «hvem jobber med hva», «er dette ferdig» og «hva bør jeg ta fatt på neste gang» skaper enorme mengder kommunikasjon med lav verdi i organisasjoner som ikke har et felles, synlig system. Kanban fjerner det meste av denne støyen. Og for team der støyen er det dominerende problemet, er forskjellen betydelig.

Slik kommer du i gang – uten en workshop på tre dager

De beste Kanban-innføringene jeg har sett, startet smått og utviklet seg over tid. De verste involverte en konsulent, en todagers samling utenfor kontoret og en vakkert designet tavle som ingen brukte innen uke tre.

Start med teamet slik det faktisk er, og arbeidet dere faktisk har. Lag tre kolonner: Backlog, Pågår, Ferdig. Bruk tretti minutter sammen med teamet på å sette hvert eneste pågående arbeidselement på et kort. Bli enige om én regel: Når du begynner på noe, havner det på tavlen. Når det flytter seg, flytter du kortet. Ikke gjør noe annet de neste to ukene.

Etter to uker ser dere på tavlen sammen. Hvor hopet ting seg opp? Hva ble liggende i Backlog som alle hadde sagt var en prioritet? Hva gikk raskere enn forventet? Hva ble stående fast, og hvorfor? Bruk det du observerer til å justere kolonnene og gjøre dem mer presise. Kanskje «Pågår» må deles i «Pågår» og «Venter på eksterne». Kanskje du trenger en kolonne som heter «Til gjennomgang», fordi det trinnet stadig forsvinner. La tavlen utvikle seg etter det det faktiske arbeidet ditt viser, ikke etter hva en metodebok sier at den bør se ut som.

Det lange løpet: flytmåltall

Når et Kanban-system er i gang, genererer det data som de fleste team aldri bruker. Gjennomløpstid – den totale tiden fra en oppgave opprettes til den er fullført – er det viktigste. Hvis gjennomsnittlig gjennomløpstid for en typisk oppgave er tolv dager, og du vil ned på fem, har du nå et tall å jobbe mot og en tavle som viser deg hvor de ekstra syv dagene går.

Syklustid måler bare den aktive arbeidsperioden, uten tiden en oppgave ligger i backlogen. Gjennomstrømning måler hvor mange elementer teamet ditt fullfører per uke. Ingen av disse måltallene krever spesialprogramvare hvis du er disiplinert nok til å notere når kort opprettes og når de lukkes. Og sammen gir de deg et mye ærligere bilde av teamets kapasitet enn noen estimatbasert planleggingsprosess kan gi.

De fleste små og mellomstore team kommer aldri hit. De bruker Kanban som et verktøy for oversikt – noe som er verdifullt i seg selv – og går ikke lenger. Det er helt greit. Men hvis du finner ut at du vil gi interessentene forpliktende svar på når noe blir ferdig, eller forstå hvorfor noe arbeid tar tre ganger så lang tid som forventet, finnes måltallene der når du trenger dem.