Perché Kanban funziona — e come sapere se il tuo team è pronto

La maggior parte dei team adotta Kanban perché qualcuno ha letto un post sul blog. La domanda più intelligente è se i problemi che Kanban risolve sono davvero i problemi del tuo team.

C'è un momento che riconosce la maggior parte dei team, di solito intorno al momento in cui hanno più di otto o nove persone. Il lavoro viene fatto — le email vengono inviate, le feature vengono spedite, i clienti vengono gestiti — ma nessuno ha una chiara idea di cosa stia facendo tutti gli altri. I progetti si accumulano. Le cose vengono promesse e poi tranquillamente dimenticate. Passi venti minuti prima di ogni riunione cercando di capire dove si trova davvero un pezzo di lavoro. La risposta, di solito, è "da qualche parte."

Questo è il problema che Kanban è stato progettato per risolvere. Non il problema di impostare la strategia, o di assumere le persone giuste, o di costruire una cultura — ma il problema operativo specifico e logorante di sapere su cosa sta lavorando il tuo team e cosa sta ostacolando.

È uno strumento sorprendentemente umile per qualcosa che ha attirato così tanta attenzione. Kanban non sostiene di risolvere la tua organizzazione. Rende semplicemente il lavoro visibile. E risulta che la visibilità, applicata consistentemente, cambia un numero straordinario di cose a valle.

Da dove viene davvero Kanban

La parola è giapponese — significa "cartellone" o "cartellone pubblicitario" — e il sistema è stato sviluppato da Toyota alla fine degli anni '40 come un modo per gestire l'inventario nei loro impianti di produzione. L'idea era semplice: piuttosto che produrre parti su uno schema fisso, la fabbrica le avrebbe prodotte solo quando una stazione a valle segnalasse che ne aveva bisogno. Una carta fisica — il kanban — avrebbe viaggiato di nuovo giù per la linea come una richiesta. Niente è stato fatto speculativamente. Niente si è accumulato inutilmente.

L'intuizione che Toyota ha avuto, e che i team software hanno successivamente preso in prestito, è che la maggior parte dell'inefficienza in un sistema non proviene dalle persone che lavorano troppo lentamente, ma dal lavoro sbagliato che viene fatto al momento sbagliato. Troppe cose iniziate contemporaneamente. Colli di bottiglia che nessuno nota fino a quando non è troppo tardi. Lavoro che rimane finito in un posto mentre il passo successivo è sopraffatto altrove.

Gli sviluppatori di software, in particolare presso aziende come Microsoft all'inizio degli anni 2000, hanno iniziato ad adattare queste idee al lavoro della conoscenza. Le carte sono diventate compiti. Le stazioni di fabbrica sono diventate stadi in un flusso di lavoro. E il cartellone è diventato una scheda — fisica all'inizio, poi digitale — dove chiunque nel team poteva vedere, a colpo d'occhio, cosa era in corso, cosa era in attesa, e cosa era fatto.

Cosa mostra davvero una scheda Kanban

Una scheda Kanban di base ha tre colonne: Da fare, In corso, Fatto. Questo è sufficiente per molti piccoli team ed è un buon punto di partenza. Ma il valore reale emerge quando inizi a personalizzare quegli stadi per corrispondere a come il tuo lavoro effettivamente scorre — non come desideri che scorresse.

Un team di contenuti potrebbe usare: Idea, Brief, In bozza, In revisione, Programmato, Pubblicato. Un team software potrebbe spezzare "In corso" in colonne separate per sviluppo, revisione del codice, e QA. Un team di consulenza potrebbe tracciare Scoperta, Proposta, Attivo, In attesa del cliente, e Chiuso. Gli stadi dovrebbero riflettere i passaggi reali e i tempi di attesa reali — posti dove il lavoro cambia mano, o dove rimane finché qualcos'altro accade.

Noti la carta nella colonna di mezzo — il rapporto di controllo magazzino, dopo otto giorni, contrassegnato come bloccato. In un sistema senza una scheda, quel compito potrebbe rimanere per altre due settimane prima che qualcuno realizzi che non si sta muovendo. Qualcuno sta aspettando una terza parte. O è necessaria una decisione da un manager che non sa di essere l'ostacolo. La scheda rende l'ostruzione visibile. Questo è la maggior parte del lavoro.

La regola che lo fa funzionare: limiti WIP

Se c'è un concetto che separa i team che usano correttamente Kanban dai team che hanno solo una lista di cose da fare più carina, sono i limiti di work-in-progress — limiti WIP in breve. L'idea è che ogni colonna ha un numero massimo di elementi che possono trovarsi lì contemporaneamente. Quando una colonna è piena, non puoi aggiungere più lavoro finché qualcosa non si muove.

Questo sembra controintuitivo. Sicuramente poter mettere più compiti in corso significa che più sta siendo fatto? Non lo fa. Quello che accade effettivamente quando le persone lavorano su troppe cose simultaneamente è che tutto impiega più tempo. Il cambio di contesto è costoso. Il lavoro semi-finito crea sovraccarico di coordinamento. E quando dieci cose sono "in corso", è molto difficile dire quali stanno effettivamente progredendo e quali sono solo bloccate ma non marcate.

Un limite WIP di tre sulla colonna In corso significa che quando la quarta cosa arriva alla scrivania di qualcuno, qualcuno nel team deve prendere una decisione: quale compito esistente viene completato per primo? Forza la priorizzazione. Forza la conversazione. E tende a produrre il completamento più veloce dei singoli elementi, anche se il tasso di inizio di nuovi elementi rallenta.

Kanban versus Scrum: la domanda che i team fanno sempre

Se hai passato un po' di tempo intorno ai team software o al pensiero operativo moderno, probabilmente hai incontrato Scrum — il framework che organizza il lavoro in sprint fissi di due settimane, con sessioni di pianificazione, retrospettive, e ruoli definiti come Scrum Master e Product Owner. Molti team trattano Scrum e Kanban come metodologie concorrenti e sentono che devono scegliere. La distinzione è effettivamente più semplice di così.

Molti team — specialmente quelli che non sono pure team di ingegneria del software — trovano la cerimonia di Scrum pesante e la sua struttura sprint fissa difficile da applicare al lavoro operativo in corso. I team di marketing, i team di successo del cliente, i team di operations, e i founder che gestiscono tutto-in-una-volta raramente hanno lavoro che si adatta bene nei cicli di due settimane. Il modello di flusso continuo di Kanban tende a adattarsi loro meglio.

Detto questo, molti team combinano entrambi. Usano cicli di pianificazione in stile sprint per lo sviluppo del prodotto mentre eseguono una scheda Kanban per il lavoro operativo e di supporto che scorre indipendentemente da quale sprint sei. È un ibrido perfettamente ragionevole.

Le tre domande a cui la tua scheda dovrebbe rispondere in trenta secondi

Una scheda Kanban è più utile quando puoi guardarla e, senza parlare con nessuno, rispondere rapidamente a queste tre domande: Su cosa sta lavorando il team adesso? Dove il lavoro sta rimanendo bloccato? C'è qualcosa che dovrebbe essere fatto che non è stato iniziato?

Se non puoi rispondere a tutti e tre entro trenta secondi da quando guardi la scheda, probabilmente non viene mantenuta correttamente. La modalità di fallimento più comune è una scheda dove i compiti vengono creati ma mai spostati — diventa un cimitero di buone intenzioni piuttosto che una mappa viva del lavoro effettivo. Una scheda che non è corrente è peggio di nessuna scheda, perché crea un falso senso di visibilità.

La disciplina richiesta per mantenere una scheda è reale. I compiti hanno bisogno di muoversi quando il lavoro si muove. Gli elementi bloccati hanno bisogno di essere contrassegnati nel momento in cui si fermano, non due settimane dopo. Le carte hanno bisogno di avere proprietari chiari, e i proprietari hanno bisogno di aggiornare le loro carte. Nulla di questo richiede molto tempo — una pratica Kanban ben gestita potrebbe richiedere da cinque a dieci minuti per persona al giorno — ma richiede consistenza. I team che beneficiano di più da Kanban sono quelli che trattano la scheda come la fonte di verità, non come un esercizio di record-keeping supplementare.

Cosa Kanban non fa

Kanban non è uno strumento di strategia. Non ti aiuterà a capire cosa lavorare — solo ti aiuterà a gestire ciò su cui hai già deciso di lavorare. Se la tua organizzazione ha un problema di priorizzazione, o un problema di mandato poco chiaro, o un problema "iniziamo troppi progetti prima di finire quelli vecchi" radicato nel comportamento della leadership piuttosto che nel processo, una scheda Kanban rivelerà quei problemi ma non li risolverà.

Non è nemmeno un sostituto per una buona gestione. Una scheda non sostituisce i one-to-one, o la delegazione riflessiva, o la comunicazione chiara su perché certo lavoro imporsi. I team a volte adottano strumenti di processo sperando che il processo farà il lavoro relazionale e organizzativo che è effettivamente il compito del manager. Non lo farà.

Quello che farà è ridurre l'incertezza ambientale che rallenta la maggior parte dei team. Le domande di "chi sta lavorando su cosa," "è fatto," e "cosa dovrei prendere dopo" generano enormi quantità di comunicazione a basso valore nelle organizzazioni che non hanno un sistema condiviso e visibile. Kanban elimina la maggior parte di quel rumore. E per i team dove quel rumore è il problema dominante, la differenza è significativa.

Come iniziare — senza un workshop di tre giorni

Le migliori implementazioni Kanban che ho visto hanno iniziato in piccolo e si sono evolute. Le peggiori hanno comportato un consulente, un ritiro di due giorni, e una scheda splendidamente progettata che nessuno usava entro la settimana tre.

Inizia con il tuo team come effettivamente è, con il lavoro che effettivamente hai. Crea tre colonne: Backlog, In corso, Fatto. Passi trenta minuti con il tuo team mettendo ogni elemento di lavoro attuale su una carta. Concordate una regola: quando inizi qualcosa, va sulla scheda. Quando si muove, muovi la carta. Non fare nient'altro per due settimane.

Dopo due settimane, guarda insieme la scheda. Dove le cose si sono accumulate? Cosa è rimasto nel Backlog che tutti hanno detto fosse una priorità? Cosa si è mosso più veloce del previsto? Cosa si è bloccato e perché? Usa quello che osservi per perfezionare le colonne e aggiungere specificità. Forse "In corso" ha bisogno di dividersi in "In corso" e "In attesa di esterno." Forse hai bisogno di una colonna chiamata "In revisione" perché quel passaggio continua a perdersi. Lascia che la scheda si evolva in risposta a ciò che il tuo lavoro effettivo rivela, non in risposta a ciò che un libro di metodologia dice che dovrebbe assomigliare.

Il gioco più lungo: metriche di flusso

Una volta che un sistema Kanban è in esecuzione, genera dati che la maggior parte dei team non usa mai. Lead time — il tempo totale da quando un compito viene creato a quando viene completato — è il più importante. Se il tuo tempo di lead medio per un compito tipico è di dodici giorni, e vuoi che sia cinque, ora hai un numero su cui lavorare e una scheda che ti mostrerà dove vanno quei sette giorni extra.

Cycle time misura solo il periodo di lavoro attivo, escludendo il tempo che un compito rimane nel backlog. Throughput misura quanti elementi il tuo team completa per settimana. Nessuno di questi metriche richiede software speciale se sei disciplinato nel notare quando le carte vengono create e quando vengono chiuse. E insieme, ti danno un'immagine molto più onesta della capacità del tuo team di qualsiasi processo di pianificazione basato su stime.

La maggior parte dei team piccoli e di medie dimensioni non arriva mai qui. Usano Kanban come uno strumento di visibilità — che è prezioso di per sé — e non vanno oltre. Va bene. Ma se ti ritrovi a voler fare impegni agli stakeholder su quando qualcosa sarà fatto, o voler capire perché un certo lavoro impiega tre volte più a lungo del previsto, i metriche sono lì quando ne hai bisogno.