Breve panoramica del sistema Kanban

Cos’è Kanban?

All’interno dell’universo delle metodologie agili, spicca per popolarità e importanza il sistema Kanban ¹.
Kanban è un metodo lean ² che si sviluppa negli anni sulla scia del famoso Toyota Production System, introdotto in Toyota a partire dalla fine degli anni Quaranta dagli ingegneri Taiichi Ohno e Eiji Toyoda. Gli obiettivi del TPS, validi oltre i confini dell’industria automobilistica, erano la riduzione degli sprechi, degli errori di produzione, delle interruzioni e quindi massimizzare l’incorporazione di valore all’interno del prodotto per il cliente finale.

Nel mondo software, agli occhi di un osservatore esterno, un team che utilizza Kanban si mostrerà intento ad usare una board (fisica o virtuale) piena di cartellini colorati che vengono spostati da sinistra verso destra attraverso varie colonne. Si penserà subito agli artefatti SCRUM ³, ma per capire veramente il sistema (e come si è passati dalle automobili al software) occorre scendere più in profondità oltre l’apparenza.

In sintesi è possibile individuare sei regole fondamentali di Kanban:

1. errori e difetti devono essere individuati e bloccati prima del rilascio al cliente. Questo implica l’utilizzo di tutte le moderne metodologie di testing, continuous integration e deployment, etc. 
2. il team lavora per priorità, accettando richieste solamente fino a capacità e non oltre
3. il team produce le feature di provato valore per il cliente, e solo quelle, mantenendo il focus sul prodotto
4. le fasi di lavoro devono permettere un flusso continuo, senza colli di bottiglia, e il team amministra le risorse per ottenere questo scopo
5. il team organizza retrospettive e momenti di introspezione per analizzarsi e analizzare le fasi di lavoro allo scopo di applicare aggiustamenti progressivi al sistema
6. per garantire predicibilità nella qualità e nei livelli di produzione, nel tempo, il team razionalizza e standardizza sempre di più il processo (per esempio tramite documentazione, check-list, la definition of done, etc.)

L’Obiettivo

Sviluppando software, in confronto con la produzione di automobili all’origine di Kanban, ci ritroviamo subito ovviamente con delle differenze importanti. Forse la più importante di queste è che per noi programmatori è molto più facile accumulare lavoro non finito.
Il lavoro non finito per una catena di montaggio sarebbero automobili non completate, invendibili, molto tangibili e molto visibili, in attesa di essere completate.
Nel nostro progetto software, il lavoro non finito si nasconde in branch abbandonati, pull request in attesa di una integrazione, parti di codice temporaneamente disattivate in attesa di essere completate, e mille altri modi meno tangibili e meno visibili di una montagna accatastata di automobili semilavorate.

L’obiettivo fondamentale di Kanban è avere un flusso di produzione di valore, ininterrotto, che scorre verso l’utente finale, capace di reagire al cambiamento velocemente. L’accumulo di lavoro non completato (work-in-progress, wip) è l’antitesi di tutto questo. Ridurlo “è la cosa semplice che è difficile da fare”.

Perché?

L’aumento del work-in-progress è il padre di quasi tutte le inefficienze e i ritardi. Dietro di esso si nascondono interruzioni continue (che di per sé infliggono al team stress è calo della concentrazione, e quindi della produttività), rallentamenti nelle integrazioni, costi aggiuntivi nel mantenimento del codice.

Il lavoro incompleto è sintomo di una direzione poco chiara, di priorità poco chiare, di un ciclo di sviluppo confuso e schizofrenico. È un imbuto nero che risucchia risorse e blocca il flusso di valore prima che arrivi al cliente finale. Mille branch non integrati su master, contenenti feature complete al 99%, non valgono quanto invece vale un’unica feature rilasciata all’utente e funzionante ⁴.

Riuscire a ridurre il carico del work-in-progress equivale praticamente sempre ad un aumento immediato della produzione, in quantità e qualità, e soprattutto aiuta il team ad essere più concentrato e meno stressato.

Il Flusso di Valore

L’elemento più visibile di Kanban, come abbiamo anticipato, è la Kanban board. Questa, fisica o virtuale, ha il compito di rappresentare in modo trasparente e onesto il flusso di produzione di valore.

Questo flusso prende forma in task ⁵, tracciati spesso come card, che “entrano” nella board da sinistra, attraversano varie fasi di lavorazione, tracciate con colonne verticali, fino ad “uscire” a destra della board.
L’ingresso e l’uscita dalla board marcano i confini del nostro team. All’interno di questi confini il team è sovrano, si auto-organizza e rappresenta il proprio lavoro tramite la board stessa. Oltre questi confini risiedono gli elementi dell’organizzazione su cui il team non esercita alcuna sovranità.

Abbiamo detto anche che la board deve rappresentare questo flusso di lavoro. Questo significa che le colonne della board, attraverso cui passeranno le card da sinistra verso destra, devono rappresentare fedelmente le fasi di lavoro ⁶ che sono necessarie per completare i task.
L’approccio, se vogliamo, è bottom-up. Osserviamo con onestà il modo concreto, reale, attraverso cui il team costruisce valore e cominciamo con il rappresentare le fasi attuali del nostro processo. Teniamo a mente che il processo non è statico ed eterno ma soggetto a mutamenti, applicati volontariamente dal team per migliorarsi o anche imposti dalle circostanze esterne. La board verrà modificata di volta in volta per tenere traccia di questi cambiamenti.
Questo ci permette di rendere visibili le inefficienze del nostro flusso. Il secondo passo fondamentale è, una volta rese visibili le inefficienze, risolverle nel tempo facendo periodicamente introspezione (kaizen).

Pull vs Push

Solitamente tutti i progetti finiscono per avere una board di qualche tipo che traccia le feature richieste e lo stato di lavorazione. Quello che è altrettanto comune è che queste board finiscono inevitabilmente per lavorare in push.
Ovvero il project manager, o il cliente, spingono all’interno della board richieste, scadenze, aspettative, e il team fatica nel tenere il passo. Il sintomo grafico di questo metodo di lavoro è vedere le card sulla board disporsi in senso decrescente. Nel backlog saranno presenti innumerevoli card, nelle colonne working saranno presenti meno card, ma comunque tantissime, e così via a scemare, fino ad avere molto poco in dirittura di arrivo. Il sistema sta funzionando su pressione dall’esterno, da sinistra verso destra.
Questo funzionamento è intrinsecamente inefficiente e massimizza il work-in-progress, nostro nemico giurato.

In modo completamente opposto, un sistema che lavora in pull opera da destra verso sinistra. Il team consuma per prime le card che sono più vicine ad uscire dalla board, più vicine ad essere completate. La priorità è svuotare il sistema dal lavoro in corso, da destra verso sinistra. Nuovo lavoro può entrare nel sistema solo se è stato completato un task, e quindi delle card sono uscite dal sistema (valore è stato rilasciato al cliente), e si è liberato spazio per prendere in carico altre card.

Il sistema in pull, appunto, tira lavoro all’interno del team per essere sempre a capienza, e non accetta niente di più.

Wip Limit

Un metodo molto comune e consigliato per individuare i colli di bottiglia e assicurarsi di lavorare in pull è applicare un wip limit alle fasi di lavorazione.

Questo significa che il team rifiuta di accettare altre card in una fase di lavoro (una colonna della nostra Kanban board) già piena a regime senza prima aver smaltito il lavoro in corso. Inoltre ci permette di osservare meglio il flusso e capire cosa sta succedendo.

Per esempio se una colonna si ritrova ad essere molto spesso piena, probabilmente quello è un collo di bottiglia del processo e merita una riflessione del team. Il limite ci impedisce di trascurare il problema, accumulando polvere sotto al tappeto.

Quanto dovrebbe essere il limite per ogni colonna? Dipende dal numero di persone nel team, dalla natura della fase di lavorazione e mille altre fattori. Per semplicità possiamo partire da un limite pari al numero di membri del team coinvolti in quella fase, e poi andare a spostare l’asticella basandosi sull’esperienza ⁷. L’obiettivo sarà quello di avere un flusso costante, attraverso tutte le fasi, che minimizzi il tempo di lavorazione di una singola card (lead time).

Stime vs Proiezioni

Stimare un lavoro prima di averlo fatto un compito ingrato che ogni programmatore in questa industria si è trovato ad affrontare almeno una volta. Tutti vogliono sapere quanto tempo occorre per avere rilasciata la loro feature e tutti vogliono essere confortati che la scadenza imposta dal reparto marketing o dal commerciale sarà rispettata.

Purtroppo la magia non esiste e quindi queste aspettative  potrebbero essere deluse. Nella realtà il programmatore, anche nelle migliori condizioni, possiede informazioni molto parziali e non può prevedere il futuro. Imprevisti di ogni genere sorgeranno a minare la qualità della stima.
Sovrastimare aiuterà a risolvere il problema solo in apparenza. Si produrrà infatti il paradosso per cui una stima risulterà tanto più difficile da sforare tanto più sarà imprecisa e inutile.

In un processo agile dobbiamo dunque eliminare le stime e rinunciare a qualunque misurazione temporale? In parte sì, e in parte no.
Ciò che possiamo fare, superate le fasi iniziali di assestamento del team, è osservare i risultati trascorsi del sistema e fare proiezioni. Kanban spinge il team per avere un flusso di lavoro costante, predicibile, visibile e misurabile. Questo ci dovrebbe permettere di fare proiezioni nel futuro con un buon grado di attendibilità.

Per esempio, se il team ha mantenuto un ritmo di circa 10 card ⁸ consumate in media alla settimana negli scorsi mesi, questo ci permette di avere un’idea di cosa succederà nella prossima settimana proiettando questi numeri nel futuro.

È difficile fare meglio di così.

I Risultati

La progressiva e corretta applicazione della metodologia Kanban dovrebbe produrre in tempi relativamente brevi alcuni miglioramenti tangibili:

• dovrebbe diminuire il quantitativo di card in sospeso in lavorazione, ovvero il nostro work-in-progress
• dovrebbe diminuire il tempo totale impiegato da un task per attraversare l’intera board e raggiungere il prodotto (e quindi il cliente), cioè il lead time
• dovrebbe di conseguenza aumentare il valore rilasciato al cliente
• dovrebbe aumentare la frequenza di questi rilasci
• la predicibilità dei rilasci e dello sviluppo delle feature dovrebbe di conseguenza stabilizzarsi

Per ottenere questi risultati sarà però necessario prestare attenzione alla reale applicazione della sostanza del sistema, al di là della forma.
Possiamo chiamare la nostra board “Kanban board”, possiamo vantarci di lavorare in modo agile, ma se avremo di fatto ancora una board in push, un team alla rincorsa di feature e scadenze imposte dall’alto con priorità confuse, fasi di lavoro non ufficiali non presenti sulla board, wip limit quotidianamente ignorati e una colonna working con duemila card, nessun cambiamento vero è stato purtroppo fatto.

Se invece, con un po’ di coraggio, si vuole veramente cominciare a muovere dei passi verso metodologie agili, allora Kanban è sicuramente un buon candidato e solitamente si conseguono risultati.

1. Una curiosità: la parola Kanban significa cartellino, signal card in Inglese. L’utilizzo di questa parola deriva dall’uso massivo di cartellini di segnalazione in Toyota, utilizzati per manifestare e regolare il flusso di lavoro, il riordino dei pezzi nella catena di montaggio, e così via. ↩
2. Il mondo del software prende a prestito questo concetto dall’industria manifatturiera. La produzione lean si basa su cinque principi che in sintesi sono: massimizzare il valore del prodotto; identificare il flusso di creazione di questo valore; assicurarsi che questo flusso non venga mai interrotto; la direzione del flusso è in pull, guidata quindi dalla domanda; e infine fare introspezione del processo per perseguire continui miglioramenti verso la perfezione (kaizen). ↩
3. In Italia spesso frainteso come sinonimo della metodologia agile, è il sistema che ci ha dato ruoli professionali come il Product Owner, lo SCRUM Master, e che ha popolarizzato l’idea di lavorare per sprint temporalmente definiti, aperti da una fase di pianificazione e chiusi da una demo con il cliente. Anche qui le cose sarebbero più complicate di quello che sembrano, ma rimandiamo per ora questa conversazione. ↩
4. Vale la pena menzionare la difficoltà che spesso si incontra nell’accettare (e nel far accettare) l’esistenza di un apparente paradosso. Cioè che il lavoro speso su task poco importanti, o sull’aprire nuovi task senza rilasciare i precedenti, anche se apparentemente produttivo perché la quantità di codice scritto aumenta, in realtà non lo è. La produttività e l’efficienza si misurano sulla base del valore rilasciato all’utente finale, e non sulla quantità di linee di codice aggiunte. “Source code is a liability, not an asset”, Software Engineering at Google. ↩
5. Task o user story? Evitiamo di entrare in dettaglio su questo. Il punto fondamentale è che gli elementi lavorati devono rappresentare valore per l’utente finale, o essere direttamente connessi ad esso. Il suggerimento fortissimo è che dovrebbero avere una dimensione temporale gestibile (per esempio un paio di giorni al massimo) e il team dovrebbe tendere a spezzare il lavoro in task di dimensione simile. ↩
6. È comune sulle Kanban board vedere le colonne divise in sotto-colonne, con vari criteri, ma l’elemento importante è sempre quello di tracciare le fasi di lavoro, per visualizzare e migliorare il flow del valore. ↩
7. Si possono trovare molti modi diversi per calcolare il WIP limit; vari metodi di calcolo che non sono elencati qui per ragioni di brevità. L’aspetto importante però rimane lo stesso: l’obiettivo è eliminare l’accumulazione di lavoro in corso non finito seguendo il mantra stop starting start finishing. ↩
8. Un altro modo che vale la pena menzionare per misurare la velocity del team è usare story point in una scala di fibonacci. Ogni card può essere stimata in punti e saranno possibili proiezioni basate sul valore medio di punti realizzati. Tuttavia lo scopo del team dovrebbe essere la realizzazione di card di dimensione e difficoltà omogenea, andando quindi a ridurre il senso dell’usare una scala di punti. ↩