Cos’è Kanban e l’arte di fare di più facendo di meno

Kanban: do more with less
Featured

Cos’è Kanban e l’arte di fare di più facendo di meno

Cos’è Kanban?

La maggior parte delle persone a cui viene posta la domanda “Cos’è Kanban?” risponde che si tratta di una lavagna con dei post-it o della sua versione digitale presente in qualche tool come Trello, Jira, Kanbanize e simili.

Purtroppo (anzi, per fortuna) Kanban è molto di più di una board e fermarsi per mesi o anni allo “stato post-it” non solo non ci permette di cogliere la vera essenza di questo approccio e sfruttarne i benefici ma dopo un pò stanca e inevitabilmente torniamo nella nostra zona di confort ad utilizzare gli approcci che conosciamo così bene.

Una storia d’amore, quella con Kanban, finita ancora prima del primo appuntamento: che peccato! ☹

Forse vale la pena conoscerla un po’ meglio: che ne dici?

Buona lettura!

Il Toyota Production System (TPS).

Negli anni ’40, è l’ingegnere giapponese Taiichi Ohno a introdurre in Toyota dei cambiamenti così radicali da rivoluzionare completamente il modello di produzione industriale, tanto da passare alla storia come il padre del Toyota Production System (TPS) nota in seguito come Lean Production.

 I due pilastri del Toyota Production System, introdotto da Ohno, erano il modello di produzione just-in-time (JIT) e la logica kaizen o del “miglioramento continuo” e lo strumento utilizzato per farli funzionare era kanban.

Il termine kanban è composto dalle due parole giapponesi “kan”, che vuol dire “Visuale” e “ban”, che significa “Segnalino” o “Card”, possiamo quindi tradurre la parola kanban come ”Scheda Visiva” o “Segnalino Visuale”.

In Toyota, questa scheda visuale veniva utilizzata come un “segnale” o un meccanismo di autorizzazione per cui ogni fase “a monte” di un processo era autorizzata a produrre di più solo se riceveva il “segnale” da una fase “a valle” del processo stesso.

Questo meccanismo di permessi “da destra (il processo a valle) a sinistra (il processo a monte)” non solo consentiva alle persone di svolgere il proprio lavoro in modo sostenibile ma rappresentava un potente strumento per guidare il miglioramento continuo.

Un approccio allo sviluppo del Software.

Ispirandosi a Lean e al Toyota Production System, David J. Anderson mette a punto Kanban (con la “K” maiuscola): metodologia di gestione e controllo del processo di sviluppo del software.

Anderson descrive il suo approccio, frutto di anni di studio e ricerche, nel libro “Kanban: Successful Evolutionary Change for Your Technology Business” pubblicato nel 2010.

Vede così la luce l’approccio Kanban applicato al mondo dello sviluppo software.

Kanban è un approccio “Pull” al processo di sviluppo del software che mira a ridurre al minimo il lavoro in corso di svolgimento (o WIP, Work in Progress), rendere continuo e fluido il rilascio di valore al cliente e rappresentare visivamente il flusso di lavoro in tutte le sue fasi.

Una definizione un po’ criptica, vero? Non preoccuparti e continua a leggere e tra un po’sarà tutto più chiaro.

K minuscola o K maiuscola?

In realtà l’una e l’altra ma sapendo che ci riferiamo a due concetti diversi e lo stesso D.J. Anderson chiarisce bene la differenza:

[…] I describe Kanban (capital K) as 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. – David J. Anderson

Per riassumere:

  • kanban system (con la “k” minuscola) è il sistema pull introdotto da Toyota in ambito industriale
  • kanban (con la “k” minuscola) è il “segnale visuale” (fisico o digitale) che il kanban system usa per controllare il Work In Progress
  • kanban board (con la “k” minuscola) è il tool utilizzato originariamente da Toyota (e che noi abbiamo ereditato) per visualizzare e gestire il flusso di lavoro
  • Kanban (con la “K” maiuscola) è la metodologia sviluppata da Anderson che si ispira al kanban system (con la “k” minuscola) di Toyota e utilizza l’insieme di tool di visualizzazione e controllo per sfruttare i vantaggi dell’approccio Lean anche nell’ingegneria del software (e più in generale nel knowledge work), come Toyota aveva fatto nel contesto industriale.
il mio intento è quello di approfondire l’approccio Kanban sviluppato da Anderson per il Knowledge Work ma chiaramente non potranno mancare i riferimenti a Toyota. Da qui in poi, perciò, mi sforzerò di utilizzare la nomenclatura con la “k” minuscola e la “K” maiuscola per rifermi rispettivamente all’approccio Toyota e a quella di Anderson. Utilizzerò la “K” maiuscola anche nei molti casi in cui i concetti espressi valgono sia per l’uno che per l’altro approccio.

PUSH VS PULL.

Kanban: Push vs Pull

Kanban: Push vs Pull

L’approccio PUSH.

Nel modello industriale tradizionale, adottato nel ‘900 anche dall’industria Ford (competitor USA, insieme a General Motors, di Toyota), gli obiettivi principali erano la riduzione dei costi e l’aumento dei volumi di produzione.

La qualità si misurava, non tanto rispetto alla qualità intrinseca del prodotto, quanto piuttosto nella quantità di pezzi prodotti: un concetto di qualità, dunque, relativo agli obiettivi di natura economica dell’azienda non certo alla soddisfazione del cliente.

D’altra parte, una azienda come Ford, lavorava praticamente in assenza di concorrenza quindi, che il cliente fosse soddisfatto o meno, aveva poca importanza perché, di fatto, chi voleva un’auto aveva ben poco da scegliere.

Il modello di produzione adottato era quindi di tipo “PUSH”.

Nella catena di produzione, le persone erano misurate in funzione della velocità con ci completavano il loro lavoro e passavano (o spingevano, “push”) il semilavorato ai colleghi che svolgevano la fase successiva del processo.

In questo modello, la variabile trascurata era la reale capacità di assorbire, completare il lavoro da parte di chi quel lavoro lo riceveva (i colleghi alla nostra “destra” nel processo di produzione), la loro reale capacità produttiva.

Le conseguenze drammatiche erano colli di bottiglia, inefficienze del flusso di lavoro, multitasking a go go e (ulteriore) compromissione della qualità per aumentare la velocità. Tutti elementi che, per Toyota, erano classificabili come “Waste” (letteralmente “sprechi” o MUDA in giapponese).

Se osservi l’immagine seguente, in cui ti mostro gli step del classico ciclo di vita di sviluppo del software (faccio riferimento all’approccio Waterfall o sequenziale o plan-driven o comunque vogliamo chiamarlo), scommetto che ora la parola “Push” ti ricorda qualcosa: sbaglio? 😊

Push Process

Push Process

L’approccio PULL.

La lotta ossessiva verso qualsiasi forma di spreco e il perseguimento maniacale della qualità totale sono tra gli aspetti più caratterizzanti e rivoluzionari dell’approccio di Toyota.

Perché? Semplice: perché sprechi e scarsa qualità erano un costo che, a differenza di General Motors e Ford con la loro “potenza di fuoco” economica, la piccola Toyota non si poteva certo permettere.

L’azienda giapponese sostituisce quindi l’approccio “Push” con quello “PULL”.

Il modello Kanban è “demand driven”: sono le persone a prelevare (o tirare, “Pull”) il lavoro da svolgere quando sono ragionevolmente certe di poterlo completare, senza rendere inefficiente il flusso di lavoro, senza colli di bottiglia, senza compromettere la qualità.

Il processo di produzione è basato sulla reale capacità produttiva delle persone e ogni processo adegua il ritmo di produzione alla velocità con cui il lavoro procede “a valle”.

A Kanban non interessa affatto che le persone siano sempre occupate a fare qualcosa per il 100% del loro tempo se questa impresa titanica non si traduce in valore per il cliente. A Kanban interessa che le persone siano in grado di iniziare, completare e rilasciare valore al cliente il prima possibile (“Stop starting and start finishing”) e, adottare un approccio PULL, è l’unico modo per farlo.

Cos’è Kanban: i valori dietro la board.

Come tutti i framework agili (Scrum incluso), Kanban è un approccio value-driven: i principi e le pratiche Kanban esistono e funzionano solo in contesti abitati da persone che condividono un comune set di valori.

I 9 valori al centro del mindset Kanban sono:

  1. Transparency: La condivisione delle informazioni ci permette di prendere decisioni migliori basate su fatti reali
  2. Balance: l’efficienza del processo richiede il bilanciamento di esigenze diverse (trovare un compromesso tra la domanda, espressa dal cliente e la reale capacità produttiva dei team ne è un esempio)
  3. Collaboration: Kanban ha senso se permette alle persone di lavorare bene insieme
  4. Customer Focus: il flusso di valore che creiamo per il cliente è al centro e rappresenta il nostro focus
  5. Flow: il valore si realizza attraverso un “flusso di lavoro”: visualizzarlo e ottimizzarlo è cruciale per creare prodotti e servizi migliori
  6. Leadership: una leadership sviluppata a tutti i livelli dell’organizzazione è in grado di ispirare gli altri. I comportamenti virtuosi sono “contagiosi”
  7. Understanding: conoscere (se stessi, il proprio team, l’organizzazione e il proprio cliente) è il primo step per il miglioramento
  8. Agreement: perseguire insieme un obiettivo comune richiede rispetto e capacità di armonizzare punti di vista, opinioni e approcci diversi
  9. Respect: Last but not least, valorizzare, comprendere e avere cura delle persone costituisce la base fondante degli altri valori.

Cos’è Kanban: i principi dietro la board.

Kanban si basa su 6 principi fondanti raggruppabili in 2 classi:

  1. Change Management Principles: riguardano principalmente gli aspetti “umani” (psicologici e sociologici) dell’organizzazione
  2. Service Delivery Principles: stressano il concetto di centralità del cliente e del valore che riceve attraverso i nostri servizi.

CHANGE MANAGEMENT PRINCIPLES

SERVICE DELIVERY PRINCIPLES

1. Start with what you do now: “Partire da dove siamo” per ridurre la naturale resistenza al cambiamento riconoscendo che processi, ruoli e responsabilità costituiscono un patrimonio i cui aspetti positivi vanno mantenuti e protetti.

4. Understand and focus on your customers’ needs and expectations: il focus è sempre verso il cliente e le sue necessità.

2. Agree to pursue improvement through evolutionary change: abbracciare il miglioramento attraverso il cambiamento.

5. Manage the work; let people self-organize around it: più le persone sono lasciate libere di auto organizzarsi per gestire il proprio lavoro più saranno in grado di produrre valore.

3. Encourage acts of leadership at every level, from the individual contributor to senior management: stimolare la leadership ad ogni livello dell’organizzazione.

6. Evolve policies to improve customer and business outcomes: le regole sono fatte per essere rotte quando non sono più funzionali agli obiettivi di business, tanto dell’organizzazione quanto del cliente.

Cos’è Kanban: le pratiche dietro la board.

Visualize Work.

L’atto di rendere il lavoro visibile è così importante, nell’ottica lean-kanban, perché ci consente di comprendere come funziona il nostro sistema e trovare potenziali aree di miglioramento. Tutto questo in uno sforzo collettivo di collaborazione.

Se per Toyota, che costruiva auto, rendere visibile il lavoro era così importante quanto può esserlo per noi knowledge workers che, a differenza dell’azienda giapponese, lavoriamo su prodotti “intangibili”?

Perché sia legittimo parlare di un “kanban system” (con la “k” minuscola) e non semplicemente di un “flow system” ad essere visualizzato non deve essere solo il flusso di lavoro ma anche le policy che lo regolano (della pratica “Make Process Policies Explicit” ne parliamo tra un po’), incluse le regole di qualità, ed il WIP Limit.

Come immaginerai, lo strumento principale utilizzato allo scopo di rendere visibile il lavoro è la kanban board.

Kanban in action: la kanban board.

La kanban board è uno strumento, tanto semplice quanto potente, utilizzato per progettare, gestire e migliorare qualsiasi sistema che generi un flusso di valore per i clienti, sia che si tratti della creazione di prodotti fisici (come nel caso di Toyota) sia che si tratti di Knowledge Work.

La kanban board visualizza un flusso di lavoro in cui i singoli work item (attività, task, pezzi da lavorare, ecc.) fluiscono, passando attraverso i vari step del processo, da sinistra (ingresso nel sistema) a destra (item completi potenzialmente rilasciabili al cliente).
Kanban Board Structure

Kanban Board Structure

Una kanban board può essere implementata:

  • fisicamente, utilizzando una parete o una lavagna e, in questo caso gli item saranno rappresentati da card fisiche (di solito si tratta di post-it)
  • digitalmente da una soluzione software tra le tante disponibili sul mercato (Trello, Jira, Kanbanize, ecc.) con gli item rappresentati da card digitali.

La seconda soluzione è sicuramente la più comoda e la più (e a volte l’unica) praticabile per team non co-locati ma è certamente meno efficace, nel coinvolgere le persone e stimolare collaborazione e creatività, rispetto alla seconda soluzione Low Tech, High Touch.

La struttura di base di una kanban board è piuttosto semplice e include i seguenti elementi:

  • COLONNE: che rappresentano verticalmente gli step del processo che vogliamo rappresentare.

In una kanban board sono presenti almeno 3 colonne:

TO DO

DOING (o In Progress)

DONE

Contiene gli item (attività, task o pezzi da lavorare) presenti nel sistema e di cui non abbiamo ancora iniziato la lavorazione.

Include gli item attualmente in lavorazione ma non ancora completi.

La colonna Doing viene spesso suddivisa in tante sotto colonne quanti sono gli step del processo che ci interessa rappresentare (ad esempio, in un processo di sviluppo software, potremmo avere le sotto colonne Analisi, Disegno, Sviluppo Front-End, Sviluppo Back-End, Test, ecc.).

Con gli item completati pronti ad essere rilasciati al cliente.

  • SWIMLANES: corsie orizzontali e opzionali che attraversano due o più colonne e vengono utilizzate per organizzare gli item per tipologia, cliente, classe di servizio, ecc.
  • POLICIES: descrizioni esplicite del comportamento atteso del sistema e dei vincoli a cui è sottoposto. Tra le Policy principali troviamo:
  • il WIP Limit ovvero la quantità massima di Work in Progress ammesso in un certo step del processo, misurato in numero di Work Item (lo vedremo approfonditamente tra poco). Di solito è rappresentato con un numero posto sotto l’intestazione della colonna a cui lo step di processo si riferisce.
  • la Definition Of Done (DoD), l’insieme delle regole di qualità che è necessario soddisfare perché il Work Item possa essere considerato completo e quindi rilasciabile.

Limit Work In Progress (WIP).

Kanban Metrics.

Per comprendere perché per Kanban è così importante limitare il Work in Progress (tanto da dedicare a questo un’intera pratica) è necessario introdurre le principali “metriche di flusso”, visibili anche dalla kanban board, che Kanban ci offre (rimando a futuri post un approfondimento su tutte le altre mtriche Kanban).

Kanban Board with metrics

Kanban Board with metrics

Work in Progress (WIP).

Il Work in Progress è la più importante metrica di flusso, perchè:

  • è in grado di predire quali saranno le performance del nostro sistema
  • tutte le altre metriche vengono calcolate a partire dal WIP
  • la pratica Limit work in progress è totalmente dedicata proprio al WIP.
Per Work in Progress (abbreviato in WiP) intendiamo l’insieme di Work Item (o il loro numero) che sono entrati nel nostro sistema ma non ne sono ancora usciti (perché completati o perché scartati/eliminati).

Per capire cosa significa “Entrati nel sistema” e “Usciti dal sistema”, la prima cosa da fare è chiarire qual è il perimetro del nostro sistema, lo spazio entro il quale ci è consentito di agire e al di fuori del quale non abbiamo alcuna autorità e influenza:

  • Il punto di ingresso è quello che Kanban chiama “Commitment Point”: il punto specifico in cui un Work Item passa dall’essere solo un’idea, un’opzione, un possibile candidato, a qualcosa su cui dobbiamo effettivamente lavorare per completarlo e rilasciarlo. E solo da questo punto in poi che quel Work Item sarà considerato (e contato come) Work in Progress.
  • Il punto d’uscita è in Kanban il “Delivery Point”: il punto del flusso in cui abbiamo completato la lavorazione del Work Item e possiamo rilasciarlo al cliente (oppure a un processo o a un team a valle).
System boundaries

System boundaries

Cycle Time.

Il Cycle Time rappresenta la quantità di tempo che un Work Item trascorre nel sistema come Work in Progress ovvero il tempo necessario al Work Item per attraversare il sistema dal Committment Point al Delivery Point.

Risponde alla domanda: “Quando sarà completato il Work Item?”.

Lead Time.

Il Lead Time è il tempo totale che un cliente attende da quando esprime un’esigenza a quando riceve il prodotto o servizio che la soddisfa. In pratica qualcosa di analogo al Time-to-Market.

Risponde alla domanda: “Quando sarà rilasciato al cliente il Work Item?”.

I termini Cycle Time e Lead Time sono piuttosto ambigui. Alcuni autori si riferiscono al Lead Time, inteso come Time-to-Market, con il termine Customer Lead Time o Flow Time e chiamano il tempo di permanenza di un Work Item all’interno del sistema System Lead Time anziché Cycle Time.

Non esiste una definizione ufficialmente corretta quindi possiamo utilizzare quella che ci piace di più patto di accordarci prima sul significato che vogliamo darle.

Throughput (o Delivery Rate).

Il Throughput è un coefficiente di prestazione che indica la quantità di WIP (numero di Work Item) completati nell’unità di tempo ovvero la misura della velocità con cui i Work Item escono dal sistema.

Risponde alla domanda: “Quanti Work Item riceverà il cliente con il prossimo rilascio?”.

La scelta dell’unità di misura del Throughput da utilizzare è a discrezione del team, del sistema o del contesto organizzativo (ad es. User Stories/Settimana, Funzionalità/Mese o Task/Giorno, ecc.).

Perché limitare il Work in Progress?

Limitare il Work In Progress è probabilmente la pratica più conosciuta di Kanban e, insieme, la più disattesa: migliorare il time-to-market e la produttività riducendo il numero di attività è un concetto controintuitivo e rappresenta uno dei principali ostacoli all’adozione di Kanban.

La verità è che possiamo beneficiare di Kanban solo se il nostro obiettivo è quello di implementare un sistema PULL in cui la domanda è sempre bilanciata con la reale capacità produttiva del sistema e una nuova attività può avere inizio solo se è stata completata la precedente (“Stop starting and start finishing”). E, per implementare un sistema PULL, è necessario limitare il Work in Progress.

Ogni sistema ha una capacità massima (che ci piaccia o meno) e spingere oltre il limite non la farà aumentare. Al contrario, il risultato sarà un aumento dello stress da sovraccarico, la deriva del multitasking con annesso context switching (le persone iniziano a saltellare istericamente da un’attività all’altra senza completarne nessuna), la creazione di colli di bottiglia e attese (in pratica tutta la gamma di ciò che Lean qualifica come Waste/MUDA).

Anche Goldratt, nella sua “Teoria dei Vincoli” ci ricorda che la creazione di un flow subottimale con colli di bottiglia, attese e inefficienze è in grado di rallentare o arrestare l’intero sistema (ne parlo nel mio post su Le Tre Vie di DevOps).

In aggiunta i colli di bottiglia nascondono le inefficienze, impedendoci di capire cosa stia andando storto per correggerlo: come in un fiume in piena, non saremo in grado di capire dov’è il masso che blocca il flusso dell’acqua finché non la dreniamo.

In Kanban nessuna attività può procedere verso destra, verso lo step di processo adiacente, finché altre attività non siano state completate liberando capacità produttiva.

Per gestire questo meccanismo di “autorizzazione” Kanban produce un segnale visivo (il kanban con la “k” minuscola) per segnalare che è possibile prelevare nuovo lavoro.

In una kanban board, questo “segnale” è solitamente rappresentato da un post-it o una digital card, relativi ad un Work Item completato, che migra verso le colonne (step di processo) di destra.

Ogni step del nostro processo avrà un suo WIP Limit (come abbiamo visto indicato da un numero posto sotto il titolo della colonna).

Il WIP Limit ideale è, solitamente, il frutto di un approccio empirico di sperimentazione, misurazione e adattamento in cui non mi addentro qui.

La Little’s Law.

A rafforzare in modo “quantitativo” l’esigenza “qualitativa” di limitare il WIP ci ha pensato John D.C. Little, fisico statunitense, formulando l’omonima Little’s Law, che fa parte della Teoria delle Code ed è espressa dalla formula:

Average WIP = Average Cycle Time * Throughput o, se preferisci, Average Cycle Time = Average WIP / Throughput.

Secondo la Legge di Little tra Cycle Time e WIP esiste un rapporto di proporzionalità diretta il che vuol dire che più item sono presenti in una coda maggiore sarà il tempo di completamento del singolo item.

Ecco quindi chiarito l’apparente paradosso di Kanban: per riuscire a fare di più (velocizzare il flusso di valore per il cliente) dobbiamo fare di meno (limitare il Work in Progress).

Manage Workflow.

Gestire il Workflow, uno dei mantra che Kanban ha ereditato da Lean, vuol dire ottimizzare il flusso di lavoro, rendendolo il più fluido (e prevedibile) possibile, ridurre il time-to-market e eliminare colli di bottiglia, inefficienze e dipendenze esterne (tutte cose che per Lean rappresentano una forma di “spreco”).

In Kanban non si gestiscono le persone, si gestisce il flusso di lavoro: non ci interessa chi sta facendo cosa, ma quanto velocemente il flusso di lavoro scorre attraverso il sistema.

Make Process Policies Explicit.

Esplicitare (rendere visibili) le regole e i vincoli di un sistema è indispensabile per ridurre le ambiguità, le incomprensioni e permetterci di misurare empiricamente e adattare sperimentalmente i nostri processi.

Una buona policy dovrebbe essere semplice, ben definita, visibile, sempre applicata ma modificabile, se necessario.

Tra le Policy più importanti in Kanban troviamo Il WIP Limit e la Definition Of Done.

Implement Feedback Loops.

Il concetto di Feedback Loop è centrale in Lean così come lo è in tutti gli approcci agili e in DevOps: rappresenta lo strumento per migliorare un prodotto, un processo o un servizio raccogliendo e sfruttando le evidenze provenienti dagli stakeholders e dai sistemi con cui si interagisce.

Scrum, ad esempio, prescrive 4 eventi formali per l’inspect e l’adapt di qualche aspetto o artefatto del processo (puoi rinfrescarti la memoria leggendo il mio post sugli Eventi Scrum) e, quando leggi inspect & adapt traduci in feedback loop.

L’approccio Kanban (con la “K” maiuscola) di Anderson, definisce 7 specifiche opportunità di feedback, o cadenze: riunioni e revisioni cicliche che guidano l’evoluzione e l’efficace erogazione del servizio e il cui ritmo dipende dal contesto specifico.

  1. Strategy Review: per selezionare, anche interpretando i segnali che arrivano dal mercato e dal contesto esterno, i servizi da offrire e definire per loro gli opportuni criteri di “fit for scope”
  2. Operations Review: per stabilire il giusto equilibrio tra i servizi offerti, distribuendo le risorse per massimizzare il rilascio di valore allineato alle aspettative dei clienti
  3. Risk Review: per identificare e rispondere a rischi che possono minacciare la corretta erogazione dei servizi
  4. Service Delivery Review: per analizzare e migliorare l’efficacia di un singolo servizio
  5. Replenishment Meeting: per pianificare quali wok item verranno lavorati (entreranno nella coda del sistema) e predisporre le selezioni future
  6. Kanban Meeting: breve meeting quotidiano in cui le persone che partecipano alla creazione del servizio hanno l’opportunità di coordinarsi, auto-organizzarsi e pianificare le loro attività. Di solito svolto in un format “stand up” per forzarne la brevità, stimolare la focalizzazione sugli obiettivi da raggiungere e rimuovere blocchi e impedimenti
  7. Delivery Planning Meeting: per pianificare e monitorare i rilasci ai clienti.

Congruentemente con il principio Kanban “Start with what you do now“, l’implementazione delle sette cadenze non implica necessariamente l’aggiunta di sette nuovi meeting: almeno inizialmente, l’agenda di ogni cadenza potrebbe essere inclusa nei meeting abituali e adattata in base al contesto.

Le due cadenze Replenishment Meeting e Kanban Meeting sono di solito considerate essenziali in ogni implementazione Kanban,

Kanban: agile o non agile?

Non credo che esista una risposta “ufficialmente” corretta a questa domanda, perciò posso offrirti solo il mio punto di vista:

  • Il kanban system (“k” minuscola) non è un approccio agile ma un sistema pull introdotto da Toyota in ambito industriale per rendere efficiente, snello, veloce e continuamente migliorabile il processo produttivo che porta il flusso di valore al cliente.
  • Il Kanban (“K” maiuscola) di Anderson è invece, a mio avviso, un approccio agile (come lo sono Scrum, XP, ecc.) che trasla nel contesto IT le innovazioni portate da Toyota in contesti industriali ed è in linea con i valori espressi dall’Agile Manifesto.
Detto ciò, francamente la questione non mi appassiona in modo particolare: quello di cui sono certa è che Kanban (come Scrum, come XP, ecc.) porta l’”agilità” nelle nostre organizzazioni ben al di la dell’appartenenza più o meno formale e codificata a una famiglia di approcci piuttosto che ad un’altra.

Conclusioni.

Adottare un approccio PULL, limitare il WIP e passare dalla cultura dell’ottimizzazione delle risorse a quella dell’efficienza del flusso è una sfida che richiede un cambio di mindset e genera resistenze ma, utilizzare una kanban board senza farlo equivale a giocare con i post-it su una lavagna.

E tu di che Kanban sei? 😊

Se ti va di condividere con me la tua esperienza o i tuoi dubbi lasciami un commento e sarò felice di parlarne con te.

Le nostre fonti.

No Comments

Give a comment