efficienza | Il Project Management & l'arte della Maratona

Limitare per accelerare: il beneficio controintuitivo di limitare il lavoro in corso in Kanban

L’adozione di Kanban in team appartenenti a contesti lavorativi anche diversi offre benefici significativi in termini di gestione più efficiente del flusso di lavoro, maggiore produttività, tempi di lavorazione ridotti e miglioramento della collaborazione. Tuttavia, questi vantaggi non sempre risultano evidenti quando spiegati in teoria; ecco perché strumenti di simulazione come Featureban si rivelano particolarmente efficaci.

Featureban è un gioco ideato da Mike Burrows che permette ai partecipanti di sperimentare il funzionamento del flusso di lavoro in un contesto simulato, imparando i principi e le pratiche di Kanban in modo concreto e coinvolgente. Una delle caratteristiche più interessanti di Featureban è la sua capacità di dimostrare come la semplice introduzione di limiti al lavoro in corso (Work In Progress – WIP) tra una iterazione e l’altra del gioco possa trasformare il comportamento del team, stimolando collaborazione e migliorando le performance.

Sperimentare la meccanica di base di un sistema Kanban

In Featureban, i partecipanti operano all’interno di un flusso di lavoro rappresentato su una board Kanban, completando attività simulate. Non viene svolto alcun lavoro reale, l’avanzamento o il blocco delle attività dipende dal caso, tramite il sorteggio di carte casuali o il lancio di una moneta, applicando poi delle semplici regole fisse in base ai risultati ottenuti. Ogni azione nel gioco è quindi determinata esclusivamente dalla meccanica del flusso. Un aspetto interessante è che, tra le regole, ce n’è una che va volutamente controcorrente rispetto alla collaborazione: i giocatori possono aiutarsi tra loro solo come ultima risorsa, quando non vi sono altre opzioni disponibili.

Nella prima iterazione, non vengono imposti limiti al lavoro in corso, e in questo scenario iniziale si sviluppa la dinamica tipica, amplificata dalle regole del gioco, in cui ogni giocatore lavora individualmente mentre le attività tendono ad accumularsi durante la fase di lavorazione, provocando congestione e inefficienze.

L’impatto dell’introduzione dei limiti al lavoro in corso

Dopo la prima iterazione, viene quindi introdotto un limite al numero di attività che possono essere in corso contemporaneamente. Questo piccolo cambiamento ha effetti sorprendenti e immediatamente visibili:

Maggiore collaborazione spontanea: con il limite lavoro in corso, i giocatori devono gestire il proprio lavoro in modo più strategico, comprendendo che il completamento di un’attività libera spazio per nuove iniziative. Di conseguenza, la collaborazione diventa un comportamento naturale e frequente.
Stabilizzazione del flusso: riducendo l’accumulo di attività in corso, il lavoro procede in maniera più regolare e prevedibile, evitando le inefficienze.
Aumento della produttività: il numero di attività completate nella seconda iterazione cresce, poiché i giocatori si concentrano sulla conclusione anziché sull’avvio di nuove attività.
Diminuzione del tempo di lavorazione: con meno attività in corso, ogni elemento del flusso attraversa la board più rapidamente, riducendo il tempo necessario per completare una singola attività.

Sbloccare il flusso: meno lavoro in corso, più produttività

Uno degli aspetti che più colpisce i partecipanti alla simulazione è sperimentare direttamente e concretamente un concetto controintuitivo: limitare il lavoro in corso aumenta l’efficienza complessiva. Istintivamente si tende a pensare che avviare più attività porti a una maggiore produttività. Tuttavia, Featureban dimostra in modo plastico che quando troppe attività sono in corso contemporaneamente, il flusso di lavoro si congestiona, causando un aumento dei tempi di attesa e riducendo la quantità di lavoro completato. Limitando il lavoro in corso, viceversa, si ottiene un flusso più stabile e prevedibile, con una diminuzione dei tempi di attesa e un aumento significativo della quantità di lavoro completato.

Un’altra sorpresa per i partecipanti è che, nella seconda iterazione, anche la regola che permette ai giocatori di aiutarsi tra loro solo come ultima risorsa, anziché limitare la collaborazione, contribuisce, insieme al limite sul lavoro in corso, a garantire la stabilità del flusso. Questo dimostra come regole ben congegnate e condivise possano essere decisive per mantenere il flusso stabile.

Sperimentare le altre pratiche di Kanban

Oltre alla limitazione del lavoro in corso, Featureban consente di applicare le altre cinque pratiche generali di Kanban. I partecipanti possono sperimentare la visualizzazione del lavoro, rappresentando il flusso sulla board e sviluppando una maggiore consapevolezza sulle sue dinamiche; la gestione del flusso, osservando come le attività progrediscono e imparando a gestire i blocchi; la definizione esplicita delle policy, creando insieme le regole che favoriscono la collaborazione e l’efficienza del flusso; l’implementazione di cicli di feedback, esaminando i risultati tra una iterazione e l’altra; e il miglioramento evolutivo e sperimentale, adattando le strategie di gioco per ottimizzare il sistema. Questo approccio esperienziale aiuta a interiorizzare i principi fondamentali di Kanban e a comprenderne il valore nel lavoro quotidiano.

Risultati e applicazioni pratiche

Featureban dimostra in modo chiaro ed efficace che la gestione dei limiti al lavoro in corso non si limita a controllare e stabilizzare il flusso, ma agisce anche come un catalizzatore per la collaborazione e il miglioramento continuo. Nella pratica aziendale, l’adozione di Kanban e l’introduzione dei limiti al lavoro in corso supportano i team nel lavorare in maniera più coesa ed efficiente, migliorando la prevedibilità e la qualità dei risultati.

In conclusione, la simulazione con Featureban permette di vivere direttamente gli effetti positivi di una gestione consapevole del flusso di lavoro. Comprendere e sperimentare in prima persona questi concetti rende molto più semplice il loro trasferimento nella pratica quotidiana, portando benefici concreti ai team e alle organizzazioni.

Prossimi eventi

Se questo articolo vi ha incuriosito, il prossimo 28 marzo a Milano terremo un workshop in cui potrete prendere parte a questa simulazione. Un’opportunità per sperimentare in prima persona i principi di Kanban e scoprire i vantaggi di una gestione efficace del flusso di lavoro!

Potete iscrivervi cliccando qui.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

L’Arsenale di Venezia: un sistema Kanban ante litteram

L’Arsenale di Venezia, un tempo il più grande complesso industriale d’Europa, e il metodo Kanban potrebbero sembrare non avere alcuna correlazione. Tuttavia, un’analisi più attenta e approfondita rivela sorprendenti somiglianze e interessanti spunti di riflessione. L’esempio che sto per raccontarvi ci condurrà alla scoperta di una straordinaria storia che affonda le sue radici nel passato.

Un modello pionieristico di produzione industriale

L’Arsenale di Venezia, fondato nel XII secolo, rappresenta uno dei primi e più avanzati esempi di complesso industriale integrato nella storia. Si trattava di un cantiere navale gestito dalla Repubblica di Venezia, specializzato nella costruzione e nella manutenzione delle navi da guerra e mercantili della Serenissima. Per secoli, è stato il cuore pulsante della potenza marittima veneziana, grazie a una straordinaria organizzazione del lavoro che anticipava molti dei principi della produzione industriale moderna.

Con una forza lavoro che raggiungeva le 16.000 unità, l’Arsenale era in grado di costruire e allestire una galea al giorno, grazie a un’organizzazione del lavoro altamente specializzata e a una divisione delle fasi produttive. Questa struttura permetteva una produzione efficiente e standardizzata delle navi.

L’entrata dell’Arsenale dipinta da Canaletto, 1732

L’organizzazione della produzione nell’Arsenale di Venezia

L’Arsenale funzionava come una gigantesca macchina produttiva, organizzata secondo un modello che garantiva velocità, efficienza e qualità nella costruzione delle navi. La produzione era suddivisa in una serie di fasi altamente specializzate, ciascuna affidata a operai esperti detti “arsenalotti”. Questi artigiani erano suddivisi in corporazioni a seconda del loro ruolo nel processo produttivo.

La gestione del flusso di lavoro

La costruzione di una nave all’interno dell’Arsenale seguiva un percorso ben definito, che prevedeva le seguenti fasi principali:

Preparazione del legname: Il legno proveniva dalle foreste del Cadore e di altri territori sotto il controllo della Serenissima. Dopo essere stato selezionato e stagionato, veniva trasportato all’Arsenale per essere lavorato.
Assemblaggio dello scafo: Gli operai specializzati nelle strutture in legno lavoravano con una precisione quasi standardizzata. L’impiego di modelli e tecniche di produzione ripetitive permetteva di costruire scafi in tempi rapidi.
Placcatura e rinforzi: Dopo la realizzazione dello scheletro della nave, si procedeva alla placcatura esterna con tavole di legno, fissate con chiodi e resine impermeabilizzanti. Le navi veneziane erano rinomate per la loro robustezza e leggerezza.
Installazione delle sovrastrutture e dell’attrezzatura di bordo: In questa fase venivano installati gli alberi, le vele, i remi e le decorazioni, oltre alle cabine per l’equipaggio e i capitani.
Armamento e rifinitura: Le navi da guerra erano dotate di cannoni e altre attrezzature belliche prima di essere varate e messe in servizio.

Questa suddivisione del lavoro consentiva di realizzare una galea in tempi straordinariamente brevi per l’epoca, arrivando, nei momenti di massima efficienza, a costruire una nave al giorno.

Un sistema Kanban ante litteram

Uno degli aspetti più innovativi dell’Arsenale di Venezia era la sua capacità di funzionare in maniera simile a un moderno sistema di produzione Kanban. Il processo di costruzione delle navi era altamente standardizzato e suddiviso in reparti specializzati, con un flusso di materiali e manodopera ottimizzato per garantire la massima produttività.

Gli arsenalotti utilizzavano un sistema di prefabbricazione in cui le diverse sezioni della nave, come ordinate, paratie e fasciame, venivano prodotte separatamente e contrassegnate con numeri o segni distintivi. Queste parti venivano poi trasportate nei punti di assemblaggio finale, dove venivano montate in sequenza, riducendo significativamente i tempi di costruzione. La numerazione delle parti facilitava il lavoro degli operai specializzati, assicurando che ogni componente fosse posizionato correttamente senza margine di errore.

A differenza di altri cantieri navali dell’epoca, dove la costruzione avveniva in modo artigianale e disperso, nell’Arsenale veneziano la produzione era centralizzata e organizzata in una sequenza precisa. Questa innovazione permetteva di ottenere navi di qualità uniforme e di ridurre i tempi di realizzazione, garantendo a Venezia una flotta costantemente rinnovata e aggiornata.

La gestione delle risorse e il controllo della qualità

La Repubblica di Venezia esercitava un controllo rigoroso sulle risorse necessarie alla produzione navale. Le materie prime, come il legno, il ferro e la pece, erano gestite direttamente dallo Stato, che ne garantiva la disponibilità e la qualità. Anche la manodopera era regolata da un sistema preciso: gli arsenalotti godevano di salari stabili e privilegi che li incentivavano a trasmettere le loro competenze alle nuove generazioni.

Inoltre, ogni fase della costruzione era soggetta a controlli rigorosi per garantire la massima qualità delle imbarcazioni. La Serenissima aveva compreso l’importanza della standardizzazione e della manutenzione preventiva per mantenere la propria supremazia marittima.

Valori del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia

Il metodo Kanban si basa su valori e pratiche che possiamo sorprendentemente ritrovare nell’organizzazione dell’Arsenale di Venezia. Di seguito analizziamo le principali corrispondenze.

1. Trasparenza

Kanban enfatizza la trasparenza dei processi di lavoro attraverso strumenti visivi, come le Kanban board. Allo stesso modo, nell’Arsenale di Venezia, l’organizzazione della produzione era chiara e strutturata:

Le diverse fasi della costruzione navale erano visibilmente organizzate nei vari reparti dell’Arsenale.
Ogni lavoratore sapeva esattamente quale fosse la sua mansione e il contributo alla fase produttiva.

2. Collaborazione

Il metodo Kanban incoraggia la collaborazione tra team per migliorare il flusso di lavoro. L’Arsenale era un esempio di lavoro collettivo su larga scala:

Le diverse corporazioni di mestieri (falegnami, calafati, fabbri, velai) collaboravano strettamente per completare ogni nave nel minor tempo possibile.
Il processo produttivo era suddiviso in team specializzati che operavano in modo interdipendente, simile ai team Kanban moderni.

3. Equilibrio

Kanban aiuta a bilanciare la domanda e la capacità produttiva. L’Arsenale manteneva un equilibrio attraverso:

Produzione su richiesta, evitando scorte eccessive. Le navi venivano costruite in base alle esigenze della Repubblica di Venezia, evitando surplus inutili.
Una gestione delle risorse centralizzata, assicurando che ogni reparto ricevesse materiali in modo coordinato.

4. Focalizzazione sul cliente

Il metodo Kanban incoraggia a lavorare su ciò che porta valore al cliente finale. L’Arsenale aveva una forte attenzione al bisogno della Serenissima:

La produzione di navi era ottimizzata per garantire potenza navale e velocità di risposta alle esigenze militari e commerciali di Venezia.
La capacità di costruire una galea al giorno era una risposta diretta alle necessità strategiche di difesa e commercio.

5. Leadership a tutti i livelli

Kanban valorizza il ruolo di ogni membro del team nel miglioramento continuo. Anche nell’Arsenale:

Gli arsenalotti non erano semplici operai, ma specialisti altamente qualificati, il cui sapere era tramandato di generazione in generazione.
L’organizzazione del lavoro lasciava spazio all’iniziativa individuale, permettendo ai maestri d’arte di migliorare continuamente le tecniche costruttive.

Pratiche del metodo Kanban riconoscibili nel sistema dell’Arsenale di Venezia

1. Visualizzare il lavoro

Nel metodo Kanban, i flussi di lavoro vengono visualizzati su una board. Nell’Arsenale:

Il layout fisico dell’Arsenale permetteva una visualizzazione naturale, dove ogni fase di costruzione aveva una posizione ben definita.
Le navi in costruzione erano assemblate lungo un canale e le attività assegnate a ogni squadra erano chiaramente visibili.

2. Limitare il lavoro in corso (WIP – Work In Progress)

Il metodo Kanban limita il numero di attività in corso per evitare sovraccarico e sprechi. Nell’Arsenale:

La costruzione era organizzata per fasi specifiche e sequenziali, evitando congestioni di lavoro.
Il numero di navi in produzione era attentamente regolato per non sovraccaricare le risorse e ottimizzare i tempi.

3. Gestire il flusso di lavoro

Kanban aiuta a identificare colli di bottiglia e ottimizzare il flusso. Nell’Arsenale:

La suddivisione del lavoro in reparti specializzati assicurava un flusso regolare e prevedibile della produzione.
Ogni squadra di operai riceveva i materiali e i componenti nel momento giusto, garantendo un processo continuo, l’Arsenale era sostanzialmente un sistema ‘pull’.

4. Rendere le regole di processo esplicite

Kanban suggerisce di rendere le regole operative chiare per tutti. Nell’Arsenale:

Il lavoro era rigidamente regolato da norme statali e procedure definite.
I mestieri erano organizzati in corporazioni con ruoli e compiti ben definiti, simili alle policy documentate nei sistemi Kanban.

5. Implementare feedback loop

Nel metodo Kanban, i feedback sono la vera e propria catena di trazione del miglioramento continuo. Nell’Arsenale:

La produzione era monitorata costantemente, per correggere errori e ottimizzare i processi.
Venezia investiva nella formazione continua degli arsenalotti, trasmettendo le conoscenze per migliorare le tecniche produttive.

6. Migliorare collaborando ed evolvere sperimentando

Il metodo Kanban incoraggia cambiamenti incrementali per ottimizzare il sistema. Nell’Arsenale:

I metodi di costruzione delle navi si evolvevano continuamente, adattandosi alle nuove esigenze belliche e commerciali.
L’innovazione tecnologica era costante, con l’introduzione di miglioramenti nei materiali e nelle tecniche di assemblaggio.

Conclusione

L’Arsenale di Venezia rappresentava un modello industriale e di organizzazione del lavoro sorprendentemente vicino ai principi di Lean e del metodo Kanban. La suddivisione delle fasi produttive, la gestione del flusso, il controllo delle risorse e della qualità hanno reso questo straordinario cantiere navale uno dei più avanzati della storia.

Il modello produttivo veneziano non solo garantì alla Serenissima una flotta potente ed efficiente, che dominò i mari per quasi un millennio, ma gettò anche le basi per quelli che sono stati i successivi sviluppi nel campo della produzione industriale. Sebbene sviluppato in un contesto preindustriale, il metodo veneziano dimostra come l’efficienza nella gestione del lavoro sia un principio senza tempo.

Fonti sull’organizzazione del lavoro nell’Arsenale di Venezia:
Giovanni Caniato – L’Arsenale: maestranze e organizzazione del lavoro – Treccani
Carlo Gatti – L’Arsenale di Venezia – Mare Nostrum

Scrum applicato in azienda: ridurre il carico del team per aumentarne l’efficienza

Un team agile, come qualunque sistema di servizio, raggiunge la massima efficienza se non viene caricato oltre i due terzi della propria capacità massima. Un concetto controintuitivo che ci viene spiegato dalla teoria delle code.

Sul concetto di Velocity di un team agile

Chi ha familiarità con le modalità di lavoro agile e i suoi vari framework di riferimento, dovrebbe aver sentito parlare del concetto di Velocity, che è la principale metrica di riferimento che viene utilizzata per misurare quanto lavoro un team di sviluppo può completare con successo nel corso di un intervallo di tempo fisso detto Sprint. Ma sappiamo cosa significa davvero misurare la Velocity di un team?

Il termine, per assonanza, tende a essere sempre tradotto con “velocità” per cui la metrica nella percezione comune diventa la “velocità del team“ e la sensazione è che il team debba ricercare la propria efficienza, che però per il modo di pensare agile è un controsenso.

In un contesto di lavoro agile infatti, quale per esempio Scrum, quello che importa non è tanto l’efficienza del team quanto la sua capacità di permettere al proprio cliente, in Scrum rappresentato dal ruolo del Product Onwer, di ottenere i risultati che creano valore per il cliente stesso.

Questi risultati che creano valore in inglese sono detti Outcome e infatti si dice che le metriche per misurare un team agile devono essere Outcome based.

Per fare un esempio semplice ma efficace del concetto appena espresso, in un contesto agile a nessuno importa quanto un team sia efficiente a piantare chiodi o ad avvitare viti, quello che importa è la capacità di appendere quadri nel modo desiderato dal proprio Product Owner entro un tempo ragionevole previsto dal team e utile al Product Owner.

Siamo allora sicuri che “velocità” sia la traduzione corretta per il termine Velocity? Anche perché chiunque conosca un inglese anche elementare sa che normalmente “velocità” si traduce con “speed”. E quindi?

La spiegazione sta in un’altra delle mie passioni sportive, la barca a vela. Perché la parola Velocity in realtà è un termine nautico con un significato ben preciso e tutto mi fa pensare che chi ha adottato questo termine per i team agili abbia voluto utilizzare una metafora sportiva e in particolare velica, che però è risultata talmente sottile che quasi nessuno la ha colta.

La velocità di una barca a vela si misura con due grandezze: la velocità propria della barca nell’acqua (Speed Through Water – STW) che è quella che si percepisce navigando e la velocità effettiva sulla superficie terrestre (Speed Over Ground – SOG) che è quella che ci dice quanto la barca di sta effettivamente spostando. Senza qui addentrarsi in spiegazioni tecniche, le due velocità sono correlate ma non sono quasi mai uguali per via delle dinamiche dell’acqua. Sempre per fare un esempio semplice, si pensi a una barca che naviga contro corrente in un fiume dove c’è una corrente pari alla velocità della barca stessa; la STW sarà positiva, la barca rispetto all’acqua si muove, la SOG sarà nulla, rispetto alla superficie terrestre la barca è ferma.

La STW ci dice quanto rapidamente la barca si muove sull’acqua, quindi ci da un’indicazione di quanto è efficiente il moto della barca, la SOG ci dice quanto rapidamente la barca si muove sulla superfice terrestre, quindi ci da un’indicazione di quanto è efficace il moto della barca. Da notare che entrambe in inglese sono Speed, nessuna delle due è Velocity, che è un concetto ancora diverso. Cosa è la Velocity allora?

Nel disegno ho riportato una spiegazione un po’ semplificata del concetto velico di Velocity.

Una barca non può muoversi contro vento, al massimo può tenere un angolo di circa 45° rispetto alla direzione del vento. Se si vuole quindi raggiungere un obiettivo che sta controvento, occorre bordeggiare, ovvero ‘zigzagare’ come in figura con angoli di 45° rispetto alla direzione del vento e così facendo ci si avvicinerà al punto obiettivo. Quello che ci interessa non è né la STW, né la SOG ma la velocità con cui la barca si avvicina al punto obiettivo, che in inglese viene chiamata appunto Velocity Made good on Course (VMC), che è la componente della SOG che ci sta avvicinando al punto obiettivo.

Quindi il sottinteso di chi ha scelto il termine Velocity è che il team deve misurare la propria capacità relativa di avvicinarsi al punto obiettivo (che fuori di metafora è il risultato che crea valore per il Product Owner) e non tanto la propria efficienza di azione intrinseca (Speed Through Water – STW) ma nemmeno la propria efficacia assoluta (Speed Over Ground – SOG), perché per raggiungere l’obiettivo del Product Owner il team deve saper combinare la propria efficienza ed efficacia con una strategia che permetta di impiegare al meglio gli elementi propulsivi disponibili (il vento) per riuscire a raggiungere l’obiettivo nel tempo più breve possibile, ma senza compromettere il risultato. E chi ha esperienza di navigazione a vela sa bene che questa strategia di impiego degli elementi propulsivi disponibili è l’elemento che fa la differenza tra un buon velista e un principiante ed è più decisiva e importante rispetto a efficienza ed efficacia del mezzo, perché se si sbaglia il percorso o non si capisce come gira il vento e si finisce controvento, la barca si ferma.

Fuori dalla metafora velica, si usa quindi il termine Velocity perché non importa quanto il team agile sia efficiente e nemmeno quanto sia efficace, ma quanto sia complessivamente abile nel progredire il più rapidamente possibile verso gli obiettivi che creano valore per il cliente.