Il libro di David Anderson, “Kanban,”, cattura fin dalla prima pagina. Con illustrazioni, grafici e conclusioni, la biografia concisa di Anderson svela la metodologia Kanban per gli appassionati della gestione sana dei progetti. La gestione dei progetti diventa intrigante quando narrata dallo sviluppatore del metodo da una prospettiva di prima persona.
Informazioni sull’Autore
Secondo il blog ufficiale della sua azienda, David J Anderson è elencato come presidente di Lean Kanban Inc. È stato un formatore e consulente di gestione sin dai primi anni 2000 e un relatore e ospite di conferenze dal 2005. Anderson ha ricoperto per la prima volta un ruolo manageriale nel 1991, conferendogli ampia esperienza per confrontare onestamente Kanban con Waterfall, Agile, Scrum e altre metodologie di gestione dei progetti.
Ha creato Kanban per elevare il livello del lavoro intellettuale e creativo. Gli obiettivi di Anderson comprendevano la consegna puntuale, l’allineamento del lavoro con obiettivi stabiliti e una gestione efficace delle moderne aziende nel loro complesso. Utilizzando esempi reali di Microsoft, Motorola e Corbis, ha spiegato e dimostrato i principi, i metodi e le istruzioni per implementare Kanban nelle aziende.
Contenuto ed Essenza del Libro
“Kanban: Il Percorso Alternativo verso Agile” è scritto dalla persona che ha inventato Kanban. Il libro è sia interessante che informativo, rivelando il sottile confine tra la filosofia Kaizen (miglioramento continuo), la metodologia Lean (produzione snella) e Kanban (un metodo per conservare risorse umane e materiali).
Kaizen: Una filosofia e un’etica delle relazioni tra i lavoratori in fabbrica e l’amministrazione.
Lean Production: Un sistema di gestione dei progetti creato presso Toyota per eliminare tutti i tempi e i rifiuti di risorse dai processi aziendali.
Kanban: Un metodo di gestione dei progetti che limita il numero di compiti simultanei. Se ci sono persone, strumenti o tempo limitati, Kanban aiuta a distribuire compiti e progetti.
Notevolmente influenzato dalla Teoria dei Vincoli, il libro di Anderson copre ampiamente i limiti WIP, i colli di bottiglia e la capacità di determinare onestamente il carico di lavoro massimo per unità di tempo mantenendo una qualità ottimale.
La Teoria dei Vincoli, sviluppata dal Dr. Eliyahu Goldratt, è una metodologia di gestione per le imprese manifatturiere. L’approccio sistemico di Goldratt per identificare i vincoli nelle aziende aiuta a semplificare ogni cosa. Secondo l’esperienza di Goldratt, la politica dell’azienda diventa spesso il vincolo principale.
Limite WIP (Work in Progress): Il numero di compiti che possono essere aperti simultaneamente.
Collo di bottiglia: Un punto nel flusso di lavoro dove c’è un serio vincolo su risorse o capacità. Nei diagrammi, assomiglia al collo stretto di una bottiglia, con linee che si allargano prima e dopo tale situazione.
Stereotipi su Kanban
Quando sentiamo parlare di Kanban, spesso immaginiamo una bacheca con note adesive — uno stereotipo perpetuato dai media. Simbolicamente, c’è un elenco di compiti aperti, in corso e completati sul muro. Possono essere utilizzate pareti virtuali e software di gestione dei progetti, dove vengono inseriti elenchi di compiti, priorità e altre sfumature.
In questa metodologia, Kanban non è solo una bacheca o note adesive ma un processo di controllo e trasferimento dei compiti sul muro. Anderson spiega chi muove gli adesivi, perché e quanti possono essere mantenuti nella colonna “in corso” e perché limitare questo numero sia importante.
Kanban non è una bacheca con note adesive; le note adesive sono semplicemente indicatori di carico di lavoro.
Anderson ha sviluppato Kanban per prevenire l’inizio di nuovi progetti prima di completare quelli precedenti. Ad esempio, se un sviluppatore può gestire 3 – 5 compiti alla volta, può prendersi un nuovo compito solo dopo averne completato uno.
Agile, Scrum e Kanban
Anderson ritiene che le metodologie Agile e Scrum siano rigide e predeterminate. A suo avviso, la gestione dei progetti dovrebbe essere personalizzata per ogni azienda. Pertanto, Agile e Scrum, con i loro algoritmi d’azione standardizzati, sono superati, proprio come la classica metodologia Waterfall passo dopo passo. Kanban, d’altra parte, si adatta alle caratteristiche uniche di un’azienda, il che può spaventare gli sostenitori della metodologia Agile.
Agile: Una metodologia flessibile che storicamente ha iniziato lo sviluppo software nel formato di rilascio di aggiornamenti ogni pochi mesi. Iterazioni di poche settimane per ogni funzionalità accelerano lo sviluppo e riducono i rischi.
Scrum: Un’altra metodologia flessibile con iterazioni brevi e un controllo significativo sul processo di programmazione. Ci sono sprint — segmenti di tempo con compiti specifici da completare. Sono rigorosamente limitati. Ci sono backlog — elenchi di compiti distribuiti dal proprietario del prodotto. Il proprietario del prodotto non fa parte del team di sviluppo ma stabilisce le priorità dei compiti.
Waterfall: Un modello classico di gestione dei progetti con una sequenza rigorosa di azioni. Viene spesso spiegato con l’analogia della costruzione edilizia dalla fondazione al tetto.
Qualità Letteraria
Le recensioni dell’originale inglese di “Kanban” di David Anderson sono simili: tutti menzionano che l’autore spiega:
- Come è stato creato il metodo, perché e con chi è stato sviluppato.
- Chi né beneficia e chi né ha assolutamente bisogno.
- Come applicarlo per ottenere risultati.
“Kanban” è scritto nel modo della buona letteratura aziendale. Include conclusioni alla fine di ogni capitolo, e tutti i capitoli affrontano logicamente ogni possibile domanda che un lettore potrebbe avere in un ordine logico.
Il Capitolo 20, “Gestione dei Problemi e Regole di Escalation,” mi ha colpito particolarmente. Differenziare un collo di bottiglia da un compito bloccato è ovvio, ma quanto spesso confondiamo l’uno con l’altro e cerchiamo di spingere attraverso un vicolo cieco? Se un compito non può essere risolto ora, affronta la causa principale. Ecco una citazione dal libro:
“Un compito bloccato forma effettivamente un collo di bottiglia che limita il flusso. Tuttavia, non è la stessa cosa del collo di bottiglia descritto nel Capitolo 17 perché non è un vincolo delle risorse e non è una risorsa che aspetta di accedere. Allo stesso modo, un tappo non è un collo di bottiglia. Per ripristinare il flusso di liquido dalla bottiglia, basta rimuovere il tappo.”
Verdetto
Certamente vale la pena leggerlo, sarà benefico per:
- Imprenditori che lottano per gestire tassi di produzione crescenti.
- Direttori di aziende IT insoddisfatti di Scrum.
- Manager senior e team leader.
- Marketer ossessionati dai KPI ma incerti sulla loro efficacia.
- Team di startup che necessitano di fare tutto bene fin dall’inizio senza “reinventare la ruota,” nel codice, nella vita e nei progetti.