Una riflessione relativa a Kanban: possiamo considerarlo una metodologia agile, oppure è concettualmente sbagliato? In questo articolo analizzeremo tale questione: nel mondo degli agilisti è un tema dibattuto, anche ferocemente. Ma quali conseguenze pratiche può avere sul modo in cui gestiamo il processo di sviluppo del software?

È solo questione di parole?

In questo articolo affronteremo una questione solo apparentemente “nominale”. Kanban è una metodologia agile oppure no? Nell’ambito di coloro che adottano metodologie agili il dibattito è aperto e a volte anche feroce, poiche’, almeno da parte di alcuni importanti esponenti del movimento agile, si afferma chiaramente che Kanban non può essere considerato una metodologia agile, almeno in senso “ortodosso”.

Ciò non toglie che l’uso delle lavagne Kanban sia estremamente diffuso e, soprattutto, risulti estremamente utile a molti gruppi di lavoro, i cui membri non stanno tanto a porsi il dilemma “filosofico” sulla vera o presunta agilità di Kanban, ma si limitano a sfruttare tali strumenti per gli scopi della loro attività di sviluppo.

In pratica, semplificando al massimo, da un lato abbiamo gruppi di sviluppo e intere aziende che utilizzano le Kanban board con successo, dall’altro, alcune affermazioni che arrivano a definire Kanban come una metodologia waterfall. Vedremo di seguito i termini della questione, lasciando ai nostri lettori la possibilità di farsi un’idea motivata.

Maiuscole e minuscole

Per impostare il discorso, eliminando una serie di malintesi, cominciamo con una rapida definizione del termine kanban, facendo oltretutto una distinzione tra la parola scritta con la lettera iniziale minuscola (kanban) e quella scritta con l’iniziale maiuscola (Kanban). Il termine è il medesimo, di origine giapponese, e significa letteralmente “cartellino”; ma mentre con kanban ci si riferisce specificamente a un particolare cartellino utilizzato come segnalazione visuale nella produzione industriale basata sul metodo Toyota, la parola Kanban (con l’iniziale maiuscola) viene utilizzata per indicare una particolare metodologia di sviluppo del software basata sull’uso di Kanban board, cioè delle lavagne in grado di visualizzare il flusso di lavoro del processo con l’utilizzo di foglietti adesivi post-it, ma che non si limita a questo: si tratta infatti di una serie di principi e pratiche che vanno ben oltre l’utilizzo delle lavagne e dei post-it e che si basano sul metodo di produzione lean.

Figura 1 – Un esempio di kanban, il cartellino usato come segnalazione visuale nel sistema di produzione industriale messo a punto dalla Toyota.

Logica pull

Alla base dell’uso del kanban, cioè di un cartellino per segnalare la necessità di determinate materie o oggetti indispensabili alla linea produttiva per andare avanti con il lavoro, sta una logica organizzativa del processo di lavoro che viene definita di tipo pull, e che, storicamente, è stata sviluppata e messa a punto nel secondo dopoguerra in Giappone (il cosiddetto Toyota production system). La logica pull si contrappone a quella push, tipica della catena di montaggio delle industrie occidentali, e statunitensi in particolare (il metodo di produzione fordista).

Nella logica pull, avviene un “trascinamento” per cui l’attività a valle trascina quella a monte: si parte dai fabbisogni, che trascinano alla produzione di un determinato bene, in una specifica quantità, con precise caratteristiche. In questo modo, si riesce a migliorare la rapidità di consegna, e a rispondere in maniera adeguata alle variazioni nella domanda, purche’ si istituisca una ben precisa catena di fornitura logistica di tipo “just in time”.

Just in time

Per just in time (JIT) si intende una gestione delle scorte “a ripristino” in cui si alleggeriscono al massimo le quantità di materie prime e semilavorati presenti in magazzino, e si cerca invece di acquisire e avere a disposizione tali materiali solo “appena in tempo” rispetto a quando serviranno effettivamente sulla linea di produzione in fabbrica. Sostanzialmente: si ha a disposizione quel che serve quando serve, senza farne enormi scorte preventive, costose e potenzialmente destinate allo spreco nel caso la domanda cambi e certe materie e semilavorati non servano più. Nella produzione industriale ispirata al metodo Toyota, il kanban, il cartellino si segnalazione visuale, è un segnale identificativo che serve per rifornire di materiale una determinata stazione di lavoro.

In una stazione di lavoro si può procedere con la produzione solo se tutto quel che serve è disponibile, e il segnale identificativo consente appunto di gestire il flusso di materiali dalla stazione a monte a quella a valle. Uno degli aspetti più interessanti del sistema di flusso basato su questi cartellini kanban è che esso responsabilizza l’operaio e riconosce al lavoratore una conoscenza e una competenza specifica che cresce con l’esperienza e la riflessione e che si estrinseca nell’ambito della sua “postazione” e del suo team di lavoro. La funzione che ha, per quanto ripetitiva, richiede una notevole consapevolezza, un “saper fare” tutt’altro che superficiale e che non può essere ridotto a gesto meccanico.

Lean manufacturing

Dall’analisi del sistema Toyota, gli autori del libro “La macchina che ha cambiato il mondo” [1] hanno coniato il termine “produzione snella”. Il lean manufacturing è appunto l’applicazione di tali principi alla produzione industriale. Molti principi lean sono entrati oramai a far parte del bagaglio culturale di chi gestisce i processi di sviluppo software, tant’è che in certi casi, almeno fra coloro che non approfondiscono certe tematiche, i concetti di lean e agile finiscono, erroneamente, per confondersi.

Dalla fabbrica al software

I principi lean hanno, come detto, trovato ottimo terreno di sviluppo nel mondo della gestione dei processi di sviluppo software, tanto che l’autore David Anderson ha scritto un libro dedicato proprio a proporre il metodo nell’ambito delle aziende tecnologiche [2]: da questa esperienza si è diffuso l’uso della parola Kanban in ambito IT.

In questo testo viene messo in luce come sia possibile ispirarsi a certi principi e certe pratiche della “produzione snella” anche per quel che riguarda la produzione di software. In particolare, Kanban consente di

• visualizzare, misurare e gestire il flusso di lavoro;
• limitare i lavori lasciati a metà, concentrandosi sul portare a conclusione le varie attività;
• rendere esplicite a tutti le “regole” alla base del processo che si segue;
• individuare la possibilità di “aggiustare il tiro” continuamente, in un’ottica di miglioramento continuo.

Ma qui nascono anche i primi intoppi: possiamo considerare Kanban una metodologia agile? E, se sì o no, su quali basi?

Definire che cosa è agile

Per stabilire se Kanban sia propriamente agile o no, occorre anzitutto mettersi d’accordo su quel che consideriamo, appunto, “agile”. E occorre subito dirimere un’altra possibile interpretazione errata: per Kanban si intende tutto l’approccio ispirato alla “produzione snella” e non la sola Kanban board, che ne rappresenta lo strumento operativo, utilissimo e potente, ma che è solo un tool e non costituisce invece l’insieme di principi e pratiche che David Anderson ha descritto nel suo libro.

Figura 2 – Questa lavagna Kanban, invece, è quella usata nello sviluppo del software. Ma è solo uno strumento, per quanto importante e potente.

Una definizione “ampia” di Agile potrebbe essere basata su considerazioni quali:

• la reale interazione tra azienda e clienti per decidere le priorità su cui lavorare nell’immediato;
• la velocità con cui il lavoro può essere condotto a termine, una volta assunto l’impegno a farlo;
• la frequenza con cui ogni nuovo “pezzo” completato può essere consegnato e reso operativo.

Si tratta, un po’ alla larga, dei concetti di gestione del “ripristino” delle scorte, di “tempo di attraversamento” o “di risposta” (lead time), e di consegna, presenti nella produzione snella, ma che sono tipici anche delle metodologie agili “ortodosse” come Scrum.

Ma ci sono anche definizioni più stingenti.

Kanban vs. manifesto agile

Se ci atteniamo a quanto riportato nel manifesto per lo sviluppo agile di software [3], però, la situazione si fa più complessa: a voler essere pignoli, Kanban può essere considerato perfettamente aderente all’Agile Manifesto solo per quanto riguarda la voce “rispondere al cambiamento più che seguire un piano”.

Ma non è che gli altri tre principi del manifesto siano poi così lontani da Kanban, specie se si vanno a guardare le declinazioni più ampie di tali principi, i cosiddetti “Dodici principi del software agile” [4].

Quello che, almeno apparentemente, rende Kanban lontano dalle pratiche agili strettamente definite è la mancanza di consegne fisse a tempi prestabiliti (time-boxed), vale a dire le cosiddette “iterazioni”, che invece sono presenti in tutte le pratiche che a quel manifesto si sono ispirate.

Kanban in azione

L’introduzione di Kanban, a partire dagli anni 2007-2008, ha avuto una ragione molto “pratica”, almeno stando a quanto dichiarato da David Anderson: si trattava di trovare una metodologia che potesse essere introdotta nelle aziende, anche complesse, con un impatto minore rispetto a quello che avrebbe richiesto l’adozione su larga scala di metodologie Agile tout-court. Questo ha anche creato degli attriti, poiche’ in certi casi Kanban è stato visto come una alternativa in contrapposizione all’Agile: forse anche da questo è derivato un atteggiamento “sprezzante” da parte di alcuni Agilisti ortodossi (“se non è Agile… allora deve essere Waterfall”).

L’altro atteggiamento è stato quello di vedere in Kanban solo lo strumento: la “lavagna con i post-it”. È chiaramente uno strumento potente, utilissimo, che può essere incorporato in altre metodologie propriamente agili, ma è solo una visione parziale, come già detto: all’inizio, per esempio, le primissime implementazioni di Kanban… addirittura non prevedevano ancora l’uso della Kanban board!

È solo un nome?

In definitiva, con un approccio molto “laico” al problema… ma a chi importa veramente stabilire se Kanban possa essere definito agile o meno? Non è forse più importante capire se i suoi principi e le sue pratiche possano avere un impatto positivo sulle attività produttive di una azienda? Non è meglio concentrarsi sul comprendere se e come possa migliorare la soddisfazione dei clienti e i risultati economici delle organizzazioni che la adottano?

È anche chiaro, a questo punto, che molto prosaicamente si possa far rientrare comunque Kanban nel novero delle metodologie agile, semplicemente per ragioni di marketing: lo si può proporre ad aziende interessate al passaggio all’Agile, senza doverle ulteriormente confondere con una serie di distinzioni e differenziazioni utili nella riflessione metodologica, ma meno utili nel proporsi al cliente. La cosa che conta, in definitiva, è se Kanban migliori o no l’organizzazione del processo di lavoro nelle aziende tecnologiche. E la risposta è affermativa.

Qualche punto di forza

Kanban ha il merito di mettere in luce l’andamento del flusso di lavoro, in maniera chiara e comprensibile: questo permette di capire che i “lavori ancora a metà”, i work in progress (WIP), devono essere ridotti al minimo. Un sistema di produzione che funziona si basa sull’assioma “stop starting, start finishing!”: piuttosto che cominciare sempre nuove attività, è fondamentale concluderne una per volta.

Non è quello che succede di solito: si tende infatti a mantenere in vita un gran numero di attività contemporanee, anche con l’illusione che allocare contemporaneamente una persona su più progetti diversi paralleli ne ottimizzi la produttività. In realtà, più WIP sono presenti nel flusso in un determinato momento, più le difficoltà di comunicazione e di gestione in parallelo finiscono per appesantire il sistema produttivo. Ne derivano multitasking, problemi di comunicazione, e code che finiscono inevitabilmente per fare aumentare il lead time. A questo punto, le aziende che se lo possono permettere, reagiscono impiegando più personale, che però va a gestire i Work In Progress spesso creando ulteriori WIP e finendo comunque per aumentare i tempi di consegna.

La forza di Kanban sta proprio qui: mettendo in evidenza le code nel flusso, indica chiaramente che la soluzione non sta nel “motivare” i lavoratori, o nel migliorare i tempi della singola attività (le “colonne” della lavagna Kanban). La soluzione sta nel migliorare nettamente il passaggio dei post-it da una colonna all’altro, vale a dire nel ridurre i ritardi nel passaggio da una stazione produttiva all’altra: si tratta in pratica di favorire il flusso, riducendo le ragioni di blocco o attesa che creano le code.

Il limite ai WIP che è possibile istituire per ogni colonna della lavagna mantiene a livelli gestibili il carico di attività svolte contemporaneamente, limitando la complessità e le code che derivano da un eccesso di “contemporaneità” nello svolgere le attività (multitasking, “spezzettameno” del personale su tanti progetti diversi etc.).

Conclusioni

Kanban è un sistema che affonda le sue radici nel sistema di produzione industriale lean, assumendone i principi e la logica pull. Discutere se la metodologia di sviluppo per il software messa a punto da David Anderson, e denominata appunto Kanban, sia o no una metodologia agile è senza dubbio logico e sensato, da un punto di vista “accademico”, visto che in molti casi essa è stata adottata in alternativa a metodologie agili più ortodosse e usate in precedenza, specie in grandi aziende.

Se però passiamo a una visione pragmatica, più che alle differenze di ispirazione e filosofia, occorre guardare al miglioramento e ai vantaggi che Kanban può portare a una organizzazione: in tal senso, sicuramente questo approccio apporta benefici indiscussi al contesto aziendale in cui si effettua sviluppo software, migliorandone “l’agilità” in senso lato.

Kanban può dimostrarsi più adatto a un’adozione in situazioni aziendali molto complesse, perche’ consente una transizione “morbida”, meno drastica di quella necessaria con metodologie agile più strutturate: da un lato c’è un processo di miglioramento continuo (kaizen), dall’altra una iniziativa di transizione gestita.

Per questo, conoscere Kanban come “filosofia” di lean manufacturing, e non solo come strumento rappresentato dalla lavagna, è un punto di forza, poiche’ consente di avere a disposizione una “via alternativa” all’agilità, che è possibile percorrere in quei casi e in quei particolari contesti in cui altre metodologie agili potrebbero incontrare grosse resistenze o non essere scalabili.
 

Riferimenti bibliografici

[1] Womack J.P. – Jones D.T. – Roos D., “The Machine That Changed the World: The Story of Lean Production”, Harper Business, 1991 (trad. it. “La macchina che ha cambiato il mondo”, Rizzoli 1999)

[2] David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, Blue Hole Press, 2010

[3] Agile Manifesto

http://agilemanifesto.org/iso/it/

[4] I dodici principi del software agile

http://agilemanifesto.org/iso/it/principles.html