Hvorfor Kanban virker, og hvordan du ved, om dit team er klar til det

De fleste teams indfører Kanban, fordi nogen har læst et blogindlæg. Det kloge spørgsmål er, om de problemer, Kanban løser, faktisk er dem, dit team har.

Der er et øjeblik, som de fleste teams genkender, som regel omkring det tidspunkt, hvor de er mere end otte eller ni personer. Arbejdet bliver udført: Mails bliver sendt, funktioner bliver leveret, kunder bliver håndteret, men ingen har et klart overblik over, hvad alle de andre laver. Projekter hober sig op. Der bliver lovet noget, som så stille og roligt bliver glemt. Du bruger tyve minutter før hvert møde på at finde ud af, hvor en opgave egentlig er nået til. Svaret er som regel: »et eller andet sted«.

Det er det problem, Kanban blev designet til at løse. Ikke problemet med at fastlægge strategi, ansætte de rigtige folk eller bygge en kultur, men det helt konkrete, sejlivede, operationelle problem at vide, hvad dit team arbejder på, og hvad der står i vejen.

Det er et overraskende ydmygt værktøj, når man tænker på, hvor meget opmærksomhed det har fået. Kanban hævder ikke at kunne ordne din organisation. Det gør bare arbejdet synligt. Og det viser sig, at synlighed, når den bruges konsekvent, ændrer et bemærkelsesværdigt antal ting længere nede i processen.

Hvor Kanban oprindeligt kommer fra

Ordet er japansk og betyder »skilt« eller »opslagstavle«, og systemet blev udviklet af Toyota i slutningen af 1940'erne som en måde at styre lagerbeholdningen på i virksomhedens produktionsanlæg. Ideen var enkel: I stedet for at producere dele efter en fast plan ville fabrikken kun producere dem, når en efterfølgende station signalerede, at den havde brug for dem. Et fysisk kort, selve kanban-kortet, rejste tilbage op ad linjen som en anmodning. Intet blev lavet på spekulation. Intet hobede sig unødvendigt op.

Den indsigt, Toyota havde, og som softwareteams senere lånte, er, at det meste af ineffektiviteten i et system ikke skyldes, at folk arbejder for langsomt, men at det forkerte arbejde bliver gjort på det forkerte tidspunkt. For mange ting sat i gang på én gang. Flaskehalse, som ingen opdager, før det er for sent. Arbejde, der ligger færdigt det ene sted, mens det næste trin drukner et andet sted.

Softwareudviklere, især i virksomheder som Microsoft i begyndelsen af 00'erne, begyndte at tilpasse disse ideer til vidensarbejde. Kortene blev til opgaver. Fabrikkens stationer blev til trin i et arbejdsforløb. Og skiltet blev til en tavle, først fysisk og siden digital, hvor alle i teamet kunne se med et blik, hvad der var i gang, hvad der ventede, og hvad der var færdigt.

Hvad en Kanban-tavle faktisk viser dig

En grundlæggende Kanban-tavle har tre kolonner: Skal gøres, I gang og Færdig. Det er nok for mange små teams og et fint sted at starte. Men den egentlige værdi opstår, når du begynder at tilpasse trinene, så de svarer til, hvordan dit arbejde faktisk forløber, og ikke til, hvordan du ønsker, det forløb.

Et indholdsteam kan bruge: Idé, Brief, Under udarbejdelse, Til gennemsyn, Planlagt, Udgivet. Et softwareteam kan dele »I gang« op i separate kolonner for udvikling, kodegennemgang og QA. Et konsulentteam kan følge Afdækning, Tilbud, Aktiv, Afventer kunde og Afsluttet. Trinene skal afspejle reelle overdragelser og reel ventetid, altså steder, hvor arbejdet skifter hænder, eller hvor det bliver liggende, til noget andet sker.

Læg mærke til kortet i den midterste kolonne: rapporten om lagerrevisionen, otte dage inde i forløbet og markeret som blokeret. I et system uden tavle kunne den opgave blive liggende i yderligere to uger, før nogen opdager, at den ikke rykker sig. Nogen venter på en tredjepart. Eller der mangler en beslutning fra en leder, som ikke ved, at det er ham eller hende, der blokerer. Tavlen gør blokeringen synlig. Det er det meste af arbejdet.

Reglen, der får det til at virke: WIP-grænser

Hvis der er ét begreb, der adskiller de teams, der bruger Kanban ordentligt, fra de teams, der bare har en pænere huskeliste, er det grænser for igangværende arbejde, WIP-grænser (work in progress) for kort. Ideen er, at hver kolonne har et maksimalt antal elementer, der må være der på samme tid. Når en kolonne er fuld, kan du ikke tilføje mere arbejde, før noget flytter ud.

Det føles kontraintuitivt. Hvis man kan sætte flere opgaver i gang, må der vel blive lavet mere? Nej. Når folk arbejder på for mange ting på én gang, tager alting i virkeligheden længere tid. Det er dyrt at skifte kontekst. Halvfærdigt arbejde skaber ekstra koordinering. Og når ti ting er »i gang«, er det meget svært at se, hvilke der faktisk rykker sig, og hvilke der bare sidder fast uden at være markeret.

En WIP-grænse på tre i kolonnen »I gang« betyder, at når den fjerde opgave lander på nogens bord, må nogen i teamet træffe en beslutning: Hvilken af de eksisterende opgaver skal gøres færdig først? Det tvinger til prioritering. Det tvinger til samtale. Og det giver som regel hurtigere afslutning af de enkelte opgaver, selv om tempoet, hvormed man starter nye, bliver lavere.

Kanban versus Scrum: spørgsmålet, som teams altid stiller

Hvis du har beskæftiget dig med softwareteams eller moderne driftstænkning, er du sandsynligvis stødt på Scrum, den ramme, der organiserer arbejdet i faste sprints på to uger med planlægningsmøder, retrospektiver og definerede roller som Scrum Master og Product Owner. Mange teams opfatter Scrum og Kanban som konkurrerende metoder og føler, at de må vælge. Forskellen er i virkeligheden enklere end det.

Mange teams, især dem der ikke er rene softwareudviklingsteams, oplever, at Scrums ceremonier er tunge, og at den faste sprintstruktur er uhensigtsmæssig at anvende på løbende driftsarbejde. Marketingteams, kundesuccesteams, driftsteams og stiftere, der styrer alt på én gang, har sjældent arbejde, der passer pænt ind i cyklusser på to uger. Kanbans model med kontinuerligt flow passer som regel bedre til dem.

Når det er sagt, kombinerer mange teams begge dele. De bruger planlægningscyklusser i sprintstil til produktudvikling og kører samtidig en Kanban-tavle til det drifts- og supportarbejde, der kommer ind, uanset hvilken sprint man er i. Det er en helt rimelig hybrid.

De tre spørgsmål, din tavle skal kunne besvare på tredive sekunder

En Kanban-tavle er mest nyttig, når du kan kigge på den og hurtigt, uden at tale med nogen, besvare disse tre spørgsmål: Hvad arbejder teamet på lige nu? Hvor sidder arbejdet fast? Er der noget, der burde gøres, men ikke er startet?

Hvis du ikke kan besvare alle tre inden for tredive sekunder efter at have set på tavlen, bliver den sandsynligvis ikke vedligeholdt ordentligt. Den hyppigste fejl er en tavle, hvor opgaver oprettes, men aldrig flyttes. Den bliver en kirkegård for gode intentioner i stedet for et levende kort over det faktiske arbejde. En tavle, der ikke er opdateret, er værre end ingen tavle, fordi den skaber en falsk følelse af overblik.

Det kræver reel disciplin at vedligeholde en tavle. Opgaver skal flyttes, når arbejdet rykker sig. Blokerede opgaver skal markeres i det øjeblik, de går i stå, ikke to uger senere. Kort skal have klare ejere, og ejerne skal opdatere deres kort. Intet af det kræver meget tid: En velfungerende Kanban-praksis kan tage fem til ti minutter pr. person pr. dag, men det kræver konsekvens. De teams, der får mest ud af Kanban, er dem, der behandler tavlen som den primære kilde til sandheden og ikke som en ekstra øvelse i registrering.

Hvad Kanban ikke gør

Kanban er ikke et strategiværktøj. Det hjælper dig ikke med at finde ud af, hvad du skal arbejde på, men kun med at styre det, du allerede har besluttet at arbejde på. Hvis din organisation har et problem med prioritering, med et uklart mandat eller med, at »vi starter for mange projekter, før vi har afsluttet de gamle«, og det problem stikker i ledelsens adfærd og ikke i processen, vil en Kanban-tavle afsløre problemerne, men ikke løse dem.

Det er heller ikke en erstatning for god ledelse. En tavle erstatter ikke samtaler på tomandshånd, gennemtænkt uddelegering eller klar kommunikation om, hvorfor bestemt arbejde er vigtigt. Teams indfører nogle gange procesværktøjer i håb om, at processen klarer det relationelle og organisatoriske arbejde, som i virkeligheden er lederens opgave. Det gør den ikke.

Det, den gør, er at mindske den uvished, der hele tiden hænger i luften og bremser de fleste teams. Spørgsmål som »hvem arbejder på hvad«, »er det her færdigt« og »hvad skal jeg tage fat på næste gang« skaber enorme mængder kommunikation af lav værdi i organisationer, der ikke har et fælles, synligt system. Kanban fjerner det meste af den støj. Og for teams, hvor støjen er det største problem, gør det en markant forskel.

Sådan kommer du i gang uden en workshop på tre dage

De bedste Kanban-indførelser, jeg har set, startede i det små og udviklede sig undervejs. De dårligste involverede en konsulent, to dages seminar uden for huset og en smukt designet tavle, som ingen brugte i uge tre.

Start med dit team, som det faktisk er, og det arbejde, du faktisk har. Opret tre kolonner: Backlog, I gang og Færdig. Brug tredive minutter sammen med teamet på at lægge alle aktuelle opgaver på kort. Bliv enige om én regel: Når du starter på noget, kommer det på tavlen. Når det rykker sig, flytter du kortet. Gør ikke andet i to uger.

Efter to uger ser I sammen på tavlen. Hvor hobede tingene sig op? Hvad blev liggende i Backlog, selv om alle sagde, at det var en prioritet? Hvad gik hurtigere end forventet? Hvad gik i stå, og hvorfor? Brug det, I observerer, til at finjustere kolonnerne og gøre dem mere præcise. Måske skal »I gang« deles op i »I gang« og »Afventer eksterne«. Måske har I brug for en kolonne, der hedder »Til gennemsyn«, fordi det trin hele tiden bliver glemt. Lad tavlen udvikle sig efter det, jeres faktiske arbejde viser, og ikke efter, hvordan en metodebog siger, den skal se ud.

Det lange seje træk: flow-nøgletal

Når et Kanban-system kører, genererer det data, som de fleste teams aldrig bruger. Gennemløbstid (lead time), altså den samlede tid fra en opgave oprettes til den er færdig, er den vigtigste. Hvis din gennemsnitlige gennemløbstid for en typisk opgave er tolv dage, og du gerne vil have den ned på fem, har du nu et tal at arbejde mod og en tavle, der viser dig, hvor de ekstra syv dage går hen.

Cyklustid (cycle time) måler kun den aktive arbejdsperiode og udelader den tid, en opgave ligger i backloggen. Kapacitet (throughput) måler, hvor mange elementer dit team afslutter pr. uge. Ingen af disse nøgletal kræver særlig software, hvis du er disciplineret med at notere, hvornår kort oprettes, og hvornår de lukkes. Og samlet giver de dig et langt mere ærligt billede af dit teams kapacitet, end en planlægningsproces baseret på estimater kan.

De fleste små og mellemstore teams kommer aldrig så langt. De bruger Kanban som et værktøj til overblik, hvilket er værdifuldt i sig selv, og går ikke videre. Det er fint. Men hvis du får lyst til at give interessenterne tilsagn om, hvornår noget bliver færdigt, eller til at forstå, hvorfor noget arbejde tager tre gange så lang tid som forventet, er nøgletallene der, når du får brug for dem.