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

De fleste teams vedtager Kanban fordi nogen læste en blogindlæg. Det smartere spørgsmål er om problemerne Kanban løser faktisk er de problemer dit team har.

Der er et øjeblik de fleste teams genkender, normalt omkring tidspunktet hvor de har mere end otte eller ni personer. Arbejdet udføres — emails sendes, funktioner leveres, klienter administreres — men ingen har et klart syn på hvad alle andre gør. Projekter hober sig op. Ting bliver lovet og derefter stille glemt. Du bruger tyve minutter før hvert møde på at finde ud af hvor et arbejdsemne faktisk er. Svaret er normalt "et sted."

Det er problemet Kanban blev designet til at løse. Ikke problemet med at sætte strategi, eller at ansætte de rigtige mennesker, eller at bygge en kultur — men det specifikke, slidende, operationelle problem med at vide hvad dit team arbejder på og hvad der kommer i vejen.

Det er et overraskende beskedent værktøj for noget der har tiltrukket så meget opmærksomhed. Kanban påstår ikke at reparere din organisation. Det gør arbejde synligt. Og det viser sig at synlighed, anvendt konsistent, ændrer et bemærkelsesværdigt antal ting nedstrøms.

Hvor Kanban faktisk kom fra

Ordet er japansk — det betyder "skilte" eller "plakat" — og systemet blev udviklet af Toyota i slutningen af 1940'erne som en måde at administrere inventar i deres produktionsanlæg. Idéen var simpel: i stedet for at producere dele på et fast skema, ville fabrikken producere dem kun når en downstream station signalerede at den havde brug for dem. Et fysisk kort — kanban'en — ville rejse tilbage op ad linjen som en anmodning. Intet blev lavet spekulativt. Intet blev akkumuleret unødvendigt.

Indsigten Toyota havde, og som softwareteams senere lånte, er at mest ineffektivitet i et system kommer ikke fra mennesker der arbejder for langsomt, men fra det forkerte arbejde der bliver gjort på det forkerte tidspunkt. For mange ting startet på en gang. Flaskehalse som ingen bemærker før det er for sent. Arbejde der sidder færdigt et sted mens næste trin er overvældet andre steder.

Softwareudviklere, især ved virksomheder som Microsoft i de tidlige 2000'ere, begyndte at tilpasse disse idéer til videnarbejde. Kortene blev opgaver. Fabrikstationerne blev stadier i en arbejdsgang. Og skiltet blev en tavle — fysisk først, derefter digital — hvor enhver i teamet kunne se på et øjeblik 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: At gøre, I gang, Færdig. Det er tilstrækkeligt for mange små teams og et fint sted at starte. Men den virkelige værdi opstår når du begynder at tilpasse disse stadier til at matche hvordan dit arbejde faktisk flyder — ikke hvordan du ønsker det flød.

Et indholdsteam kan bruge: Idé, Breif, I udkast, Under review, Planlagt, Udgivet. Et software team kan bryde "I gang" op i separate kolonner for udvikling, code review og QA. Et konsulentteam kan spore Opdagelse, Forslag, Aktivt, Venter på kunde og Lukket. Stadiene skal afspejle rigtige handoffs og rigtige ventetider — steder hvor arbejde skifter hænder, eller hvor det sidder til noget andet sker.

Bemærk kortet i midterkolonnen — lagerrevisions rapporten, otte dage ind, markeret som blokeret. I et system uden en tavle kan denne opgave sidde i yderligere to uger før nogen bemærker at den ikke bevæger sig. Nogen venter på en tredje part. Eller en beslutning er nødvendig fra en leder som ikke ved de er blokeringen. Tavlen gør blokering synlig. Det er størstedelen af arbejdet.

Reglen der gør det virker: WIP grænser

Hvis der er et koncept der adskiller teams bruger Kanban ordenligt fra teams der bare har en pænere at-gøre liste, er det work-in-progress grænser — WIP grænser for kort. Idéen er at hver kolonne har et maksimalt antal elementer der er tilladt at være der på en gang. Når en kolonne er fuld, kan du ikke tilføje mere arbejde til den holder noget flytter ud.

Dette føles kontraintuitivt. Sikker på at kunne putto mere opgaver i gang betyder mere bliver gjort? Det gør det ikke. Hvad der faktisk sker når mennesker arbejder på for mange ting samtidigt er at alt tager længere. Kontekst skifte er dyrt. Halvfærdigt arbejde skaber koordinerings overhead. Og når ti ting er "i gang" er det meget svært at fortælle hvilke der faktisk bevæger sig og hvilke der bare sidder fast men ikke markeret.

En WIP grænse på tre på din I gang kolonne betyder at når den fjerde ting ankommer til nogens skrivebord skal nogen i teamet foretage en beslutning: hvilket eksisterende arbejde bliver færdigt først? Det tvinger prioritering. Det tvinger samtale. Og det har tendens til at producere hurtigere afslutning af individuelle elementer, selvom hastigheden af at starte nye elementer bremses.

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

Hvis du har brugt tid omkring software teams eller moderne operationel tænkning, har du sandsynligvis mødt Scrum — rammen der organiserer arbejde i faste to-ugers sprints, med planlægnings sessioner, retrospektiver og definerede roller som Scrum Master og Produkt Owner. Mange teams behandler Scrum og Kanban som konkurrerende metodologier og føler de skal vælge. Sondringen er faktisk enklere end det.

Mange teams — især dem der ikke er ren software ingeniør teams — finder Scrum's ceremoni tung og dets faste-sprint struktur ubelejlig at anvende på vedvarende operationelt arbejde. Marketing teams, kundesucces teams, drift teams, og grundlæggere der administrerer alt på en gang har sjældent arbejde der passer fint op i to-ugers cykler. Kanban's kontinuerlige flow model passer dem normalt bedre.

Det sagt, mange teams kombinerer begge. De bruger sprint-style planlægnings cykler for produktudvikling mens de kører et Kanban tavle for det operationelle og support arbejde der flyder uanset hvilken sprint du er i. Det er en perfekt rimelig hybrid.

De tre spørgsmål din tavle skal svar på på tredive sekunder

En Kanban tavle er mest brugbar når du kan se på den og uden at snakke med nogen svar disse tre spørgsmål hurtigt: Hvad arbejder teamet på lige nu? Hvor sidder arbejde fast? Er der noget som burde gøres som ikke er startet?

Hvis du ikke kan svare på alle tre inden for tredive sekunder af at se tavlen, bliver den sandsynligvis ikke vedligeholdt ordenligt. Den mest almindelige fejl mode er en tavle hvor opgaver er skabt men aldrig flyttet — det bliver en gravplads for gode intentioner i stedet for et live kort over virkeligt arbejde. En tavle der ikke er aktuel er værre end ingen tavle, fordi det skaber en falsk fornemmelse af synlighed.

Disciplinen påkrævet for at vedligeholde en tavle er reel. Opgaver skal flytte når arbejde bevæger sig. Blokerede elementer skal markeres det øjeblik de staller, ikke to uger senere. Kort skal have klare ejere, og ejere skal opdatere deres kort. Intet af dette kræver meget tid — en velopbygget Kanban praksis kan tage fem til ti minutter per person per dag — men det kræver konsistens. De teams der får mest fordel af Kanban er dem som behandler tavlen som kilden til sandheden, ikke som en sekundær registrerings øvelse.

Hvad Kanban ikke gør

Kanban er ikke et strategi værktøj. Det vil ikke hjælpe dig med at finde ud af hvad du skal arbejde på — kun hjælp med at administrere hvad du allerede har besluttet at arbejde på. Hvis din organisation har et prioriterings problem, eller et uklart mandat problem, eller et "vi starter for mange projekter før vi afslutter gamle" problem som er rodfæstet i ledelsesadfærd i stedet for proces, vil en Kanban tavle afsløre disse problemer men ikke løse dem.

Det er heller ikke en erstatning for god ledelse. En tavle erstatter ikke en-til-en samtaler, eller gennemtænkt delegation, eller klar kommunikation omkring hvorfor visse arbejde betyder noget. Teams vedtager nogle gange proces værktøjer håbende processen vil gøre det relationelle og organisatoriske arbejde der faktisk er leders job. Det vil ikke.

Hvad det vil gøre er at reducere den omgivende usikkerhed der bremser de fleste teams. Spørgsmålene om "hvem arbejder på hvad," "er dette færdig" og "hvad skal jeg tage op næste" genererer enormt mange lav-værdi kommunikation i organisationer der ikke har et delt, synligt system. Kanban fjerner størstedelen af det støj. Og for teams hvor det støj er det dominerende problem, er forskellen signifikant.

Hvordan man starter — uden en tre-dages workshop

De bedste Kanban implementeringer jeg har set startede småt og udviklede sig. De værste involverede en konsulent, en to-dages offsite og en smukt designet tavle som ingen brugte ved uge tre.

Start med dit team som det faktisk er, med det arbejde du faktisk har. Opret tre kolonner: Backlog, I gang, Færdig. Verbring tredive minutter med dit team at pute alle nuværende arbejdsemner på et kort. Bliv enig om én regel: når du starter noget skal det være på tavlen. Når det bevæger sig, bevæger du kortet. Gør intet andet i to uger.

Efter to uger, se på tavlen sammen. Hvor hobede ting sig op? Hvad blev sat i Backlog som alle sagde var en prioritet? Hvad bevægede sig hurtigere end forventet? Hvad blev stoppet og hvorfor? Brug hvad du observerer til at raffinere kolonnerne og tilføje specifitet. Måske "I gang" skal dele op i "I gang" og "Venter på eksternt." Måske skal du have en kolonne kaldet "Under review" fordi det trin fortsætter med at blive glemt. Lad tavlen udvikle sig i respons til hvad dit virkeligt arbejde afslører, ikke i respons til hvad en metodologi bog siger den skal se ud til.

Det længere spil: flow metrics

Når et Kanban system kører, genererer det data som de fleste teams aldrig bruger. Lead time — den totale tid fra når en opgave er skabt til når den er færdig — er den vigtigste. Hvis din gennemsnitlige lead time for en typisk opgave er tolv dage, og du ønsker den at være fem, har du nu et tal at arbejde mod og en tavle der vil vise dig hvor de ekstra syv dage går.

Cycle time måler kun den aktive arbejds periode, udelukker tid en opgave sidder i backlog. Throughput måler hvor mange elementer dit team udfører per uge. Ingen af disse metrics kræver speciel software hvis du er disciplineret omkring at notere når kort er skabt og når de er lukket. Og sammen, giver de dig et meget mere ærligt billede af dit teams kapacitet end nogen estimat-baseret planlægnings proces kan.

De fleste små og mellem størrelse teams kommer aldrig hertil. De bruger Kanban som et synligheds værktøj — hvilket er værdifuldt i sig selv — og går ikke længere. Det er fint. Men hvis du finder dig selv ønskende at gøre tilsagn til interessenter omkring hvornår noget bliver gjort, eller ønsker at forstå hvorfor nogle arbejde tager tre gange så længe som forventet, er metrics her når du har brug for dem.