Hvorfor Kanban fungerer — og hvordan vet du om laget ditt er klart for det

De fleste lag bruker Kanban fordi noen leste en bloggpost. Det smartere spørsmålet er om problemene som Kanban løser faktisk er problemene som laget ditt har.

Det er et øyeblikk de fleste lag gjenkjenner, vanligvis rundt tiden de har mer enn åtte eller ni personer. Arbeid gjøres — e-poster sendes, funksjoner sendes, kunder styres — men ingen har et klart syn på hva alle andre gjør. Prosjekter staplet opp. Ting blir lovet og så stille glemt. Du bruker tjueni minutter før hvert møte for å finne ut hvor et arbeid faktisk er. Svaret, vanligvis, er "et eller annet sted."

Det er problemet Kanban ble designet for å løse. Ikke problemet med å sette strategi, eller å ansette de rette menneskene, eller å bygge en kultur — men det spesifikke, slitende, operasjonelle problemet med å vite hva laget ditt arbeider på og hva som står i veien.

Det er et overraskende beskjedent verktøy for noe som har tiltrukket så mye oppmerksomhet. Kanban gjør ikke krav på å fikse organisasjonen din. Det gjør bare arbeid synlig. Og det viser seg at synlighet, brukt konsekvent, endrer et bemerkelsesverdig antall ting nedstrøms.

Hvor Kanban faktisk kom fra

Ordet er japansk — det betyr "skiltavle" eller "reklameavle" — og systemet ble utviklet av Toyota på slutten av 1940-tallet som en måte å håndtere inventar på fabrikkene deres. Ideen var enkel: i stedet for å produsere deler på en fast tidsplan, ville fabrikken produsere dem bare når en nedstrøms stasjon signaliserte at den trengte dem. Et fysisk kort — kanban — ville reise tilbake opp linjen som en forespørsel. Ingenting ble laget spekulativt. Ingenting staplet seg unødvendig.

Innsikten Toyota hadde, og som programvareteam senere lånte, er at de fleste ineffektiviteter i et system kommer ikke fra mennesker som arbeider for sakte, men fra feil arbeid som blir gjort på feil tid. For mange ting startet på en gang. Flaskehalser som ingen legger merke til før det er for sent. Arbeid som sitter ferdig på ett sted mens neste trinn er overveldet andre steder.

Programvareutviklere, spesielt på selskaper som Microsoft i tidlig 2000, begynte å tilpasse disse ideene for kunnskapsarbeid. Kortene ble oppgaver. Fabrikken stasjoner ble stadier i en arbeidsflyt. Og skiltavlen ble en tavle — fysisk først, så digital — hvor alle på laget kunne se med et øyeblikk hva som var i gang, hva som ventet, og hva som var ferdig.

Hva en Kanban tavle faktisk viser deg

En grunnleggende Kanban tavle har tre kolonner: To Do, In Progress og Done. Det er tilstrekkelig for mange små lag og et fint sted å starte. Men den virkelige verdien oppstår når du begynner å tilpasse disse stadiene for å matche hvordan arbeidet ditt faktisk flyter — ikke hvordan du ønsker det flodde.

Et innholds lag kan bruke: Idé, Brief, In Draft, In Review, Scheduled, Published. Et programvare lag kan dele "In Progress" inn i separate kolonner for utvikling, kode gjennomgang og QA. Et konsulterings lag kan spore Oppdagelse, Forslag, Aktiv, Venter på klient og Lukket. Stadiene bør reflektere virkelige handover og virkelige ventetider — steder hvor arbeid endrer hender, eller hvor det sitter til noe annet skjer.

Legg merke til kortet i midtkolonnen — lager revisjons rapporten, åtte dager inne, merket som blokkert. I et system uten en tavle, kunne denne oppgaven sitte i to uker til før noen innser det ikke beveger seg. Noen venter på en tredjepart. Eller en beslutning er nødvendig fra en leder som ikke vet at de er blokkereren. Tavlen gjør blokkeringen synlig. Det er det meste av arbeidet.

Regelen som gjør det fungerer: WIP-grenser

Hvis det er ett konsept som skiller lag som bruker Kanban riktig fra lag som bare har en finere gjøremålsliste, er det arbeid-i-prosess-grenser — WIP-grenser for kort. Ideen er at hver kolonne har et maksimalt antall elementer som er tillatt å være der på en gang. Når en kolonne er full, kan du ikke legge til mer arbeid til noe beveger seg ut.

Dette føles mot-intuitivt. Sikkert å kunne sette mer oppgaver i gang betyr at mer kommer til å bli gjort? Det gjør ikke. Hva som faktisk skjer når mennesker arbeider på for mange ting samtidig er at alt tar lengre tid. Kontekst bytte er dyrt. Halvferdig arbeid skaper koordinerings overhead. Og når ti ting er "i gang," er det veldig vanskelig å si hvilke som faktisk beveger seg og hvilke som bare sitter fast men ikke er merket.

En WIP-grense på tre på In Progress kolonnen din betyr at når det fjerde kommer til noens skrivebord, må noen på laget ta en beslutning: hvilket eksisterende arbeid blir fullført først? Det tvinger prioritering. Det tvinger samtale. Og det pleier å produsere raskere fullføring av individuelle elementer, selv hvis hastigheten av å starte nye elementer avtar.

Kanban versus Scrum: spørsmål lag alltid spør

Hvis du har brukt tid rundt programvare lag eller moderne operasjons tenking, har du sannsynligvis møtt Scrum — rammeverket som organiserer arbeid inn i faste to-ukers sprintet, med planlegging økter, retrospektiver og definerte roller som Scrum Master og Produkt Eier. Mange lag behandle Scrum og Kanban som konkurrer metodologier og føler de må velge. Skiljet er faktisk enklere enn det.

Mange lag — spesielt de som ikke er ren programvare ingeniør lag — finner Scrum seremoni tung og dets faste sprint struktur usmidig å bruke på vedvarende operasjonelt arbeid. Markedsførings lag, kunde suksess lag, operasjons lag og grunnleggere som håndterer alt-på-en-gang sjelden har arbeid som passer ryddig inn i to-ukers sykler. Kanban sin kontinuerlig strøm modell pleier å passe dem bedre.

Det sies at mange lag kombinerer begge. De bruker sprint-stil planlegging sykler for produkt utvikling mens kjøring en Kanban tavle for operasjonell og støtte arbeid som flyter inn uavhengig av hva sprint du er inn. Det er en perfekt rimelig hybrid.

De tre spørsmålene ditt tavle bør svare på i trettien sekunder

En Kanban tavle er mest nyttig når du kan se på den og, uten å snakke med noen, raskt svare disse tre spørsmålene: Hva jobber laget med akkurat nå? Hvor er arbeid å få festet? Er det noe som burde gjøres som ikke er startet?

Hvis du ikke kan svare alle tre innen trettien sekunder av å se på tavlen, er den sannsynligvis ikke bli vedlikeholdt riktig. Den vanligste svikt modusen er en tavle hvor oppgaver blir opprettet men aldri beveget — det blir en gravplass av gode intensjoner i stedet for et levende kart over virkelig arbeid. En tavle som ikke er gjeldende er verre enn ingen tavle, fordi det skaper en falsk følelsen av synlighet.

Disiplinen som kreves for å vedlikeholde en tavle er riktig. Oppgaver må bevege seg når arbeid beveger seg. Blokkerte elementer må bli markert i det øyeblikk de staller, ikke to uker senere. Kort må ha klar eiere, og eiere må oppdatere deres kort. Ingen av dette krever mye tid — en velkjørt Kanban praksis kan ta fem til ti minutter per person per dag — men det krever konsistens. Lagene som drar mest nytte fra Kanban er de som behandler tavlen som kilden til sannhet, ikke som en supplement journal-øvelse.

Hva Kanban ikke gjør

Kanban er ikke et strategi verktøy. Det vil ikke hjelpe deg å finne ut hva du skal arbeide på — bare hjelpe deg å håndtere hva du allerede har avgjort å arbeide på. Hvis organisasjonen din har et prioriterings problem, eller et uklart mandat problem, eller et "vi starter for mange prosjekter før ferdig gamle" problem rotfestet i leder oppførsel i stedet for prosess, en Kanban tavle vil avsløre de problemene men ikke løse dem.

Det er heller ikke en erstatning for god ledelse. En tavle erstatter ikke en-til-en, eller gjennomtenkt delegering, eller klar kommunikasjon om hvorfor bestemt arbeid betyr. Lag noen ganger bruker prosess verktøy i håp at prosessen vil gjøre det relasjonelt og organisatorisk arbeid som er faktisk lederens jobb. Det vil ikke.

Hva det vil gjøre er reduser den omgivende usikkerhet som avslower de fleste lag. Spørsmålene av "hvem arbeider på hva," "er dette ferdig," og "hva burde jeg plukke opp neste" genererer enorme mengder lavverdi kommunikasjon i organisasjoner som ikke har et delt, synlig system. Kanban eliminerer de fleste av det støyen. Og for lag hvor det støyen er det dominerende problemet, forskjellen er signifikant.

Hvordan starte — uten en tre-dagers workshop

De beste Kanban implementeringer jeg har sett startet små og utviklet. De verste involverte en konsulent, en to-dagers offsite og en vakkert designet tavle at ingen brukte innen uke tre.

Start med laget ditt som det faktisk er, med arbeidet du faktisk har. Opprett tre kolonner: Backlog, In Progress, Done. Bruk trettien minutter med laget ditt å sette hver nåværende arbeid element på et kort. Bli enig om en regel: når du starter noe, går det på tavlen. Når det beveger seg, beveger du kortet. Gjør ingenting annet i to uker.

Etter to uker, se på tavlen sammen. Hvor ble ting stablet? Hva ble igjen i Backlog som alle sa var prioritet? Hva beveget seg raskere enn forventet? Hva fikk festet og hvorfor? Bruk hva du observerer for å finpusse kolonnene og legge til spesifisitet. Kanskje "In Progress" må dele inn i "In Progress" og "Venter på ekstern." Kanskje du trenger en kolonne som heter "In Review" fordi det trinnet kontinuerlig å få tapt. Tillate tavlen å utvikle seg som respons til hva ditt faktisk arbeid avsløre, ikke som respons til hva en metodologis bok sier det burde se ut som.

Det lengre spillet: strøm metrikker

En gang en Kanban system kjøres, det genererer data at de fleste lagene aldri bruker. Lede tid — totalt tid fra når en oppgave blir opprettet til når det er fullført — er det viktigste. Hvis din gjennomsnitt lede tid for en typisk oppgave er tolv dager, og du vil det å være fem, du nå har et tall å arbeide mot og en tavle som vil vise deg hvor de ekstra syv dagene går.

Sykeltid måler bare den aktive arbeids periode, ekskluderer tiden en oppgave sitter i backlog. Gjennomstrømning måler hvor mange elementer laget ditt fullfører per uke. Ingen av disse metrikene krever spesiell programvare hvis du er disiplinert om notere når kort blir opprettet og når de lukkes. Og sammen, de gir deg en mye mer ærlig bilde av din lags kapasitet enn noe estimat-basert planlegger kan.

De fleste små og medium lag komme aldri her. De bruker Kanban som et synlighet verktøy — som er verdifullt på sin egen — og ikke gå videre. Det er bra. Men hvis du finner deg selv vil gjøre forpliktelser til interessenter om når noe blir gjort, eller vil forstå hvorfor noe arbeid tar tre ganger så lenge som forventet, metrikene er der når du trenger dem.