Kanban

Quando si pensa allo sviluppo agile, molti si ri­fe­ri­sco­no al popolare metodo Scrum. Esso non è tuttavia l’unico modo per uti­liz­za­re una gestione agile dei progetti all’interno della vostra azienda. Kanban è un altro metodo red­di­ti­zio già uti­liz­za­to in molti ambiti. Ma Kanban è adatto anche alla vostra azienda o al vostro progetto? Vi spie­ghia­mo come funziona il metodo.

Kanban viene ori­gi­na­ria­men­te dal Giappone. La Toyota sviluppò questo sistema già nel 1947. Ecco spiegato il suo nome: è una parola composta da due sillabe giap­po­ne­si, kan e ban, che let­te­ral­men­te significa “carta segnale”. A quell’epoca con l’aiuto di Kanban venivano ot­ti­miz­za­ti i flussi di materiale. Toyota voleva infatti evitare carenze ma anche eccessi di scorte di materiali di pro­du­zio­ne. Il risultato oggi viene chiamato anche metodo pull, poiché l’ap­prov­vi­gio­na­men­to viene richiesto solo quando le scorte stanno ter­mi­nan­do.

Basandosi su questa idea, il metodo si è affermato anche nello sviluppo dei software. Sia alla Microsoft che alla Corbis (un’altra azienda di Bill Gates) negli anni 2000 l’idea dello sviluppo snello pro­ve­nien­te dall’industria au­to­mo­bi­li­sti­ca è stata rein­ter­pre­ta­ta e adattata. Non si trattava più di gestire i materiali di pro­du­zio­ne, ma di assegnare compiti secondo il metodo pull: non appena un team porta a termine un compito, ne vengono “tirati” altri dal backlog. In questo modo il flusso di lavoro può essere mi­glio­ra­to anche in tanti altri campi.

Chi introduce Kanban nel suo team vuole mi­glio­ra­re il flusso di lavoro e allo stesso tempo aumentare la pro­dut­ti­vi­tà e la qualità del prodotto finale. Kanban fa parte dei metodi agili e come tale rende il processo la­vo­ra­ti­vo molto più fles­si­bi­le. I compiti vengono suddivisi in piccole fasi e portati a termine l’uno dopo l’altro. A Kanban ap­par­tie­ne infatti lo slogan: “Stop starting – start finishing!” Invece di iniziare numerosi compiti e lavorarci più o meno in parallelo con un’attività mul­ti­ta­sking, sarebbe meglio operare passo dopo passo, ter­mi­nan­do­ne uno prima di dedicarsi a un altro.

Adeguarsi a questo nuovo sistema è molto facile. A dif­fe­ren­za di altri metodi, Kanban si integra fa­cil­men­te in processi già esistenti. Ciò lo rende par­ti­co­lar­men­te aperto: è infatti possibile in­tro­dur­re insieme a Kanban anche altri metodi come Scrum.

Nella quo­ti­dia­ni­tà la­vo­ra­ti­va è normale tuttavia che ci siano dei compiti più im­por­tan­ti di altri. Per mettere in evidenza tali priorità anche sulla Kanban Board, si in­se­ri­sco­no le co­sid­det­te swimmlane. Si tratta di linee oriz­zon­ta­li che sud­di­vi­do­no la colonna del work in progress. Ad esempio il team può inserire in un campo in alto (in una fastlane) tutti quei compiti che devono essere portati a termine prima degli altri e lasciare i compiti meno urgenti in basso. In questo modo ogni com­po­nen­te del team può farsi ve­lo­ce­men­te un’idea delle priorità attuali.

Grazie a questa rap­pre­sen­ta­zio­ne si riesce ad aumentare la tra­spa­ren­za del lavoro in modo molto semplice. Sce­glien­do Kanban non si decide solo di adottare un’utile vi­sua­liz­za­zio­ne del flusso di lavoro, ma si sceglie anche un metodo che limita i compiti: prima di iniziare ad uti­liz­za­re Kanban nella pro­du­zio­ne, si sta­bi­li­sce a quanti compiti si può lavorare con­tem­po­ra­nea­men­te. Se non c’è nessuna li­mi­ta­zio­ne per le due colonne esterne, ogni colonna centrale deve ri­spet­ta­re un valore massimo. Quindi un team può lavorare solo a due car­tel­li­ni per fase, perché, secondo i so­ste­ni­to­ri del Kanban, il mul­ti­ta­sking porta ad un ritardo nel processo la­vo­ra­ti­vo.

Invece di spostare i compiti da una fase a un’altra, con Kanban si segue il metodo pull. I compiti vengono quindi “tirati”. Solo quando il team ha di nuovo spazio libero nella colonna, i di­pen­den­ti prendono un nuovo compito dalla colonna situata a sinistra rispetto alla loro. Ciò significa anche che le colonne sono spesso ul­te­rior­men­te suddivise: da un lato i compiti a cui si sta lavorando e dall’altro quelli che devono essere spostati alla fase suc­ces­si­va.

Le li­mi­ta­zio­ni poi servono affinché le risorse libere possano essere suddivise ef­fi­cien­te­men­te, in par­ti­co­la­re quando un compito è co­sti­tui­to da diverse fasi e per evitare di formare degli ingorghi. Nel caso in cui nella prima fase si lavori ve­lo­ce­men­te ma nella seconda ci siano dei problemi, i di­pen­den­ti, secondo Kanban, non possono con­ti­nua­re a portare a termine i compiti della prima. Al contrario, si uti­liz­ze­ran­no risorse libere per aiutare a risolvere il problema nella seconda fase.

Oltre al limite dei compiti con­te­stua­li, sulla Kanban Board possono essere chia­ra­men­te rap­pre­sen­ta­te altre regole. Tra queste quella che indica il momento a partire dal quale un compito può essere definito terminato e pronto per la prossima fase. Inoltre deve essere chiaro che tali regole possono cambiare. Fanno parte dei processi agili anche le attività di analisi e adat­ta­men­to.

Per mi­glio­ra­re il processo la­vo­ra­ti­vo a lungo termine è im­por­tan­te lo scambio di feedback. Per questo motivo Kanban prevede meeting regolari (le co­sid­det­te cadenze), ma non vengono date in­di­ca­zio­ni precise sulla loro frequenza o modalità di svol­gi­men­to. Il pioniere di Kanban, David J. Anderson, dà invece alcuni consigli a riguardo: un meeting Kanban al giorno (simile al Daily Scrum), revisioni spe­ci­fi­che su diversi temi e altri meeting.

Lo scambio di idee tra colleghi è in linea con lo scopo generale di Kanban: mi­glio­ra­re il flusso di lavoro e il prodotto. Partendo dallo stato attuale il team deve in­tro­dur­re nuovi mi­glio­ra­men­ti a poco a poco, invece di or­ga­niz­za­re una grande svolta. Questo approccio viene spesso pa­ra­go­na­to alla filosofia giap­po­ne­se Kaizen. Tale teoria, che si ritrova ora prin­ci­pal­men­te nella corporate go­ver­nan­ce, promuove il mi­glio­ra­men­to continuo (Kaizen in giap­po­ne­se significa “cambiare per mi­glio­ra­re”). Un ob­biet­ti­vo finale invece non c’è. Secondo la teoria Kaizen si possono adottare sempre nuovi cam­bia­men­ti.

Nel metodo Kanban si possono in­di­vi­dua­re com­ples­si­va­men­te sei diverse prassi:

1. Vi­sua­liz­za­zio­ne: la Kanban Board è una vi­sua­liz­za­zio­ne del processo la­vo­ra­ti­vo. La sua con­fi­gu­ra­zio­ne rimane però ab­ba­stan­za libera. La cosa im­por­tan­te è che le fasi siano chiare e che per ogni colonna venga mostrato il relativo limite.
2. Li­mi­ta­zio­ne: ogni colonna può contenere solo un de­ter­mi­na­to numero di compiti. Il team può prendere un nuovo car­tel­li­no dal lato sinistro solo quando il car­tel­li­no di un compito viene spostato verso destra. Ciò porta ine­vi­ta­bil­men­te a un flusso di lavoro ef­fi­cien­te.
3. Gestione: durante il processo la­vo­ra­ti­vo può succedere che ci siano dei blocchi o delle carenze. In tali si­tua­zio­ni è im­por­tan­te far con­cen­tra­re il team sull’eli­mi­na­zio­ne dei blocchi. Inoltre l’os­ser­va­zio­ne del flusso di lavoro serve a sud­di­vi­de­re cor­ret­ta­men­te le risorse di­spo­ni­bi­li a lungo termine.
4. Re­go­la­men­ta­zio­ne: regole esplicite sono pensate per rendere il processo la­vo­ra­ti­vo tra­spa­ren­te e chiaro. Fanno parte di tali regole ad es. la de­ter­mi­na­zio­ne di limiti, ma anche la de­fi­ni­zio­ne del momento a partire dal quale un compito può definirsi com­ple­ta­to. Le regole del processo devono essere allo stesso modo una parte evidente e mutabile della Kanban Board.
5. Feedback: i feedback sono una parte im­por­tan­te del processo la­vo­ra­ti­vo, in quanto è solo grazie ad essi che il lavoro può essere mi­glio­ra­to. Per questo motivo sono previsti meeting regolari, le co­sid­det­te cadenze. A dif­fe­ren­za di Scrum, Kanban non definisce una struttura fissa per tali incontri.
6. Kaizen: i processi del team devono essere con­ti­nua­men­te mi­glio­ra­ti con Kanban. Secondo la teoria non bisogna rag­giun­ge­re un optimum, ma bisogna lavorare con­ti­nua­men­te per mi­glio­ra­re.

Kanban si può inserire fa­cil­men­te in qualsiasi struttura di lavoro in team. Alcune aziende lavorano già con una versione (snellita) di Kanban senza saperlo. Il metodo pull è una tecnica molto intuitiva, ma anche la vi­sua­liz­za­zio­ne in una Kanban Board, la tra­spa­ren­za dei processi e la chiara li­mi­ta­zio­ne del mul­ti­ta­sking sono oltremodo sensati.

Kanban non è ap­prez­za­to solo per i vantaggi che comporta, ma anche per la sua facile im­ple­men­ta­zio­ne. Le dif­fi­col­tà iniziali sono davvero poche. Un team o un’azienda devono adottare solo pochi cam­bia­men­ti iniziali per im­ple­men­ta­re Kanban. Per prima cosa bisogna pro­cu­rar­si una Kanban Board, che può essere adattata gra­dual­men­te, e adottare il metodo pull. Il metodo può e deve essere poi affinato dal team a poco a poco: quali regole si vogliono stabilire per il processo? Quali limiti si applicano? In che modo volete rea­liz­za­re la vostra Kanban Board?

Inoltre Kanban è in generale un sistema molto libero, che prevede poche regole. Non ci sono né pro­gram­ma­zio­ni né ruoli specifici, presenti invece in Scrum. Per questo motivo Kanban si può uti­liz­za­re in ogni si­tua­zio­ne. Ciò vale sia per i team grandi che per quelli piccoli. Perfino le singole persone possono or­ga­niz­za­re meglio il proprio flusso di lavoro con Kanban.

• Team piccoli: i piccoli gruppi di lavoro si or­ga­niz­za­no spesso secondo pre­sen­ta­zio­ni agili. Si può fa­cil­men­te integrare Kanban per strut­tu­ra­re meglio i processi la­vo­ra­ti­vi e aumentare l’ef­fi­cien­za.
• Grandi aziende: per le aziende grandi e con­so­li­da­te è molto più difficile in­cor­po­ra­re nuovi processi. Ed è proprio per questo che Kanban è l’ideale per iniziare. Questo metodo semplice e aperto può essere integrato a poco a poco.
• Persone singole: Kanban aiuta nell’or­ga­niz­za­zio­ne dei compiti anche le persone singole, le imprese in fase di av­via­men­to e i freelance.

I co­sid­det­ti flight level rap­pre­sen­ta­no gli ordini di grandezza con cui Kanban può essere adottato in un’azienda. Il dott. Klaus Leopold, un altro pioniere di Kanban, spiega in tre diverse fasi a che livello Kanban può sup­por­ta­re i processi la­vo­ra­ti­vi:

• Flight level 1 – Livello operativo: A questo livello, il più basso, si trova il team di spe­cia­li­sti che ogni giorno è impegnato a rea­liz­za­re il prodotto o a fornire il servizio. Spesso questi team con­tri­bui­sco­no solo in modo parziale al prodotto finito. In altre parole ciò significa che i compiti arrivano a questi team come pacchetti che devono poi essere suddivisi in piccoli compiti prima di poterci lavorare. Se tuttavia solo un team in azienda lavora secondo il modello Kanban, po­treb­be­ro sorgere dei problemi con gli altri gruppi di lavoro che seguono invece un metodo non agile come il modello a cascata.
• Flight level 2 – Coor­di­na­zio­ne: al secondo livello troviamo la coor­di­na­zio­ne tra i team. Con Kanban ci si assicura che tutti i team portino a termine i compiti nella giusta sequenza e che abbiano sempre del lavoro. Così ogni team non è né so­vrac­ca­ri­ca­to né privo di lavoro.
• Flight level 3 – Gestione stra­te­gi­ca del portfolio: si raggiunge il terzo livello quando si coordina non solo un progetto con Kanban, ma l’intero portfolio con il metodo agile. È la gestione a decidere con quale progetto iniziare. Ciò può mi­glio­ra­re tutti i processi aziendali.

Inoltre Kanban è così aperto che si può fa­cil­men­te collegare ad altri metodi. È molto diffusa ad esempio la com­bi­na­zio­ne di Kanban con Scrum. Lo stesso Scrum è un sistema piuttosto re­strit­ti­vo, il cui framework dona al team direttive precise. Dato che Kanban è un metodo aperto, si lascia fa­cil­men­te integrare nel regolare processo di Scrum.

Tuttavia ci sono delle dif­fe­ren­ze tra i due metodi: se Scrum mette in primo piano il team, Kanban si concentra di più sul processo di pro­du­zio­ne e sul risultato per il cliente. Sotto altri punti di vista i due sistemi si com­pen­sa­no: i meeting frequenti stabiliti da Scrum non sono previsti tas­sa­ti­va­men­te da Kanban, ma si adattano molto bene all’idea del feedback prevista dal metodo.

I vantaggi di Kanban sono già indicati nella de­scri­zio­ne del metodo: semplice in­te­gra­zio­ne, mi­glio­ra­men­to continuo dei processi la­vo­ra­ti­vi, elevata tra­spa­ren­za. Ci sono però anche aspetti che sco­rag­gia­no i team. Ad esempio è as­so­lu­ta­men­te ne­ces­sa­rio sud­di­vi­de­re il lavoro in fasi. Al­tri­men­ti il completo sistema perde il suo senso.

Un altro motivo per cui il metodo non è la scelta giusta per ogni team emerge da un vantaggio del sistema: le li­mi­ta­zio­ni del work in progress servono a rendere subito visibili i problemi presenti in una fase e poter spostare fa­cil­men­te le risorse. Questo tuttavia è possibile solo se le risorse si possono ef­fet­ti­va­men­te spostare. I com­po­nen­ti del team devono essere in grado di poter lavorare in diverse fasi. Al­tri­men­ti si entra in un vicolo cieco e se da una parte il team viene so­vrac­ca­ri­ca­to, dall’altra è privo di lavoro: esat­ta­men­te il contrario di quello che è lo scopo di Kanban.