Tag: kanban

Pubblicato il

Il legame indissolubile tra leadership e responsabilità nel Metodo Kanban

Nel contesto dinamico del metodo Kanban, la leadership e la responsabilità emergono come due facce della stessa medaglia, intrinsecamente collegate per guidare il cambiamento evolutivo e il successo organizzativo. In questo senso voglio approfondire quanto già introdotto nel precedente articolo, che potete rileggere qui.

L’immagine (fonte: Kanban University) evidenzia quanto sia fondamentale, per promuovere una leadership efficace a tutti i livelli, delegare le responsabilità verso i livelli più operativi dell’organizzazione.

La leadership come atto di responsabilità a ogni livello

Contrariamente a una visione tradizionale che confina la leadership ai vertici gerarchici, in un sistema Kanban, la leadership è definita principalmente come un atto, un’azione, non semplicemente una posizione. Si manifesta nella capacità di ispirare gli altri all’azione attraverso l’esempio, le parole e la riflessione. In quest’ottica, la responsabilità diventa un elemento fondante della leadership. Chiunque intraprenda un’azione per il miglioramento, per risolvere un problema o per far progredire il lavoro si assume una responsabilità.

La leadership è necessaria a tutti i livelli per raggiungere la creazione di valore e il miglioramento continuo. Incoraggiare atti di leadership significa quindi promuovere un ambiente in cui gli individui si sentano autorizzati e motivati a contribuire con le proprie idee e a prendere iniziativa. Questa presa di iniziativa è intrinsecamente legata alla responsabilità di portare avanti le azioni intraprese.

La responsabilità come fondamento del cambiamento evolutivo

La leadership è un elemento chiave nella formula per il cambiamento evolutivo, che include uno stressor, un meccanismo di riflessione e, appunto, un atto di leadership. Senza una leadership attiva, i momenti di riflessione potrebbero non tradursi in azioni concrete. La responsabilità dei leader, a tutti i livelli, è quella di catalizzare le discussioni e spingere all’azione per affrontare le sfide.

L’impedimento al miglioramento è spesso una mancanza di leadership, e questa mancanza è frequentemente dovuta a una mancanza di responsabilità. Un’organizzazione che valorizza la leadership a tutti i livelli deve di conseguenza promuovere una cultura di accountability, dove gli individui sono ritenuti responsabili delle proprie azioni e dei risultati dell’organizzazione (ho spiegato il concetto di accountability in un articolo che potete rileggere qui).

È importante distinguere tra il prendere responsabilità per le azioni e l’accettare la responsabilità per i risultati. Una maturità organizzativa più profonda richiede individui con una motivazione altruistica e orientata al servizio, che comprendano l’impatto del loro comportamento sugli esiti collettivi dell’organizzazione. L’accountability non avviene magicamente; richiede meccanismi di feedback per riflettere sugli esiti e sulle azioni individuali.

È fondamentale che ci siano persone disposte ad assumersi la responsabilità in prima persona, agendo con affidabilità, mettendosi in gioco concretamente (“skin in the game”) e accettando rischi personali. Questo approccio è basato sul pensiero di Nassim Nicholas Taleb che, nel suo libro Skin in the Game, esplora i principi chiave alla base di resilienza, robustezza e antifragilità.

La maturità della leadership e la crescita della responsabilità

Il Kanban Maturity Model (KMM) illustra come la maturità della leadership sia strettamente legata alla maturità organizzativa. I diversi livelli di maturità della leadership descrivono anche differenti approcci alla responsabilità.

  • In organizzazioni non strutturate o poco strutturate, la leadership è “Abdicated”, si osserva una mancanza di responsabilità da parte dei leader, che evitano di prendere decisioni.
  • In presenza di maggiore maturità organizzativa, la leadership diventa più attiva e responsabile nel guidare il cambiamento e nel prendersi cura del benessere delle persone e dell’organizzazione.
  • In organizzazioni ad elevata maturità organizzativa, leader guidati da uno scopo elevato (“Purpose-Driven/Altruistic”), dimostrano una forte responsabilità verso l’intera organizzazione e il suo valore.

La responsabilità nei ruoli di leadership formali

Anche se la leadership non è confinata ai soli ruoli gerarchici, le figure con responsabilità formali, come i manager, hanno un ruolo cruciale nel dimostrare leadership attraverso la responsabilità per i risultati e per il seguito concreto che viene dato alle iniziative di miglioramento. Una delle situazioni spesso osservate è che i manager percepiscono il loro ruolo come quello di ‘massimizzare l’utilizzo delle persone per tenerle occupate’, piuttosto che concentrarsi sui risultati e sulla soddisfazione del cliente. Per questo agiscono come semplici ‘assegnatori di compiti’, senza assumersi la responsabilità di comprendere le dinamiche del business e del flusso di lavoro e di guidarne il miglioramento continuo.

L’introduzione di ruoli specifici come il Flow Manager e il Delivery Manager in un sistema Kanban sottolinea ulteriormente l’importanza di definire e assegnare precise responsabilità per supportare il flusso di lavoro e la maturità organizzativa.

Guidare con i valori: un atto di responsabilità etica

Per sviluppare una leadership efficace e responsabile, è anche fondamentale guidare con i valori. I leader hanno la responsabilità di introdurre i giusti valori culturali all’interno dell’organizzazione e di agire come esempio, promuovendo comportamenti allineati a tali valori. Questa responsabilità etica è cruciale per costruire una cultura di fiducia e per garantire che la leadership sia orientata al bene comune dell’organizzazione.

Conclusione

In sintesi, la leadership nel metodo Kanban è intrinsecamente legata alla responsabilità. Essere un leader significa agire, prendere iniziativa e, di conseguenza, assumersi la responsabilità delle proprie azioni e dei risultati collettivi. Una cultura che promuove la leadership a tutti i livelli è una cultura che incoraggia la responsabilità individuale e collettiva.

La maturità della leadership, che si sviluppa di pari passo con la capacità di assumersi responsabilità sempre maggiori, è un fattore determinante per la crescita e il successo di un’organizzazione che adotta il metodo Kanban. Coltivare leader responsabili, a ogni livello, è quindi un investimento essenziale per un cambiamento evolutivo efficace e duraturo. Senza tale investimento, le organizzazioni rischiano di rimanere bloccate, dipendenti da pochi individui e incapaci di affrontare le sfide in modo resiliente.

Pubblicato il

Guidare il cambiamento evolutivo: la leadership nei sistemi Kanban

Ho già accennato in un precedente articolo come siano necessari un senso e uno scopo condiviso per alimentare la leadership in un team. In questo articolo analizzo meglio l’importanza della leadeship per un sistema Kanban e per l’evoluzione della maturità di un’organizzazione.

Il Metodo Kanban si basa su un approccio evolutivo al cambiamento, privilegiando miglioramenti incrementali rispetto a trasformazioni drastiche. In questo contesto, la leadership svolge un ruolo cruciale nel catalizzare e sostenere l’evoluzione di un sistema Kanban e nel raggiungimento di livelli superiori di maturità organizzativa definiti dal Kanban Maturity Model (KMM).

Cambiamento incrementale e il ruolo della leadership

Il Metodo Kanban promuove un cambiamento incrementale evolutivo partendo dell’equilibrio attuale e introducendo modifiche gradualmente. A differenza di molti approcci di gestione del cambiamento che utilizzano momenti di rottura o cambiamenti drastici, Kanban considera questi come un’ultima risorsa, da utilizzare solo in casi estremi.

Guidare il cambiamento in periodi di equilibrio è più complesso e richiede che le persone riconoscano i problemi e abbiano una motivazione al cambiamento. In questo scenario, la leadership è essenziale per fornire lo stimolo necessario all’azione. Il modello di cambiamento evolutivo di Kanban si basa su tre elementi principali: uno stressor, un meccanismo di riflessione e un atto di leadership.

  • Lo stressor rende visibili le tensioni o i problemi presenti nel contesto lavorativo, e l’insoddisfazione che provoca diventa la miccia che accende il desiderio di cambiamento.
  • Il meccanismo di riflessione, come la visualizzazione condivisa della kanban board e delle metriche durante il Kanban Meeting quotidiano, offre un modo per articolare e riflettere sullo stressor. Le cadenze Kanban, come il Kanban Meeting, il Replenishment Meeting e la Service Delivery Review, costituiscono meccanismi di riflessione codificati.
  • L’atto di leadership fornisce lo stimolo per catalizzare la conversazione e l’azione che ne conseguono. Senza la leadership, si genera inerzia, ovvero frustrazione senza un catalizzatore per il cambiamento.

Valorizzare gli atti di leadership

Nel Metodo Kanban, gli atti di leadership sono un valore esplicito. Se la leadership non viene valorizzata e incoraggiata, è probabile che se ne manifesti poca. La leadership è un ingrediente fondamentale per il cambiamento evolutivo. Poiché gli atti di leadership comportano un rischio personale per l’individuo, è necessario favorire la ‘sicurezza psicologica’ (ovvero la certezza di potersi esprimere liberamente nell’ambiente di lavoro, senza rischiare conseguenze negative) e incoraggiare l’assunzione di rischi rendendo gli atti di leadership un valore esplicito.

Evoluzione della leadership attraverso i livelli di maturità dell’organizzazione

La comprensione e l’applicazione della leadership evolvono con i livelli di maturità dell’organizzazione secondo il KMM:

  • A livello di maturità 1 – Team-Focused (Orientato al Team), si valorizza la capacità di prendere iniziativa.
  • A livello di maturità 2 – Customer-Driven (Orientato al Cliente), la capacità di prendere iniziativa si approfondisce nella valorizzazione degli atti di leadership, riconoscendo che la leadership comporta rischi personali e incoraggiando gli altri ad agire attraverso l’esempio, l’ispirazione o la direzione.
  • A livello di maturità 3 – Fit-for-Purpose (Adatto allo Scopo), si riconosce che la leadership proveniente solo dal vertice causa ritardi e che i leader ai livelli superiori non sono sempre nella posizione migliore per conoscere le necessità o vedere il bisogno di azione ai livelli inferiori. Si incoraggia e ci si aspetta la leadership a tutti i livelli, e i leader più senior devono fornire la fiducia e la tolleranza agli errori necessarie per incoraggiare l’assunzione di rischi.
  • A livello di maturità 4 – Risk-Hedged (Con Copertura del Rischio), si passa allo sviluppo vero e proprio della leadership, riconoscendo che le capacità di leadership non sono innate ma apprese attraverso l’esperienza, i modelli di ruolo e il mentoring.

Superare le barriere all’adozione con la leadership

Diverse barriere possono ostacolare una piena adozione di Kanban e il raggiungimento di livelli di maturità più elevati. La leadership gioca un ruolo cruciale nel mitigare queste barriere.

  • La mancanza di leadership e la mancanza di unità e allineamento dietro un senso e uno scopo impediscono all’organizzazione di raggiungere il livello di maturità 3 o superiori. I leader devono comunicare chiaramente gli obiettivi, focalizzandosi sul servizio al cliente.
  • La mancanza di comprensione del contesto può essere affrontata con la visualizzazione e le metriche, ma la leadership è necessaria per interpretare e agire in base a queste informazioni.
  • La mancanza di fiducia può essere superata definendo politiche esplicite, che a loro volta sono guidate dalla leadership.
  • La mancanza di pensiero sistemico, quando l’organizzazione è ancora a un livello di maturità iniziale, può rallentare l’evoluzione. Serve una leadership in grado di favorire una visione integrata dei servizi, riconoscendone l’interdipendenza.
  • Anche il ruolo del coaching stesso può diventare una barriera se i coach non si concentrano sui risultati organizzativi osservabili nei livelli di maturità e non incoraggiano l’indipendenza e l’autosufficienza dell’organizzazione. La leadership dovrebbe guidare lo sviluppo delle capacità interne piuttosto che creare dipendenza dal coach stesso.

Il ruolo dei coach Kanban

I coach Kanban agiscono come se fossero degli ‘allenatori sportivi’ per l’organizzazione, utilizzando il modello del KMM come riferimento per sviluppare la maturità organizzativa e la resilienza aziendale. Essi supportano lo sviluppo della leadership a tutti i livelli, aiutando i leader aziendali a guidare con le indicazioni, l’esempio, l’ispirazione e, quando necessario, anche dando disposizioni.

Conclusione

L’evoluzione di un sistema Kanban richiede una leadership distribuita e orientata al servizio, che valorizzi il cambiamento incrementale, incoraggi gli atti di leadership a tutti i livelli e si adatti alle diverse fasi di maturità dell’organizzazione. I leader in un contesto Kanban non sono solo coloro che dettano la direzione, ma anche coloro che creano le condizioni affinché il cambiamento emerga in modo organico, superando le resistenze e costruendo una cultura di miglioramento continuo e resilienza. Il modello di maturità fornisce una guida per comprendere come la leadership debba evolvere di pari passo con la maturità dell’organizzazione, garantendo un percorso di crescita sostenibile e focalizzato sul valore per il cliente e per l’organizzazione stessa.

Pubblicato il

Le tre obiezioni che sento sempre quando propongo Kanban (e perché si possono superare)

Ogni volta che parlo di Kanban succede una cosa prevedibile quanto il traffico il lunedì mattina: arrivano le obiezioni.
Non sempre le stesse parole, ma quasi sempre gli stessi concetti.
E va benissimo così: sono obiezioni legittime, sensate… e anche superabili.

Anzi, col tempo ho imparato a vederle come un passaggio naturale: non sono ostacoli, ma porte che si aprono con le giuste chiavi.
In questo articolo condivido le tre più ricorrenti — e qualche spunto per affrontarle con più leggerezza (e un po’ di Kanban).

1. “Kanban può funzionare altrove, ma non nella nostra organizzazione…”

(Piccola, grande, media — a scelta.)

Questa è la classica obiezione da zona di comfort. Se l’organizzazione è piccola: “Siamo troppo piccoli per strutturarci.”
Se è grande: “Siamo troppo complessi per queste cose da startup agile.”
Insomma, qualsiasi dimensione è perfetta per non mettersi in gioco.

La verità?
Kanban non è un vestito taglia unica: è una maglia elastica.
Funziona perché si adatta. Puoi iniziare in piccolo, anche solo gestendo il lavoro di un unico flusso. Non serve ristrutturare l’organizzazione, basta iniziare a rendere visibile e gestire ciò che prima era invisibile: il caos.

Se Kanban “funziona solo per gli altri”, chiediti:
quali abitudini stai difendendo mascherandole da unicità?

2. “Non abbiamo tempo per cambiare. Lo faremo quando saremo più tranquilli.”

Ecco un paradosso interessante:
non si ha tempo di cambiare perché si è troppo occupati a gestire… il disordine che Kanban aiuterebbe a ridurre.

Dire che adotterai Kanban quando avrai più tempo è come dire che inizierai a risparmiare quando sarai ricco.
Spoiler: quel momento non arriva mai.

Kanban è pensato per essere introdotto senza fermare nulla. Non richiede un progetto titanico: puoi iniziare domani con tre colonne su una lavagna e alcuni post-it di colori e dimensioni diversi.
È un metodo evolutivo, non rivoluzionario.
Aspettare il “momento giusto” è solo un modo elegante per dire: “Non sono sicuro di volerlo fare davvero.”
Ma possiamo parlarne e iniziare a fare qualcosa insieme.

3. “Il nostro lavoro è troppo imprevedibile. Non è standardizzabile.”

Perfetto. Proprio per questo Kanban è quello che vi serve.

Kanban non serve a standardizzare il contenuto del lavoro, ma il modo in cui lo si gestisce.
È pensato per fare ordine nei flussi di lavoro imprevedibili, dinamici, dove il cambiamento è la norma.
Non ti chiede di prevedere il futuro, ma di rispondere meglio al presente.

Dire “il nostro lavoro è troppo caotico per Kanban” è come dire “la nostra casa è troppo disordinata per usare un armadio.”
Appunto.

In conclusione

Se ti sei ritrovato in una di queste obiezioni, Kanban non è il problema.
Forse il problema è che il cambiamento fa un po’ paura, e ci stiamo aggrappando al caos che conosciamo, invece di esplorare un ordine che ci renderebbe davvero più liberi.

Il punto non è “fare Kanban”.
Il punto è smettere di sopravvivere e cominciare a lavorare meglio.

E per questo, il momento giusto è adesso.
Anzi, era ieri.

Pubblicato il

Contro la mentalità vittimistica: come avere uno scopo alimenta la leadership

In un mio precedente articolo (che potete rileggere qui), parlando di rischi operativi, ho evidenziato un comportamento piuttosto comune in ambienti a bassa maturità organizzativa: la presunta complessità del contesto viene spesso usata come scusa per giustificare le proprie prestazioni inadeguate.

In questi contesti, le difficoltà esterne sono invocate come cause uniche del caos organizzativo, mentre si evita di riconoscere le responsabilità interne, sia individuali che sistemiche. Questo porta alla cosiddetta abdicazione della leadership, che alimenta una mentalità vittimistica e passiva nel team.

Ma come si costruisce un ambiente di lavoro che responsabilizza, invece di deresponsabilizzare? Come si promuove un contesto in cui ognuno si sente autorizzato ad agire da leader?

Uno degli strumenti concreti più efficaci in questo senso è la definizione e la condivisione di uno scopo (purpose) chiaro, che ispiri e orienti l’azione.

Immagine generata da DALL-E

Leadership a tutti i livelli: un principio fondamentale

Uno dei quattro principi base del metodo Kanban afferma:

“Incoraggia atti di leadership a tutti i livelli.”

Significa abilitare ogni individuo – non solo i manager – a migliorare attivamente il sistema. Ma affinché ciò accada, serve più di un metodo visuale o una board Kanban: serve senso. E il senso si costruisce a partire da uno scopo condiviso.

Lo scopo – ‘purpose’ – nel Kanban Maturity Model

Nel Kanban Maturity Model (KMM), lo scopo è visto come una leva culturale fondamentale per l’evoluzione organizzativa, soprattutto a partire dal livello 3 (Fit-for-Purpose) in su.
A questo stadio di maturità:

  • l’organizzazione riconosce che non tutto è fuori controllo;
  • inizia a discernere tra variabilità sistemica e problemi di metodo;
  • definisce uno scopo che guida il comportamento, orienta le decisioni e responsabilizza.

Nei livelli di maturità più alti (4 e 5), questo scopo viene interiorizzato a livello di cultura organizzativa: diventa parte del DNA del team.

Esempio pratico: uno scopo che guida le azioni

Prendiamo un team di informatici che sviluppa un’app per la gestione finanziaria personale. Iniziano a usare Kanban per migliorare il flusso, ma si accorgono che senza un orientamento chiaro, le decisioni restano frammentate. Decidono allora di formulare insieme uno scopo condiviso:

“Aiutiamo le persone a sentirsi sicure e in controllo delle proprie finanze attraverso soluzioni semplici, affidabili e accessibili.”

Questo scopo viene:

  • reso visibile sulla Kanban board;
  • usato come criterio per dare priorità;
  • richiamato nei momenti di review e miglioramento.

Risultato?

  • Un designer propone una nuova funzione utile non richiesta dal backlog.
  • Uno sviluppatore junior evidenzia un rischio sulla fiducia dell’utente.
  • Il team rifiuta collettivamente una richiesta del marketing che va contro il purpose.

Tutti questi sono atti di leadership distribuita, resi possibili dallo scopo.

Conclusione: lo scopo come antidoto alla mentalità vittimistica

Uno scopo chiaro è molto più di una dichiarazione d’intenti: è una fonte di libertà e responsabilità.
È lo strumento con cui un’organizzazione può contrastare la mentalità vittimistica, valorizzare il contributo individuale e coltivare una cultura in cui tutti si sentono parte attiva del miglioramento.

Nel linguaggio del KMM, questo è ciò che distingue i sistemi maturi da quelli che abdicano: non è la complessità esterna a fare la differenza, ma la chiarezza interna sul perché si fa ciò che si fa.

Pubblicato il

Ottimizzare la gestione dei progetti con il metodo Kanban: dalla percezione di unicità alla standardizzazione dei flussi di lavoro

Quando si parla di gestione dei progetti, spesso si tende a considerarli come entità uniche e irripetibili. Del resto i modelli di riferimento internazionali di project management ci portano in quella direzione. Solo per citare alcune definizioni:

  • il PMBoK definisce il progetto come “a temporary endeavour undertaken to create a unique product, service or result” (un’iniziativa temporanea per creare un prodotto, servizio o risultato unico);
  • la norma ISO 21502 similmente lo definisce come “a temporary endeavour to achieve one or more defined objectives” (un’iniziativa temporanea per raggiungere uno o più obiettivi definiti). La stessa norma afferma poi che “sebbene molti progetti abbiano caratteristiche simili, ogni progetto è unico”;
  • secondo PRINCE2 un progetto è “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case” (un’organizzazione temporanea che è creata con lo scopo di rilasciare uno o più prodotti di business secondo con un business case concordato). Lo stesso PRINCE2 afferma che “ciascun progetto è unico”.

Tuttavia, un’analisi più approfondita dei contesti reali rivela che nella maggior parte dei casi i progetti aziendali sono una collezione di elementi standardizzabili, ripetibili e organizzabili secondo schemi ben definiti. In questo quadro, il metodo Kanban si rivela un approccio estremamente efficace per migliorare la gestione e l’efficienza dei progetti.

I progetti: non unicità, ma standardizzazione

Analizzando le attività all’interno di un progetto, si scopre che esse sono per lo più riconducibili a schemi produttivi ben noti in ambito industriale, che si possono applicare anche ai servizi:

  • Produzione a commessa (Job-Shop): un’attività che viene svolta una sola volta, senza opportunità di apprendimento progressivo. Questo, e solo questo, schema produttivo corrisponde alla definizione di progetto data dai modelli di riferimento internazionali.
  • Produzione a lotti (Batch Production): un processo che permette un limitato margine di apprendimento tra le fasi.
  • Produzione in linea (Line Production): un processo più strutturato e ottimizzabile con il tempo.
  • Produzione continua (Continuous Production): un sistema altamente efficiente che permette un apprendimento costante e ottimizzazione continua.

Mentre l’obiettivo finale di un progetto potrebbe essere unico (Job-Shop), la maggior parte delle attività che lo compongono rientra nelle categorie di produzione in linea o a lotti, se non addirittura continua. Attività come costruzione, sviluppo, mobilitazione, acquisti, contabilità e reportistica seguono molto spesso schemi standardizzati e ripetitivi.

Perché Kanban funziona per i progetti?

Dal momento che la maggior parte delle attività di un progetto non è quindi veramente unica, ma segue schemi ricorrenti, il metodo Kanban aiuta a ottimizzare il flusso di lavoro. Identificare le attività ripetitive e trattarle con un approccio di produzione in linea o a lotti permette di:

  • Migliorare l’efficienza operativa.
  • Ridurre il tempo di consegna.
  • Minimizzare sprechi e inefficienze.
  • Rendere più prevedibile la gestione delle risorse.
  • Facilitare il miglioramento continuo attraverso l’apprendimento iterativo.

Il metodo Kanban nella gestione dei progetti

David J. Anderson ha creato il metodo Kanban originariamente per la gestione dello sviluppo software e ne ha successivamente esteso l’utilizzo alla gestione di qualunque servizio basato sulla conoscenza e ai progetti, enfatizzando l’importanza di visualizzare il lavoro, limitare il work in progress (WIP) e migliorare continuamente i flussi di lavoro. Per quanto riguarda i progetti, ne ho parlato in un articolo che potete rileggere cliccando qui.

Il Kanban Maturity Model (KMM) di David J. Anderson e Teodora Bozheva ha definito poi l’impiego del metodo Kanban per la gestione e lo sviluppo dell’azienda di servizi nel suo complesso. Più recentemente, un’evoluzione significativa di questo approccio è rappresentata dal Kanban Project, Programme e Portfolio Management (KPPM) di Teodora Bozheva, che amplia l’applicazione del metodo Kanban oltre la gestione dei singoli progetti, includendo programmi e portafogli aziendali. Il KPPM si basa su tre elementi fondamentali:

  1. Pensiero Sistemico (Systems Thinking): considerare l’organizzazione come un sistema di parti interconnesse, comprendendo che i risultati dipendono dalle interazioni tra queste parti.
  2. Gestione del Flusso (Flow Thinking): ottimizzare il flusso di lavoro identificando e affrontando i colli di bottiglia, migliorando la velocità e la qualità delle consegne.
  3. Cultura Collaborativa e Orientata allo Scopo (Purpose-driven): promuovere una cultura aziendale basata sulla collaborazione e focalizzata sugli obiettivi comuni, facilitando il miglioramento continuo.

Implementando il KPPM, le organizzazioni possono affrontare le sfide croniche nella gestione di progetti, programmi e portafogli, integrando pratiche che migliorano la prevedibilità, l’affidabilità e la trasparenza dei flussi di lavoro. Questo approccio non sostituisce i metodi di gestione tradizionali, ma li integra, offrendo strumenti per affrontare le complessità moderne con maggiore efficacia. Ho approfondito il KPPM in un articolo che potete rileggere cliccando qui.

Per quanto riguarda la mia esperienza diretta, della quale parlo in altri articoli che potete leggere qui, aziende che hanno implementato con successo sistemi Kanban per migliorare la gestione dei progetti hanno visto un significativo incremento dell’efficienza operativa, trasformando positivamente la gestione dei progetti e migliorando sia la produttività che la soddisfazione del cliente.

Conclusione

L’idea che i progetti siano entità uniche e irripetibili porta a inefficienze e ritardi nella loro esecuzione. In realtà, la maggior parte delle attività che li compongono seguono pattern standardizzabili, rendendo possibile l’applicazione del metodo Kanban per ottimizzarne la gestione. Riconoscere questa realtà permette ai project manager e alle aziende di adottare strategie più efficienti, migliorando la qualità e i tempi di consegna senza sacrificare la flessibilità necessaria per gestire le vere poche eccezioni.

In definitiva, un progetto aziendale ben gestito non è frutto solo dell’abilità del project manager o dell’applicazione di qualche metodo di project management, quanto soprattutto dell’applicazione di principi di produzione strutturati e flussi di lavoro standardizzati e ben collaudati.

Pubblicato il

Migliora il tuo Project Management con Kanban: pianificare un progetto con Kanban

Recentemente ho avuto modo di pianificare un progetto con il metodo Kanban e di apprezzare una volta di più la rapidità con cui le pratiche Kanban permettono di elaborare una previsione affidabile dei tempi e costi di progetto. Ho già introdotto in un precedente articolo i concetti fondamentali relativi al KPPM – Project, Programme e Portfolio Management. Qui racconto un breve esempio applicativo che fa uso di alcune tra le pratiche suggerite.

OpenArt AI generated image

Il progetto

Il progetto informatico da pianificare è consistito nel refactoring e sostituzione di una soluzione software per la gestione di un workflow aziendale che era diventata obsoleta e inadeguata. Il flusso di lavoro in questione ha una lunga storia ed è stato via via nel tempo ottimizzato. Non ci si aspettava nel progetto particolari sorprese da un flusso sostanzialmente consolidato.

Il team di progetto ha visto il coinvolgimento della responsabile dell’area di business interessata, oltre che della project manager (la responsabile IT), della sua assistente, il sottoscritto come Kanban coach e due team di sviluppatori appartenenti a due aziende fornitrici diverse, ben conosciuti e con entrambi i quali esiste da anni un solido rapporto di collaborazione. I due team di sviluppatori hanno caratteristiche e performance differenti e la responsabile IT ha effettuato nel tempo delle misurazioni che ci hanno permesso di conoscere con una certa accuratezza il tipo di distribuzione di probabilità dei loro Lead Time. Per il tipo di sviluppo da effettuare potevamo in questo caso considerare i Lead Time di entrambi i team di tipo gaussiano (Thin-Tailed), quindi abbiamo potuto utilizzare nelle previsioni il Lead Time medio e applicare la Legge di Little.

Preliminarmente abbiamo effettuato un’analisi del lavoro da svolgere e creato un backlog di progetto composto da circa 40 requisiti di alto livello in forma di User Story.

La pianificazione

Non entrerò nei dettagli tecnici dei concetti probabilistici e matematici sottostanti, mi limiterò a una panoramica del metodo applicato. Per pianificare il progetto con il metodo Kanban abbiamo proceduto come segue.

Modello probabilistico per calcolare il numero di User Story di dettaglio

Innanzitutto ci siamo creati un modello per fare delle ipotesi probabilistiche su quale avrebbe potuto essere il numero di User Story di dettaglio a partire da quelli che erano i requisiti di alto livello. Il modello probabilistico ci ha suggerito che un numero di circa 10 User Story di dettaglio per ciascun requisito era una misura ragionevole, per cui abbiamo previsto circa 400 User Story di dettaglio da sviluppare.

Fattore di correzione per tenere conto della ‘dark matter’

Abbiamo successivamente corretto il numero di User Story previste in funzione di quella che in Kanban chiamiamo ‘dark matter’, ovvero tutta quella parte di requisito che emerge man mano che il progetto procede. Non si tratta di nuovi requisiti, chiedendo al committente del progetto risponderà che quei requisiti non sono nuovi, sono sempre stati lì anche se non erano emersi in modo chiaro. Per questo è meglio introdurre un fattore di correzione opportuno per tenerne conto. Nel nostro caso, data la natura del progetto di refactoring del software, con poche sorprese, abbiamo ritenuto che un fattore di correzione del 40% fosse adeguato per tenere conto in modo corretto della ‘dark matter’. In totale la previsione è diventata quindi di 560 User Story.

Calcolo del throghput e del WIP a partire dalla deadline di progetto

Considerando che tipicamente, in un progetto che fa uso di un flusso di lavoro Kanban, è solo la parte temporalmente centrale quella in cui è possibile considerare il flusso di lavoro stabile e costante, abbiamo applicato la Legge di Little al 90% circa del lavoro da realizzare, pari a circa 500 User Story, da svolgersi nel 60% circa del tempo totale di progetto.

Ripartendo le User Story sui due team di sviluppo e conoscendo la deadline di progetto richiesta dalla responsabile dell’area di business, abbiamo calcolato il throghput richiesto, ovvero il numero di User Story che i team devono sviluppare per unità di tempo. Applicando la Legge di Little a ciascun team, in funzione del Lead Time medio su base storica e del throghput richiesto abbiamo quindi calcolato il WIP (Work in Progress) medio per entrambi i team.

Correzione del bias cognitivo sul concetto di media

Il modello prevede poi un ulteriore fattore di correzione del 10% per tenere conto del fatto che i valori medi usati per il calcolo sono un’approssimazione della mediana (ossia il cinquantesimo percentile statistico), che sarebbe il valore corretto da considerare. Noi esseri umani siamo soggetti a un bias cognitivo che ci fa considerare ‘valore medio’ quello che in realtà è il valore mediano. Quando diciamo che “mediamente facciamo una certa attività in un certo tempo” intendiamo che una volta su due ci mettiamo di più e una volta su due ci mettiamo di meno, ma questo appunto è il concetto statistico di mediana, non di media.

Definizione dei tempi e costi di progetto

Abbiamo infine richiesto ai fornitori di mettere a disposizione un numero di sviluppatori adeguato al WIP di lavoro calcolato. In base al calcolo effettuato i fornitori hanno organizzato ciascuno il proprio team e ci hanno fornito un preventivo dei costi per la realizzazione del progetto nei tempi previsti.

Al netto dei tempi necessari per l’elaborazione dell’offerta da parte dei fornitori, la previsione dei tempi e costi di progetto ha richiesto in tutto solo qualche ora.

Il monitoraggio

La previsione così definita ha permesso anche alcuni monitoraggi in corso di progetto molto semplici ma efficaci:

  • il fattore utilizzato per calcolare il numero di User Story per ciascun requisito ha consentito un controllo rapido e costante della stabilità del backlog. Quando un team registrava un valore significativamente diverso da quello previsto, faceva immediatamente escalation al project manager;
  • ci si aspettava che il Lead Time medio di ciascun team fosse sostanzialmente stabile. Quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager;
  • infine ci si aspettava che il throghput di ciascun team restasse attestato al valore medio previsto. Anche in questo caso, quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager.

Conclusione

E’ chiaro, come nell’esempio applicativo qui descritto, che per pianificare e monitorare un progetto con Kanban sia necessaria la presenza di un flusso di lavoro stabile del quale si conoscano i Lead Time medi. C’è del lavoro da fare a monte del progetto, sempre con Kanban, per misurare e, nel caso, rendere stabile e prevedibile il flusso di lavoro dei team.