Kanban è una metodologia basata sul modello organizzativo di tipo “pull” cioè deriva dall’idea che uno step di processo “tiri” quello precedente mediante l’invio di un segnale che si attende a valle della catena.

Questo modo di procedere è opposto al sistema “push” (spinto) dove ogni step di processo corre il più velocemente possibile senza limiti imposti dalle lavorazioni contemporanee.

Negli anni 50 Toyota introdusse questo il modello di produzione “pull” (in antitesi al modello push di Ford) in cui il processo produttivo si spingeva ad ottimizzare le fasi a monte del processo (come ad esempio analisi dei fabbisogni dei consumatori) in questo modo si evitano problemi di sovrapproduzione limitando all’osso le scorte in magazzino così da avere la quantità minima indispensabile di materie prime appena in tempo per produrre un determinato prodotto.

Kanban è un termine giapponese che significa Kan (看) “visuale”, Ban (板) “segnale”.

Questo modello produttivo che inizialmente nulla aveva a che fare con il mondo dello sviluppo software ha allargato i suoi confini quando nel 2010, David Anderson scrisse il libro “Kanban”.

In questo libro D.Anderson spiega come applicare, al mondo della tecnologia e del software, le caratteristiche della metodologia Kanban e del Lean Manufacturing in generale.

Secondo lui, questa metodologia di lavoro consente di:

• visualizzare, misurare e gestire il flusso di lavoro;
• limitare i lavori incompleti;
• regole chiare per gli addetti ai lavori;
• migliorarsi di continuo “aggiustando il tiro” mediante analisi dei risultati e mediante il monitoraggio di lead time (tempo trascorso tra richiesta e risultato) e del cycle of a process (il tempo necessario a completare un’attività)

Kanban in pratica

Una lavagna e qualche blocchetto di post-it sono gli elementi base per avviare Kanban. Si suddivide la lavagna in colonne dove ogni colonna è una singola fase del ciclo di lavoro. Ogni singolo post-it rappresenta un’attività. Quando qualcuno ha finito di compiere un’attività, guarda sulla lavagna cosa deve essere fatto e sposti l’attività che si prende in carico nella colonna apposita (ad esempio in quella “in corso“). Quell’attività diventa quindi una sua responsabilità fino a quando non viene portata a termine. La board Kanban permette di mostrare a tutto il team quali sono i task in essere, chi se ne occupa, a quale stadio di avanzamento si trovano e, data la complessità del task e il suo grado di avanzamento nel flusso, quanti altri lavori possono essere seguiti in contemporanea in quello stato.

Una volta rappresentato visivamente il processo, è facile controllare l’avanzamento delle singole attività e vedere subito dove si formano rallentamenti monitorando Lead Time e Cycle Time. La cosa positiva dell’utilizzo dei sistemi Kanban è che tutti possono vedere subito dove si forma un problema e che un’identificazione precoce della problematica porta ad una sua più semplice risoluzione.

Attenzione a non farsi prendere la mano

Il rischio di questa metodologia è quello di concentrarsi solo alle attività in ToDo ed Ongoing rischiando però di trascurare l’organizzazione del backlog ed il processo di miglioramento incrementale.

Perché il modello kanban sia veramente efficace serve fare attenzione a questi punti:

1. Deve essere definito un modello per la selezione delle attività dal backlog
2. Una volta messa in lavorazione, un’attività non deve mai essere abbandonata
3. Organizzare con precisione i Meeting previsti dal modello con l’obiettivo di migliorare efficacia ed efficienza

1. Non confondiamo Kanban con Agile

Kanban può essere considerato aderente all’Agile Manifesto solo per quanto riguarda la voce “rispondere al cambiamento più che seguire un piano”. Kanban è lontano dalle pratiche Agili per la mancanza di consegne fisse a tempi prestabiliti (time-boxed), vale a dire le cosiddette “iterazioni”.

2. Selezione delle attività

Il backlog non deve essere visto come un contenitore informe di attività, a monte del backlog devono essere attivati dei modelli di catalogazione e prioritizzazione. Possono quindi essere organizzate tre fasi a monte del backlog che sono:

1. pool of task: questo è il primo stadio ed è il contenitore di tutte le attività raccolte in modo destrutturato
2. selection and validation: in questa fase ricorrendo a tecniche tipiche utilizzate nel Product Management e nel Risk Management vengono attribuite priorità e dipendenze ad ogni singola attività. Questa è anche la fase demandata al perfezionamento del task per definire nel dettaglio obiettivi e dipendenze
3. ready to backlog: è lo stadio che precede il backlog, queste attività vengono richiamate dal backlog stesso quando quest’ultimo arriva in soglia di “rifornimento”. Importante è che in questa fase di “pull” le attività che passano da ReadyToBacklog a Backlog si muovano in blocco per dipendenza

3. Mai abbandonare un’attività e non strappare

Su questo tema non c’è molto altro da aggiungere, sembra quasi banale soffermarsi a discuterne ma nella realtà invece sono molte le occasioni che ci “tentano” a sottovalutare questo vincolo. Spesso proprio nella gestione delle emergenze la tendenza è quella di abbandonare l’attività in corso per concentrarsi sull’imprevisto con il rischio di innescare un processo flip-flop che nel lungo ci porta ad accettare questa modalità operativa che ha come impatto il fatto di sfalsare le metriche di misurazione di performance.

Sul fronte invece del “non strappare” e cioè sul fatto di trovare e mantenere un ritmo regolare, ci viene in aiuto Mary Poppendieck con questa frase cristallina: “A regular cadence establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

4. L’importanza dei Meeting

Molti di noi sono convinti che messa in piedi la Board e definito il meeting giornaliero tutto sia fatto e tutto sia sufficiente per sostenere che “stiamo usando il modello Kanban”. Invece così non è! La rete di meeting e review nel modello Kanban sono ben 7 con diversi cicli temporali e interagiscono tra loro come riportato nell’immagine qui sotto:

Andiamo a vedere quali sono gli obiettivi di ogni singola review:

4.1 Standup meeting (daily)

E’ solitamente l’incontro (preferibile farlo in piedi) più frequente (giornaliero) e serve a mantenere la squadra compatta verso l’obiettivo e condividere le informazioni utili a prendere le decisioni migliori su come utilizzare il tempo. Le domande tipiche che ci si pone durante questo incontro sono: come stiamo lavorando? su cosa?, chi ha bisogno di aiuto? qualche attività è bloccata?

4.2 Replenishment Meeting (weekly)

Kanban è un sistema pull e quindi necessita di attività nella coda di input per evitare di rimanere “affamati”. Il Replenishment Meeting è l’incontro in cui decidiamo come organizzare il “rifornimento” della coda. Scrum chiama questa fase: Sprint Planning Meeting. Il primo esempio documentato di Replenishment Meeting risale a quando David Anderson organizzò regolari riunioni di rifornimento quando scoprì che una squadra aveva difficoltà a dare priorità al lavoro in arrivo da più manager, e così organizzò incontri bisettimanali per condividere insieme la priorità delle attività. 

Il risultato atteso da questo incontro è raccogliere dagli stakeholder feedback e determinare qual’è l’insieme di compiti più importanti da svolgere. Fatto spesso e in modo trasparente, aiuta gli stakeholder a fidarsi di ciò che viene promesso. 

Il Replenishment Meeting deve essere svoltocoinvolgendo le persone “giuste” cioè coloro che possono prendere decisioni. La frequenza di questi incontri dipende dall’efficienza dei loop di feedback, della velocità di consegna e dalle dinamica dell’ambiente in cui il sistema sta operando. Indicativamente una frequenza settimanale è sufficiente ma questo meeting può anche non essere periodico ma essere attivato in base alle necessità come ad esempio innescato da un limite di attività minimo nella coda.

4.3 Service Delivery Review (bi-weekly)

Questo è il momento in cui il team si pone la seguente domanda: Come stiamo servendo i nostri clienti? Viene quindi effettuata una revisione del servizio dal punto di vista dei beneficiari. 

E’ fondamentale questa riflessione perché l’efficienza del team viene sprecata se il cliente non è soddisfatto. La revisione della consegna del servizio, che coinvolge rappresentanti degli utenti finali, esplora la soddisfazione del cliente con tutti gli aspetti del processo, tra cui l’efficienza, la comunicazione, la consegna rispetto agli SLA e l’utilizzo delle risorse del team. L’obiettivo è migliorare la soddisfazione del cliente e creare fiducia attraverso la trasparenza. 

La review viene fatta rivedendo l’ultimo lotto di lavoro consegnato analizzando qualità, SLA e qualsiasi altro criterio di successo con i clienti. Le domande da porsi in questa review sono: i clienti sono soddisfatti di ciò che viene consegnato? Sono soddisfatti di quanto frequentemente e di come viene consegnato? Sono contenti che stai facendo il miglior uso delle risorse disponibili per fornire valore? Quando le cose vanno male, sono contenti della tua reazione e comunicazione sui problemi emergenti e sono convinti che il tuo processo di valutazione del rischio sia sufficiente a minimizzare i danni a valle?

4.4 Operation Review (monthly)

L’Operation Review ha l’obiettivo di analizzare e rilevare come collaborano tra loro i vari team.

Non si può pensare di migliorare un sistema senza considerare tutte le altre parti. Un singolo team non può salvare un’organizzazione che ha una pipeline di consegne scadente. In questa review quindi i manager di diversi settori cercano modi per migliorare il sistema nel suo complesso. 

Questa review viene fatta rispondendo alle domande: Quanto sono felici i clienti? Quanto è redditizia l’azienda? Ci sono stati cambiamenti nel turnover del personale? C’è e dov’è capacità sotto-utilizzata? Sulla base di questi dati, il team elabora esperimenti per migliorare l’efficienza del flusso di lavoro nell’intero sistema.

4.5 Risk Review (monthly)

Lo scopo della Risk Review è quello di valutare la probabilità di non riuscire a soddisfare le aspettative, sia per i componenti del sistema a valle che per gli utenti finali. 

Identificare i rischi in anticipo e adottare misure per mitigare tali rischi migliora la prevedibilità del sistema, aumentando la fiducia e la redditività. 

Il livello più elementare di revisione del rischio consiste nell’esaminare i fallimenti del passato, sotto forma di attività bloccate, rielaborare gli SLA, e identificare le cause alla base e trovare modi per evitare che tali eventi si ripetano. Una pianificazione dei rischi più completa include speculazioni su possibili rischi futuri basati sull’esperienza e sull’input da tutti i livelli. 

4.6 Delivery Planning Meeting (delivery cadence)

Partendo dal riconoscere che la maggior parte di noi non consegna direttamente al cliente finale questo incontro serve a migliorare i passaggi tra team. 

Il tema valle del nostro potrebbe non apprezzare il fatto di trovare una pila di lavoro a intervalli casuali. Potrebbero quindi apprezzare il fatto di essere coinvolti nel decidere come, quando e cosa viene consegnato. 

L’analisi viene fatta raccogliendo feedback dai team a valle del nostro, incrociando queste informazioni con gli output dei meeting giornalieri, con la board e con il risk review il tutto per valutare i flussi di ciò che è pronto in consegna e ciò che sarà pronto a breve.

L’obiettivo è assicurare un trasferimento fluido dei WIP (i WIP sono i deliverable prodotti dal TeamA e consegnati al TeamB ricevente). Come risultato di questa riunione, alcune attività in corso potrebbero cambiare priorità. 

4.7 Strategy Review (quarterly)

La Strategy Review esamina i cambiamenti del mercato e si chiede se i nostri attuali obiettivi operativi siano ottimizzati per soddisfare le esigenze emergenti. 

La domande che ci dobbiamo porre sono: siamo davvero efficienti? Ma stiamo facendo la cosa giusta? La cosa giusta è cambiata a causa delle condizioni di mercato? Questo incontro è quello quindi in cui rivedere la strategia aziendale e garantire che i nostri processi stiano offrendo il valore che meglio serve alla nostra strategia di business. 

Durante lo Strategy Review si devono confrontare le consegne recenti con le tendenze del mercato e porsi la domanda: siamo abbastanza flessibili per adattarci alle richieste di mercato? Se c’è una discrepanza tra la nostra capacità di apportare modifiche significative alle nostre offerte e il ritmo delle nuove richieste del mercato, dobbiamo prendere in considerazione la possibilità di cambiare mercato o di trovare modi per ottimizzare i nostri processi. Le persone da coinvolgere ed a cui porre tali domande sono i dirigenti aziendali con input da parte di unità di marketing e clienti e che si occupano di business come vendite e assistenza clienti. Il risultato di questo incontro potrebbe essere nuove linee guida per la valutazione di idee di prodotto o indicatori KPI che siano meglio allineati con le aspettative del mercato.

La periodicità dei meeting

La periodicità di questi meeting è una proposta che vi ho fatto io ma non è scritto da nessuna parte che tutte queste cadenze devono avvenire a intervalli regolari. Potrebbe essere sensato collegarne alcuni agli eventi. Ad esempio, le revisioni dei rischi potrebbero essere effettuate mensilmente, ma potrebbero anche essere innescate da errori critici. Le revisioni sulle consegne potrebbero anche essere biennali quando tutto sta andando bene e potrebbero essere attivate automaticamente dal mancato nel momento in cui gli SLA vanno in area critica. Le riunioni di rifornimento potrebbero verificarsi settimanalmente oppure potrebbero essere attivate da un determinato numero minimo di elementi in una coda di input. Le cadenze temporali sono utile per le situazioni in cui vi è un valore negli aggiornamenti frequenti come gli standup meeting o per quelle cose importanti ma non urgenti che potrebbero non innescarsi mai come ad esempio la revisioni della strategia.