Kanban senza limiti è solo una lista con le colonne

L’adozione di un metodo agile in un team che non ce l’ha segue quasi sempre lo stesso ordine. Prima arriva la board, perché è la parte visibile e si allestisce in mezz’ora. Poi le riunioni ricorrenti, perché si mettono in calendario. Per ultimo, se arriva, il vincolo — che è l’unica parte che cambia davvero come si lavora, ed è anche la sola che costa qualcosa.

Il risultato intermedio è una board con cinque colonne dove ogni persona ha tre schede in “in corso”, e una riunione quotidiana in cui ciascuno racconta a turno di essere impegnato. Tutti gli oggetti del metodo sono al loro posto. Il tempo che passa fra “abbiamo deciso di farlo” e “è in produzione” non è cambiato di un giorno.

Una board senza limiti è una lista con le colonne

Il limite al lavoro in corso è la regola che dice: in questa colonna non possono esserci più di N schede. Sembra una restrizione burocratica ed è invece il motore di tutto il resto.

Senza limite, la board registra ciò che accade. Con il limite, la board comincia a impedire qualcosa: quando la colonna è piena non puoi tirare dentro un’altra attività, e ti trovi davanti a una scelta che prima potevi rimandare. O finisci qualcosa, o vai ad aiutare chi è bloccato, o dichiari che c’è un ostacolo che non dipende da te.

Sono le tre cose che un team che funziona fa in continuazione, e sono esattamente le tre cose che, senza vincolo, nessuno fa — perché aprire una scheda nuova è più comodo che chiudere quella vecchia.

Iniziare non è consegnare

Il lavoro in corso non produce niente finché non arriva in fondo. Otto attività avviate e ferme all’ottanta per cento non sono “quasi otto attività”: sono zero, con in più il costo di tenere in testa otto contesti diversi.

È un conto che sulla carta convince tutti e nella pratica quasi nessuno, perché il lavoro iniziato dà una sensazione di avanzamento che il lavoro non iniziato non dà. Una board con molte schede in movimento sembra un team produttivo. Spesso è un team che sta pagando l’interesse su otto debiti di attenzione.

Ridurre il numero di cose aperte accorcia il tempo di consegna senza che nessuno lavori più in fretta. Non è motivazione, è code di attesa: meno roba c’è nel sistema, meno ogni singolo pezzo aspetta.

Il limite serve a far emergere gli ostacoli, non a misurare le persone

Qui è dove il metodo viene frainteso più spesso. Un limite basso non è un modo per verificare che tutti siano occupati: è un modo per rendere visibile, in fretta, ciò che impedisce di finire.

Quando la colonna è piena e nessuno può tirare, la conversazione si sposta per forza dall’attività all’impedimento. Serve una revisione che non arriva, manca un ambiente, ci vuole una decisione che nessuno ha preso. Sono cose che esistevano anche prima; semplicemente restavano invisibili, perché ognuno le aggirava aprendo qualcos’altro.

Rimuovere quegli ostacoli è il lavoro di chi conduce il team, e il vincolo è ciò che lo mette in cima alla lista invece che in fondo.

Quando il processo non regge, spesso il problema è l’architettura

Questa è la parte che nel racconto abituale del metodo agile manca quasi sempre, ed è quella che mi interessa di più.

Se due persone non riescono a lavorare in parallelo su due attività distinte senza pestarsi i piedi, non è un problema di coordinamento: è accoppiamento. Se ogni modifica richiede di toccare lo stesso modulo, se una consegna resta ferma perché ne aspetta un’altra che tocca gli stessi file, se il tempo di integrazione supera il tempo di sviluppo — nessuna cerimonia lo sistema, perché il problema non è nel processo.

Il limite al lavoro in corso è utile anche per questo: fa emergere l’attrito strutturale sotto forma di code, dove si vede. Un team che non riesce a tenere tre cose in parallelo di solito sta lavorando su un sistema che in parallelo non si lascia toccare, e la risposta giusta non è una riunione in più ma un confine disegnato meglio.

È il motivo per cui non tratto la conduzione del team e la progettazione del sistema come due argomenti separati. Sono la stessa cosa vista da due lati: la forma dell’architettura decide quante cose il team può fare davvero insieme.

Cosa guardo

Poche misure, e nessuna che riguardi le persone singolarmente.

Il tempo di attraversamento — da quando un’attività entra in lavorazione a quando è in produzione — dice più di qualunque stima, perché è un fatto e non una previsione. La sua variabilità dice ancora di più: un team che consegna in tempi imprevedibili ha un problema che la media nasconde.

E il numero di attività ferme in attesa di qualcun altro, che è la misura diretta di quanto il team dipende da cose fuori dal suo controllo. Se cresce, non serve chiedere più impegno: serve andare a togliere quella dipendenza.

Nessuna di queste misure si presta a essere usata per giudicare una persona, ed è un requisito, non un effetto collaterale. Una metrica di flusso che diventa una pagella smette immediatamente di dire la verità, perché tutti imparano a farla sembrare buona.

In pratica

Se dovessi indicare l’ordine con cui partire, invertirei quello abituale: prima il limite, poi la board, e le riunioni solo quando servono a qualcosa che non si capisce guardando il lavoro.

Un vincolo scomodo su un team senza board produce comunque conversazioni utili. Una board perfetta senza vincoli produce un archivio ordinato di lavoro non finito.