Kanban è uno strumento di lavoro che nasce in Giappone nell’ambito della manifattura Lean, come metodo per il controllo dei flussi di produzione. Nella sua versione riveduta e adattata, Kanban diventa uno strumento che ben si integra con altre metodologie agili. In questa nuova serie, vedremo come l’utilizzo di cartellini visuali, della lavagna e di alcune semplici regole possa semplificare e migliorare la gestione dei progetti software.

Pizza al taglio, ossia Kanban nel negozio all’angolo

Nella pizzeria a taglio che ha aperto da poco in paese c’è un pizzaiolo esperto che, dopo molti anni di lavoro alle dipendenze di altri principali, ha deciso di mettersi in proprio. Useremo un nome di fantasia per questo simpatico ristoratore e nella migliore tradizione della pizza napoletana, lo chiameremo Antonio.
Antonio, nel piccolo negozio, ha messo un banco con una vetrina, dove gli avventori possono ammirare le pizze appena sfornate già tagliate in fette o spicchi.  Accanto alla vetrina c’è una piccola cassa.
Normalmente Antonio tiene in questa vetrina quattro o cinque tipi di pizza, scelte fra quelle più richieste dalla clientela. Il pomeriggio all’uscita della scuola vicina molti bambini si fermano coi genitori per fare merenda e per questo motivo una delle pizze più richieste è una specie di focaccia dolce farcita di cioccolata. La sera invece gli adolescenti preferiscono pizze dai sapori più forti, piccanti o magari qualche ricetta più dietetica.
Dietro il bancone Antonio ha installato una macchina spianatrice (con la quale, partendo dalle palle di pasta preparata manualmente, si formano le basi di pasta cruda) e un paio di forni elettrici per la cottura.
Antonio, da esperto pizzaiolo, è in grado di sfornare sempre la giusta quantità di pizze dei vari tipi, tanto che normalmente l’attesa media dei clienti è sempre molto ridotta.

Dalla quattro stagioni al Kanban

Il modo con cui Antonio gestisce la sua pizzeria è molto efficiente e vi si possono trovare applicati, magari in modo inconsapevole, alcuni principi della filosofia Agile nonchè della metodologia Kanban. Innanzitutto Antonio punta ad avere poche pizze pronte nella sua vetrina in modo che la clientela possa sempre degustare pizze calde appena sfornate, che si possano limitare gli sprechi a fine giornata e che sia quindi pianificare meglio la preparazione; normalmente per ottenere questi obiettivi deve costantemente tenere sotto controllo il flusso delle richieste della sua clientela.
In termini Lean potremmo dire che Antonio tende a ridurre al minimo le giacenze di magazzino, preferendo una produzione just-in-time per offrire sempre un prodotto di qualità.

Tirare la produzione: approccio pull vs approccio push

Il nostro pizzaiolo riesce a ottimizzare questo processo di lavorazione tramite quello, che nell’ambito della produzione snella, si chiama approccio pull: non esegue alcuna pianificazione preventiva del quantitativo di pizze da fare nè sul tipo,  ma valuta il livello del magazzino (il bancone) e in base a quello si mette a preparare o meno altre pizze. Nei momenti in cui non c’è molto da fare, quando per esempio il bancone è pieno e c’è poca clientela nel negozio, allora si mette a svolgere quelle attività non urgenti (che potremmo chiamare task a bassa priorità), come per esempio preparare le palle di pasta che poi andranno in frigorifero, oppure pulire il forno, oppure riposarsi.
Il suo obiettivo è fare in modo che sul bancone ci siano sempre tre o quattro pizze pronte: conoscendo il tempo necessario per far sì che una pizza sia pronta per essere messa in vendita, il cosiddetto lead time di processo, appena vede che le scorte scendono sotto un certo quantitativo, si mette a preparare una nuova pizza.
È quindi il flusso dei clienti che comprano le pizze, ossia il ritmo di svuotamento del magazzino, che determina il processo di lavorazione: in gergo si dice che il processo viene tirato (“pull” in inglese) dal fondo.
Se Antonio applicasse un processo opposto (push) si concentrerebbe sulla produzione delle pizze cercando prima di tutto di immaginare quante ne riuscirebbe a vendere: in questo caso la sua unica preoccupazione sarebbe quella di “spingere” la produzione dal forno verso il bancone e quindi verso la bocca dei clienti, in modo da non accumulare troppe pizze pronte per essere infornate. Per perseguire questo approccio, dovrebbe fare molta attenzione alla pianificazione e controllare accuratamente l’organizzazione del suo processo di lavorazione, valutando in particolar modo i vari colli di bottiglia (il forno, la parte di preparazione delle palle di pasta, il bancone).
Antonio sa che questo lavoro di controllo e pianificazione è indubbiamente più complicato, sicuramente meno efficiente dell’altro (pull); inoltre a fine giornata qualche spreco lo si avrebbe sempre.

Priorizzare le attività: task lenti, task bloccanti, task poco importanti

Antonio nella sua piccola bottega mette in atto anche altri principi tipici della produzione snella. Egli infatti lavora da solo, anche se in quel negozio ci sono un paio di forni e una sola pressa che spiana le palle di paste per la pizza. Questa configurazione non è causale. La macchina pressatrice infatti svolge un compito semplice e rapido che dura solo pochi secondi. Il forno invece è probabilmente la fase della lavorazione più lunga dato che per cuocere una pizza sono necessari circa 8 minuti a seconda del tipo di pizza. Per questo motivo, nella stanza una pressatrice è più che sufficiente mentre un solo forno avrebbe creato code in attesa. In realtà, dopo qualche tempo, Antonio si è potuto permettere un forno più grande, in grado di cuocere fino a dieci pizze contemporaneamente, cosa che, di fatto, gli permette non solo di velocizzare il tempo di preparazione di una singola pizza, ma anche di eliminare ingolfamenti in entrata al forno. In questo modo Antonio può smettere di preoccuparsi di gestire le fasi intermedie e concentrarsi sull’unico punto veramente importante: il numero di pizze pronte ed esposte nella vetrina.

Priorità e lotti di lavorazione

Una cosa che però continua a gestire con la massima attenzione è la fase più delicata della lavorazione, la cottura: essendo la fase più lunga dell’intero processo, è molto importante non sottovalutarla. Per questo motivo egli spesso sacrifica altre fasi della lavorazione: sia che stia guarnendo una base di pasta sia che stia servendo un cliente, spesso si interrompe per infornare o per togliere una pizza pronta (task lento ad alta priorità perchè bloccante sugli altri)
In realtà Antonio gestisce quest’alternanza (per esempio fra il servire un cliente o interrompersi per infornare una pizza) in modo accorto; come ogni commesso che lavora al pubblico conosce bene il valore di ogni fase del suo lavoro: per esempio interrompere il condimento di una pizza ha un impatto diretto solo sul processo di lavorazione, mentre sospendere momentaneamente il servizio di un cliente è una cosa che potrebbe comportare un prezzo maggiore in termini di immagine o di soddisfazione della clientela.
Dato che sa intrattenere con simpatia i propri clienti, può permettersi di interrompere il servizio al bancone per cuocere una pizza; Antonio però sa che può interrompersi solo per dedicarsi ad attività di breve durata. Se per esempio decidesse di seguire la lavorazione di 5 pizze per volta, tutte le fasi sarebbero più impegnative in termini di tempo e quindi anche le interruzioni al servizio al bancone diventerebbero intollerabili per la clientela. Antonio sa quindi che il trucco è gestire lotti di lavorazione piccoli, per esempio una pizza per volta.

Buffer nel processo

Ricapitoliamo velocemente la maggior parte delle scelte fatte da Antonio nel gestire il suo negozio: approccio pull, piccoli lotti in produzione, fasi di lavorazione a durata differente, brevi momenti di interruzione per infornare pizze crude e successivamente per sfornare pizze cotte, e così via. Tutte queste attività sono possibili anche grazie a una soluzione importante: la vetrina delle pizze pronte. In termini Lean questa potrebbe essere definita come una specie di buffer in grado di assorbire gli sbalzi del processo di lavorazione o di domanda, se per esempio entrano più persone del previsto nel negozio a comprare le pizze.
La dimensione di tale buffer (il numero di pizze cotte esposte nel bancone) è molto importante: con un buffer troppo piccolo (poche pizze pronte per la vendita), Antonio rischia di non avere tempo per dedicarsi alla preparazione di nuove pizze. Se il buffer invece è troppo grande, il pericolo è quello di trovarsi con  troppe pizze pronte rispetto alla reale domanda della clientela. L’esperienza e la maestria di Antonio gli permettono di variare e di scegliere la dimensione di volta in volta più opportuna di questo buffer.
Come si avrà modo di vedere, quasi tutti i processi di produzione si avvalgono di uno o più stazioni di parcheggio, o buffer, in modo da stabilizzare e quindi ottimizzare il flusso di lavorazione. In questo caso, essendo la catena di lavorazione estremamente ridotta, una sola stazione di parcheggio in fondo alla linea di lavorazione è in grado di stabilizzare tutta la catena.

Limitare il numero di attività svolte in parallelo: “Your multitasking is my bottleneck”.

Oltre al dimensionamento della vetrina da esposizione, fra le varie cose che Antonio ha imparato a gestire con l’esperienza, è il numero delle cose che il suo negozio riesce a fare in parallelo.
In passato si è avvalso della collaborazione di alcuni aiutanti che aveva chiamato per aumentare la produzione in concomitanza di determinati picchi di produzione. Sebbene questo abbia permesso di aumentare il numero di pizze in lavorazione, ha anche messo in luce anche alcuni limiti strutturali del laboratorio di Antonio. Spesso si creavano ingorghi durante la lavorazione delle pizze, per esempio in entrata del forno o peggio ancora sul bancone della vetrina, oppure non si riusciva a produrre il giusto quantitativo di pizze per minimizzare gli avanzi (pizze fredde non più vendibili). A rotazione, ai vari addetti alla lavorazione capitava di rimanere in attesa che un collega finisse un altro lavoro: spesso tale attesa era dovuta alle troppe cose che i colleghi dovevano fare. L’idea che iniziò a farsi strada all’interno del negozio è che, maggiore era il numero di cose che ognuno faceva in parallelo, maggiore era la probabilità che uno dei lavoratori si bloccasse; questo fenomeno sarebbe stato ancora più evidente se in quel laboratorio ci fosse stato un numero maggiore di persone (in questo caso gli spazi ridotti non fanno altro che accentuare questo fenomeno che però dipende da aspetti organizzativi).
Una frase che spesso viene utilizzata per spiegare la filosofia lean e le metodologie basate su kanban è proprio questa: “Your multitasking is my bottleneck”, vale a dire che fare tante cose tutte insieme non è affatto un vantaggio, ma anzi va a creare degli intoppi, dei “colli di bottiglia”.
Con il tempo, Antonio si rese quindi conto che, sebbene fosse possibile aumentare la quantità di attività svolte, la presenza di colli di bottiglia nel processo avrebbero portato a un complessivo abbassamento delle prestazioni tanto da vanificare gli sforzi fatti per aumentare la produzione, aumentando invece i costi e gli sprechi.
Molte delle cose viste nel caso d’esempio della pizza a taglio sono traducibili in alcuni dei concetti base della produzione snella e di Kanban in particolare. Prima di passare ad analizzare quindi la teoria alla base di Kanban, conviene vedere un altro paio di esempi.

Controllare il flusso: dal giardino della casa reale giapponese alla gestione dei parcheggi di automobili

Cambiando completamente scenario, un altro esempio che sicuramente sarà capitato a molti di vivere in prima persona è quando si parcheggia l’auto in un parcheggio a pagamento in cui entrata e uscita sono regolati da sbarre automatiche, sistemi di pagamento e i posti numerati.
Se il numero di automobilisti che desiderano parcheggiare è al di sotto della capienza del parcheggio, in genere nessuno si accorge del meccanismo che regola il parcheggio stesso: si arriva, si preleva un biglietto, la sbarra si alza e si procede verso un posto libero. Se invece il parcheggio ha raggiunto la capacità massima, normalmente all’entrata si formano delle code di auto in attesa di poter entrare nel parcheggio. In questo caso, essendo il numero di posti disponibili limitato dalla capienza massima del parcheggio, per ogni automobilista che lascia il parcheggio, si libera un posto per la vettura di un altro che potrà entrare.
Quest’organizzazione è possibile perchè un semplice contatore tiene traccia delle auto che entrano e di quelle che escono e blocca la sbarra quando si arriva a un certo limite.
Tale sistema si basa su un meccanismo inventato molti anni fa presso il giardino del palazzo imperiale giapponese: in primavera moltissime persone visitavano e visitano tutt’oggi il giardino per poter assistere allo spettacolo della fioritura dei ciliegi; per garantire l’armonia e la bellezza del parco è necessario limitare il numero di visitatori contemporanei, cosa che fin dai tempi antichi viene ottenuta con un meccanismo estremamente semplice ma altrettanto efficace. Pur essendo il parco gratuito, all’entrata ogni visitatore preleva da un contenitore una tessera visuale (una kanban appunto), oggetti realizzati a mano dagli artigiani imperiali molti anni fa. Il visitatore deve tenere con s� questa tessera per tutto il tempo in cui rimane dentro il parco. Quando il contenitore è vuoto, nessun visitatore può entrare nel parco: avere la tessera in mano è la condizione per poter entrare. Quando un visitatore esce e depone la tessera nella ciotola, un altro può entrare. Semplice. Facile. Ripetibile.
Questo aneddoto, raccontato fra gli altri da D.J. Anderson nel suo famoso libro su Kanban [KAN], è probabilmente la dimostrazione più efficace della filosofia di Kanban e dell’Agile in genere. Avremo modo di ritornare su questi concetti.

Limiti di processo e di canale: il traffico in autostrada

Un’altra esperienza che in qualche modo è collegata ai concetti teorici su cui si basa Kanban e quella che ogni lettore vive più o meno regolarmente quando percorre in automobile un tratto di autostrada o di superstrada.  Un fenomeno piuttosto ovvio che si può sperimentare è che maggiore è il numero di auto che percorrono quel tratto, maggiore è la probabilità che si formino dei rallentamenti o addirittura che il traffico si blocchi del tutto. Meno intuitivo è il fatto che, in condizioni di forte traffico, tali rallentamenti sono spesso legati ai limiti di velocità: più alta è la velocità consentita,  più alta la probabilità di problemi di circolazione. È stato dimostrato infatti che abbassare il limite permette a tutte le autovetture si spostarsi in modo costante senza blocchi, dando luogo a una performance migliore: si viaggia più piano ma senza mai fermarsi e alla fine il viaggio dura meno tempo. Questi due aspetti dello stesso fenomeno (i rallentamenti in autostrada), sono strettamente dipendenti fra loro e sono legati a quella che empiricamente viene detta capacità di processo: tale valore è funzione di una serie di fattori come la capacità massima di canale (per esempio il numero massimo di auto che possono transitare per un tratto di strada), il grado di variabilità all’interno del processo in termini di complessità o del tempo di lavorazione (nell’esempio della autostrada potrebbe essere il numero di salite o di restringimenti della carreggiate), la definizione ottimale di aree di parcheggio all’interno del processo (vedi l’esempio del bancone della pizzeria) e altro ancora.
Un errore tipico che si commette quando si desidera aumentare le prestazioni del sistema, è quello di “spingere” su tutte queste variabili con la speranza che le performance complessive migliorino. Purtroppo, come avremo modo di vedere, oltre un certo limite, la risposta del sistema va nella direzione opposta.  Di questi aspetti si era accorto anche Deming il quale, nei suoi studi affermava che la migliore performance di un sistema complesso non si ottiene spingendo al massimo ogni componente del sistema, ma trovando una corretta configurazione fatta anche di parti che lavorano ben al disotto della potenza nominale massima (vedi [VA] e successivi).
Avremo modo di formalizzare meglio questi temi quando parleremo di teoria delle code, del teorema di Little e dell’effetto Forrester. In questo primo articolo iniziamo con l’introdurre i concetti di base di Kanban rimandando alle puntate successive gli approfondimenti sulle tecniche e sull’utilizzo nella pratica di progetto.

Breve storia di Kanban

Verso l’inizio degli anni Quaranta del secolo scorso, gli ingegneri di Toyota stavano lavorando all’ottimizzazione dei propri processi di produzione. Taichi Ohno, anche prendendo spunto dal lavoro di Deming, lavorava duramente per introdurre nuovi principi di quella che sarebbe diventata poi la produzione snella (vedi [VA] e successivi).
Una delle fonti che dette maggior ispirazione a Ohno arrivò da un settore inaspettato, quello della grande distribuzione alimentare. In quel periodo stavano nascendo i primi supermercati dentro i quali i commessi e gli addetti al rifornimento del magazzino dovevano gestire merci con un alto tasso di degradazione: il periodo necessario a un cesto d’insalata per perdere di “freschezza” è sicuramente minore del tempo necessario a una automobile per diventare obsoleta. In quel contesto fu messo a punto un sistema di approvvigionamento guidato dal fondo del processo, ovvero dal livello di approvvigionamento a scaffale: solo quando l’ultimo elemento di un certo prodotto era prossimo alla vendita si procedeva al riordino, non prima.
Furono quelli i primi esperimenti di gestione just-in-time, esperienti che ispirarono  manager giapponesi della Toyota nel mettere a punto un nuovo processo di approvvigionamento. Tramite la gestione in tempo reale dei flussi di entrata e di uscita dei prodotti, riuscirono a migliorare le prestazioni complessive del sistema [MAC]. Stava nascendo Kanban.
Uno dei principi che animò questo percorso di trasformazione è descrivibile con un semplice slogan: “migliorare la comunicazione tramite una gestione visuale del processo”. La parola kanban infatti deriva dalla composizione delle parole Kan (che significa “visuale”) e  Ban (che significa “segnale”) e difatti la metodologia faceva uso di cartellini visuali e di lavagne dove questi cartellini erano attaccati per monitorare gli stati di avanzamento della produzione, l’approvvigionamento, l’acquisto o la movimentazione dei materiali. Tramite questi irradiatori di informazioni, si stimolava il confronto e il dialogo all’interno del team, velocizzando lo scambio delle informazioni e agevolando quindi il processo decisionale lavorativo.
Fra gli obiettivi che Ohno e il suo staff si dettero durante il lavoro di messa a punto di Kanban, vi era quello di evitare la sovrapproduzione delle merci in entrata o dei prodotti finiti in uscita che, in ottica Lean, erano considerate fra le forme di spreco più impattanti sulle performance di un sistema produttivo.
A partire dal 2007 Kanban è stato introdotto nel software management come metodologia di gestione e controllo dello sviluppo del software grazie al lavoro di David J. Anderson, il  quale si è ispirato ai principi del Lean e del Toyota Production System messo a punto da Ohno in oltre venti anni di lavoro (vedi [VA] e successivi). Anderson ha formalizzato le sue idee in un libro pubblicato pubblicato nel 2010 [KAN], all’interno del quale ha sintetizzato in cinque punti gli aspetti più importanti di Kanban:

• Visualizzare il flusso di lavoro: rappresentare visivamente il processo di lavorazione, ponendo in risalto, per ogni fase del processo complessivo, il valore prodotto.
• Limitare il Work-in-Progress: porre dei limiti espliciti sul lavoro complessivo eseguibile all’interno di ogni fase della lavorazione.
• Misurare e gestire il flusso: misurare e gestire il flusso per avere sempre informazioni attendibili e poter quindi prendere decisioni coerenti col sistema. Per ogni azione intrapresa, visualizzare sempre conseguenze.
• Rendere esplicite le politiche di processo: definire e condividere con tutti gli interessati le regole a cui processo e stakeholder devono attenersi è il modo più semplice ed efficace per garantire il miglioramento delle prestazioni, la riduzione degli sprechi, l’ottenimento degli obiettivi.
• Identificare le possibili opportunità di miglioramento: creare nell’organizzazione una cultura (kaizen), in cui il continuo miglioramento del sistema, del processo e delle performance siano obbiettivi condivisi in tutti i membri della comunità.

Questi cinque punti possono essere considerati i cinque obiettivi fondamentali che dovrebbero essere perseguiti tramite tre regole importanti, che sono alla base di Kanban:

• Usare gli strumenti già in possesso: partire da quello che si sa fare senza aspettare di imparare.
• Condividere un percorso di cambiamento che abbia come obiettivo la crescita e l’evoluzione dell’organizzazione.
• Rispettare l’organizzazione attuale: il processo di cambiamento ed evoluzione non deve imporre stravolgimenti nel processo, modifiche nei ruoli e nelle persone, ma introdurre le novità in modo graduale e compatibile con le necessità e gli obiettivi. Per questo la visualizzazione del processo, la misurazione, la definizione esplicita delle policy sono così importanti.

Molte delle indicazioni fin qui viste sono prese per la maggior parte dai principi del Lean che Kanban sposa in pieno: si potrebbe quasi dire che l’obiettivo principale di Kanban è quello di funzionare come attivatore dei principi Lean all’interno dei sistemi di produzione del software. In tal senso le parole di D.J. Amderson sono particolarmente esaustive:

“… Kanban (capital K) is the evolutionary change method that utilizes a kanban (small k) pull system, visualization, and other tools to catalyze the introduction of Lean ideas into technology development and IT operations”

In tal senso è importante fare una precisazione su un aspetto che spesso è fonte di fraintedimenti:  è consuetudine utilizzare la parola “Kanban” con la ‘K’ maiuscola per riferirsi alla metodologia di gestione dello sviluppo del software, mentre quando si usa la parola “kanban” con la ‘k’ minuscola si fa riferimento all’uso di cartellini come segnalatori visuali, per la realizzazione di sistemi pull così come descritto nel Toyota Production System [K].

Riferimenti bibliografici

[MAC] 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)

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

[VA] Giovanni Puliti, “Verso l’Agile – I parte: L’importanza dell’apprendimento”, MokaByte 188, ottobre 2013

https://www.mokabyte.it/cms/article.run?permalink=mb188_VersoAgile-1

[K] Francesco Saliola, “Kanban: agile o no? – Qualche riflessione su una questione dibattuta”, MokaByte 190, dicembre 2013

https://www.mokabyte.it/cms/article.run?permalink=mb190_AgileKanban