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 la maggior parte dei team riconosce, di solito quando superano le otto o nove persone. Il lavoro viene svolto — le email partono, le feature vengono rilasciate, i clienti vengono seguiti — ma nessuno ha un'idea chiara di cosa stiano facendo tutti gli altri. I progetti si accumulano. Le cose vengono promesse e poi dimenticate in silenzio. Prima di ogni riunione passi venti minuti a capire a che punto sia davvero un lavoro. La risposta, di solito, è "da qualche parte."

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

È uno strumento sorprendentemente modesto, per qualcosa che ha attirato così tanta attenzione. Kanban non pretende di risolvere i problemi della tua organizzazione. Rende semplicemente il lavoro visibile. E si scopre che la visibilità, applicata con costanza, cambia un numero notevole di cose a valle.

Da dove viene davvero Kanban

La parola è giapponese — significa "insegna" o "cartello" — e il sistema fu sviluppato da Toyota alla fine degli anni Quaranta per gestire le scorte nei suoi stabilimenti produttivi. L'idea era semplice: invece di produrre i componenti secondo un calendario fisso, la fabbrica li produceva solo quando una postazione a valle segnalava di averne bisogno. Un cartellino fisico — il kanban — risaliva la linea come richiesta. Nulla veniva prodotto in via speculativa. Nulla si accumulava inutilmente.

L'intuizione di Toyota, che i team software hanno poi ripreso, è che la maggior parte delle inefficienze di un sistema non deriva dal fatto che le persone lavorino troppo lentamente, ma dal fatto che si fa il lavoro sbagliato al momento sbagliato. Troppe cose avviate contemporaneamente. Colli di bottiglia che nessuno nota finché non è troppo tardi. Lavoro finito che resta fermo in un punto mentre la fase successiva è sommersa altrove.

Gli sviluppatori software, in particolare in aziende come Microsoft all'inizio degli anni Duemila, iniziarono ad adattare queste idee al lavoro di conoscenza. I cartellini diventarono attività. Le postazioni della fabbrica diventarono fasi di un flusso di lavoro. E l'insegna diventò una bacheca — fisica all'inizio, poi digitale — su cui chiunque nel team poteva vedere, a colpo d'occhio, cosa era in corso, cosa era in attesa e cosa era completato.

Cosa mostra davvero una bacheca Kanban

Una bacheca Kanban di base ha tre colonne: Da fare, In corso, Fatto. Per molti piccoli team bastano ed è un buon punto di partenza. Ma il valore reale emerge quando inizi a personalizzare queste fasi in modo che corrispondano a come il tuo lavoro scorre davvero — non a come vorresti che scorresse.

Un team di contenuti potrebbe usare: Idea, Brief, In bozza, In revisione, Programmato, Pubblicato. Un team software potrebbe suddividere "In corso" in colonne separate per sviluppo, code review e QA. Un team di consulenza potrebbe monitorare Discovery, Proposta, Attivo, In attesa del cliente e Chiuso. Le fasi dovrebbero riflettere passaggi di consegne e tempi di attesa reali — i punti in cui il lavoro passa di mano o resta fermo finché non succede qualcos'altro.

Nota la card nella colonna centrale — il report di audit del magazzino, fermo da otto giorni, contrassegnato come bloccato. In un sistema senza bacheca, quell'attività potrebbe restare lì altre due settimane prima che qualcuno si accorga che non si muove. Qualcuno sta aspettando una terza parte. Oppure serve una decisione da un manager che non sa di essere lui il collo di bottiglia. La bacheca rende visibile il blocco. Ed è questo a fare la maggior parte del lavoro.

La regola che lo fa funzionare: i limiti WIP

Se c'è un concetto che distingue i team che usano Kanban nel modo giusto da quelli che hanno solo una to-do list più bella, è il limite al lavoro in corso (work in progress, o WIP). L'idea è che ogni colonna possa contenere al massimo un certo numero di elementi alla volta. Quando una colonna è piena, non puoi aggiungere altro lavoro finché qualcosa non esce.

Sembra controintuitivo. Poter avviare più attività non significa forse farne di più? No. Quello che succede davvero quando le persone lavorano su troppe cose contemporaneamente è che tutto richiede più tempo. Il cambio di contesto ha un costo elevato. Il lavoro lasciato a metà genera un sovraccarico di coordinamento. E quando dieci cose sono "in corso", è molto difficile capire quali si stiano davvero muovendo e quali siano semplicemente ferme senza che nessuno lo segnali.

Un limite WIP di tre sulla colonna In corso significa che, quando la quarta attività arriva sulla scrivania di qualcuno, il team deve prendere una decisione: quale delle attività esistenti va completata per prima? Costringe a stabilire le priorità. Costringe a confrontarsi. E tende a portare a un completamento più rapido dei singoli elementi, anche se il ritmo con cui si avviano nuovi elementi rallenta.

Kanban o Scrum: la domanda che i team si pongono sempre

Se hai avuto a che fare con team software o con il pensiero operativo moderno, probabilmente hai incontrato Scrum — il framework che organizza il lavoro in sprint fissi di due settimane, con riunioni di pianificazione, retrospettive e ruoli definiti come Scrum Master e Product Owner. Molti team considerano Scrum e Kanban metodologie concorrenti e sentono di dover scegliere. In realtà la distinzione è più semplice.

Molti team — soprattutto quelli che non sono puri team di ingegneria del software — trovano le cerimonie di Scrum pesanti e la sua struttura a sprint fissi difficile da applicare al lavoro operativo continuativo. I team marketing, di customer success e di operations, e i founder che gestiscono tutto contemporaneamente, raramente hanno un lavoro che si inserisca bene in cicli di due settimane. Il modello a flusso continuo di Kanban tende a servirli meglio.

Detto questo, molti team li combinano. Usano cicli di pianificazione in stile sprint per lo sviluppo del prodotto e tengono una bacheca Kanban per il lavoro operativo e di supporto, che arriva a prescindere dallo sprint in corso. È un ibrido del tutto ragionevole.

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

Una bacheca Kanban è più utile quando puoi guardarla e, senza parlare con nessuno, rispondere rapidamente a queste tre domande: su cosa sta lavorando il team in questo momento? Dove si sta bloccando il lavoro? C'è qualcosa che andrebbe fatto e non è ancora stato avviato?

Se non riesci a rispondere a tutte e tre entro trenta secondi dall'occhiata alla bacheca, probabilmente non viene aggiornata come si deve. Il modo più comune in cui fallisce è una bacheca in cui le attività vengono create ma mai spostate — diventa un cimitero di buone intenzioni anziché una mappa viva del lavoro reale. Una bacheca non aggiornata è peggio di nessuna bacheca, perché dà una falsa sensazione di visibilità.

La disciplina necessaria per mantenere una bacheca è concreta. Le attività devono muoversi quando si muove il lavoro. Gli elementi bloccati vanno segnalati nel momento in cui si fermano, non due settimane dopo. Le card devono avere responsabili chiari, e i responsabili devono aggiornare le proprie card. Niente di tutto questo richiede molto tempo — una pratica Kanban ben condotta può richiedere da cinque a dieci minuti al giorno per persona — ma richiede costanza. I team che traggono più beneficio da Kanban sono quelli che trattano la bacheca come fonte di verità, non come un esercizio accessorio di registrazione.

Cosa Kanban non fa

Kanban non è uno strumento di strategia. Non ti aiuterà a capire su cosa lavorare — ti aiuta solo a gestire ciò su cui hai già deciso di lavorare. Se la tua organizzazione ha un problema di definizione delle priorità, o di mandato poco chiaro, o un problema del tipo "iniziamo troppi progetti prima di finire i vecchi" che affonda le radici nel comportamento della leadership più che nel processo, una bacheca Kanban metterà in luce quei problemi ma non li risolverà.

Non è nemmeno un sostituto di una buona gestione. Una bacheca non sostituisce i one-to-one, né una delega ponderata, né una comunicazione chiara sul perché certe attività contino. A volte i team adottano strumenti di processo sperando che il processo svolga il lavoro relazionale e organizzativo che in realtà spetta al manager. Non lo farà.

Quello che farà è ridurre l'incertezza di fondo che rallenta la maggior parte dei team. Domande come "chi sta lavorando a cosa", "questo è finito?" e "cosa prendo in carico adesso?" generano enormi quantità di comunicazione di scarso valore nelle organizzazioni prive di un sistema condiviso e visibile. Kanban elimina gran parte di quel rumore. E per i team in cui quel rumore è il problema dominante, la differenza è significativa.

Come iniziare — senza un workshop di tre giorni

Le migliori implementazioni di Kanban che ho visto sono partite in piccolo e si sono evolute. Le peggiori hanno coinvolto un consulente, un offsite di due giorni e una bacheca splendidamente progettata che alla terza settimana nessuno usava più.

Parti dal tuo team così com'è e dal lavoro che hai davvero. Crea tre colonne: Backlog, In corso, Fatto. Dedica trenta minuti insieme al team a mettere ogni attività attuale su una card. Concorda una sola regola: quando inizi qualcosa, finisce sulla bacheca. Quando avanza, sposti la card. Non fare nient'altro per due settimane.

Dopo due settimane, guarda la bacheca insieme al team. Dove si sono accumulate le cose? Cosa è rimasto nel Backlog pur essendo, secondo tutti, una priorità? Cosa si è mosso più in fretta del previsto? Cosa si è bloccato e perché? Usa ciò che osservi per affinare le colonne e aggiungere precisione. Forse "In corso" va divisa in "In corso" e "In attesa di terzi". Forse serve una colonna "In revisione" perché quel passaggio continua a perdersi. Lascia che la bacheca evolva in base a ciò che rivela il tuo lavoro reale, non a come dovrebbe apparire secondo un manuale di metodologia.

Uno sguardo più lungo: le metriche di flusso

Una volta che un sistema Kanban è attivo, genera dati che la maggior parte dei team non usa mai. Il lead time — il tempo totale che passa da quando un'attività viene creata a quando viene completata — è il più importante. Se il lead time medio di un'attività tipica è di dodici giorni e vuoi portarlo a cinque, hai un numero su cui lavorare e una bacheca che ti mostrerà dove finiscono quei sette giorni in più.

Il cycle time misura solo il periodo di lavoro attivo, escludendo il tempo che un'attività passa nel backlog. Il throughput misura quanti elementi il tuo team completa a settimana. Nessuna di queste metriche richiede software speciale, se sei disciplinato nell'annotare quando le card vengono create e quando vengono chiuse. E insieme ti restituiscono un quadro molto più onesto della capacità del tuo team di quanto possa fare qualsiasi processo di pianificazione basato su stime.

La maggior parte dei team piccoli e medi non arriva mai a questo punto. Usano Kanban come strumento di visibilità — che di per sé ha valore — e non vanno oltre. Va bene così. Ma se ti ritrovi a voler assumere impegni con gli stakeholder su quando qualcosa sarà pronto, o a voler capire perché certo lavoro richiede tre volte più del previsto, le metriche sono lì quando ti servono.