kanban | Il Project Management & l'arte della Maratona

Pillole di Kanban applicato: la gestione delle congestioni autostradali in Svizzera

Per recarmi in Svizzera a svolgere alcuni corsi di formazione devo percorrere una delle tratte autostradali credo più congestionate al mondo, tra la frontiera italiana di Como e Lugano Nord. La tratta complessiva che devo percorrere da casa al centro di formazione è lunga 85 km e richiede approssimativamente due ore per essere percorsa, sia all’andata al mattino che al ritorno alla sera. L’andamento del traffico non è costante, anche se si tratta di un fenomeno che può essere studiato e che è statisticamente prevedibile perché segue una distribuzione gaussiana. Si tratta di una tipica situazione che si può gestire con un sistema Kanban per garantire la puntualità del trainer in aula e infatti finora non ho mai iniziato un corso in ritardo. Grazie anche agli svizzeri che gestiscono le congestioni autostradali utilizzando gli stessi concetti che stanno alla base di Kanban.

La tratta autostradale svizzera, che si snoda in un fondo valle tra le montagne, risulta la parte più problematica e congestionata. Ho notato però che gli svizzeri gestiscono il traffico autostradale di quella tratta super congestionata utilizzando un sistema basato sulla teoria dei vincoli, quindi applicando gli stessi principi che hanno ispirato Anderson nella messa a punto del metodo Kanban. Vediamo come.

Il vincolo sta nel collo di bottiglia

Alla base del ragionamento c’è la constatazione che un sistema di flusso, come è anche un’autostrada, è vincolato dal suo collo di bottiglia. Se in autostrada ci sono delle strozzature o dei punti particolarmente congestionati, la quantità di mezzi oraria che può percorrere l’autostrada (che in Kanban chiamiamo Throughput) sarà limitata dal più lento di tali strozzature e punti congestionati. Se noi riusciamo in qualche modo a far fluire il traffico alla stessa velocità del collo di bottiglia, il flusso si stabilizza e poi possiamo provare ad accelerarlo, aumentando il throughput e diminuendo il tempo di percorrenza di ciascun mezzo. Concetto intuitivo in teoria, un po’ meno in pratica perché si tratta di andare piano per essere più veloci.

La legge di Little

L’altro concetto che ci aiuta è la Legge di Little, che si può applicare solo in presenza di sistemi con distribuzione statistica gaussiana (e il traffico in autostrada lo è), per cui si possono fare i calcoli utilizzando i valori medi come valori di riferimento. La Legge di Little è una funzione lineare che lega la quantità di elementi medi presenti in un sistema alla velocità di attraversamento media del sistema stesso.
La relazione è L = λ x W, dove L è il numero dei elementi mediamente presenti nel sistema (nel nostro caso i mezzi), λ è il tasso di arrivo medio, che si suppone costante (nel nostro caso quanti mezzi entrano in autostrada al minuto), e W è il tempo medio di attraversamento del sistema (nel nostro caso il tempo per percorrere la tratta autostradale). Facendo qualche semplice simulazione con la Legge di Little si può verificare facilmente come in un sistema si possa minimizzare la velocità di percorrenza (e di conseguenza massimizzare il throughput) se non lo si carica oltre il 65%-70% della sua capacità di carico massima teorica. In Kanban applichiamo questo mettendo dei limiti al WIP – Work In progress (lavoro in corso, nel nostro caso il numero di mezzi presenti sulla tratta autostradale). Concetto questo invece del tutto controintuitivo.

La soluzione del problema dell’autostrada

Mettere insieme questi due concetti per la gestione dell’autostrada significa fare come fanno gli svizzeri:

utilizzare un semaforo per frenare il flusso a monte (tipicamente all’ingresso di una galleria prima del tratto congestionato)
regolare tramite il semaforo l’accesso al sistema, evitando di caricare il sistema oltre il limite che tende a bloccarlo, limite che è determinato dal collo di bottiglia
fare rispettare rigidamente il limite di velocità di 80 km/h per mantenere il flusso stabile

Così facendo il sistema si stabilizza e il risultato è sorprendente, perché dopo l’attesa per accedere al sistema (che mediamente non supera mai i 15′) si riesce comodamente a percorrere la tratta a 80km/h in circa mezz’ora, che sono abbastanza sicuro essere un tempo ottimizzato.

Di ritorno alla sera, terminata la tratta in territorio svizzero, si passa la frontiera e i flussi non sono più regolati, per cui si può osservare e anche provare a misurare la differenza. Per quanto riguarda la tratta italiana, soprattutto all’andata, il metodo Kanban lo ho applicato io in modo tale da assicurarmi di avere tempi di percorrenza prevedibili e affidabili, ma di questo parlerò in un altro articolo.

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.

Migliora il tuo IT Service Management con Kanban: FARA IT Operations – Applying the Kanban Method in the IT Operations Team (case study in inglese)

Applicando il Metodo Kanban, in cinque mesi a partire dall’ottobre 2021, FARA ha migliorato in modo significativo le proprie IT Operations e ha risolto la maggior parte delle ragioni di insoddisfazione che aveva individuato inizialmente e migliorato il suo Service Management. Ha raggiunto tali risultati facendo leva sulle tipiche pratiche Kanban: visualizzazione, limitazione del WIP (Work In Progress, ovvero il lavoro in corso), gestione del flusso di lavoro, esplicitazione delle policy, attuazione dei feedback loop (incontri periodici in cui team a vari livelli discute di come gestire e migliorare il sistema) e infine miglioramento collaborativo ed evoluzione sperimentale del sistema.

FARA è un’azienda tecnologica norvegese leader nei sistemi di mobilità intelligente nei paesi nordici. Da oltre 20 anni fornisce soluzioni di mobilità innovative (come l’Account-Based Ticketing, informazioni in tempo reale e gestione della flotta) per migliorare il flusso di informazioni, l’esperienza dei passeggeri e le infrastrutture di trasporto. E’ parte del Gruppo Ticketer, fornitore del sistema di biglietteria più diffuso nel Regno Unito.

Il Case Study, scritto da Anna Radzikowska, analizza i seguenti elementi che hanno migliorato le IT Operations di FARA:

Come la valutazione del livello di maturità ha aiutato a guidare i miglioramenti

Come il team ha identificato le cause principali dell’insoddisfazione

Cosa è importante per identificare le fonti di domanda

Come le modifiche per rendere esplicite le policy e la visualizzazione hanno aiutato ad affrontare i problemi

Come il team è riuscito a superare le resistenze legate alla sensazione che avere un nuovo processo fosse un’ulteriore costo che faceva perdere tempo

Come il team ha creato nuove abitudini

Quali automazioni ha impostato il team per diminuire il numero di interventi manuali

Come la ripartizione del lead time ha aiutato il team a identificare le aree di miglioramento

Leggi il case study sul sito Kanban+ della Kanban University

Migliora il tuo IT Service Management con Kanban: identificare e misurare i flussi per ottenere livelli di servizio affidabili

Recentemente mi è capitato di essere interpellato per una consulenza Kanban da un collega che si sta occupando di supportare l’IT di una nota grande azienda di servizi. I servizi offerti dall’azienda in questione dipendono in modo significativo da una complessa rete di servizi informativi che spostano ingenti quantità di dati e gestiscono decine di migliaia di transazioni al giorno, per cui l’IT dell’azienda si ritrova a svolgere un ruolo critico per il business. Il CIO dell’azienda ha contattato il collega perché si trovava in difficoltà a comprendere le dinamiche del sistema e a mantenerlo sotto controllo.

carichi di lavoro del sistema misurati per orario della giornata

Quello a cui si è trovato davanti il collega, è un caso tipico: i sistemi informativi delle grandi aziende sono spesso modellati a partire dalle best practice ITSM di riferimento del mercato, quali ITILv3 o più recentemente ITIL4. Tali framework sono sicuramente utili per comprendere il contesto dei servizi IT e definire principi e processi delle organizzazioni anche se poi manca la parte pragmatica che permetta di plasmare l’ecosistema organizzativo in modo tale che ciò che è stato pensato e implementato possa essere successivamente controllato e migliorato. Manca quasi sempre quello che definirei il ‘motore’ per il miglioramento continuo. Per cui ci si trova a distanza di anni a non comprendere più le vere dinamiche di funzionamento del sistema organizzativo.

La prima cosa fatta è stata quindi cercare di ricostruire i flussi informativi di scambio tra i sistemi, a partire dai più critici. E’ stato utilizzato un approccio molto pragmatico, individuando insieme al CIO alcuni nodi che facevano sicuramente parte dei flussi e collocando in questi nodi delle sonde che rilevassero le metriche fondamentali di flusso tra i nodi stessi: throughput, tempi di attraversamento, carichi di lavoro distribuiti per orario della giornata e numero di transazioni che vanno in errore. Tali metriche sono poi state messe in un cruscotto a disposizione del CIO. Questo primo passo ha portato dei primi benefici in termini di visibilità e misura del sistema coerentemente con le pratiche Kanban di visualizzazione e gestione del flusso.

tempi di risposta del sistema misurati per orario della giornata

Dopo questa fase iniziale sono stati progressivamente individuati ulteriori nodi e aggiunte altre sonde in modo tale da andare a ricostruire e a misurare i processi reali all’interno dell’organizzazione. L’approccio pragmatico e sperimentale è stato apprezzato perché tende a ovviare uno dei problemi tipici dell’analisi dei processi in aziende di grandi dimensioni, dove la complessità è tale che ricostruire i flussi di lavoro con il metodo tradizionale di andare ad analizzare la documentazione e a intervistare le persone rischia di risultare fuorviante oltre che costoso.

Kanban offre una guida pragmatica su come utilizzare al meglio le metriche raccolte per ottenere un effettivo miglioramento dei flussi di lavoro e dei servizi e fare in modo che il CIO possa offrire al business livelli di servizio prevedibili e affidabili.

Aperta la finestra di visibilità sui flussi di lavoro, il prossimo passo sarà quindi quello di far leva su alcune pratiche Kanban che permettano di sviluppare il sistema in modo evolutivo;
a cominciare dall’introduzione di cicli di feedback a vari livelli dell’organizzazione per far riflettere le persone e fare emergere idee di miglioramento dei servizi; e proseguendo con l’arricchimento dei ruoli aziendali già esistenti con competenze e responsabilità di gestione dei flussi.

L’obiettivo finale è quello di arrivare a dotare l’organizzazione nel suo complesso di uno strumento di controllo efficace dei livelli di servizio, non più solo a disposizione dell’IT ma anche del business

Migliora il tuo IT Service Management con Kanban: misurare ed equilibrare i carichi di lavoro di una funzione IT

Sto collaborando come consulente e coach da qualche anno con la funzione IT di un’azienda della quale non farò il nome per ragioni di riservatezza, la chiamerò Grow, un nome di fantasia.

Quando ho iniziato a collaborare con Grow, l’azienda in forte crescita ma con una storia di piccola realtà locale, non aveva mai avuto la presenza di un vero IT Manager di ruolo e la funzione IT era operata in modo sostanzialmente poco strutturato da altre funzioni.

Dopo un periodo iniziale in cui, in staff alla presidenza, ho svolto personalmente ad interim la funzione di IT Manager, cominciando a organizzare quella che sarebbe diventata la funzione IT, si è deciso di assumere una IT Manager di ruolo e insieme a lei siamo andati a strutturare la funzione mediante l’introduzione di processi e ruoli basati sul framework ITILv3, che allora costituiva lo stato dell’arte nel settore dei servizi IT. Per la parte di gestione dei progetti abbiamo invece sviluppato, sempre insieme all’IT Manager di Grow, un metodo interno basato su un ibrido tra i framework PRINCE2 e AgilePM che successivamente è stato adottato da tutta l’azienda Grow anche per i progetti non IT.

Nel corso degli anni si è quindi sviluppata in Grow una IT moderna, in staff alla direzione aziendale e basata sul concetto di System Integration and Management, che oggi conta un team di tre persone, oltre alla IT Manager, coordina e integra un network di fornitori esterni per erogare un numero sempre crescente di servizi IT alle direzioni tecniche di Grow, che nel frattempo ha raggiunto i tremila dipendenti.

Il volume di lavoro e le dimensioni sempre maggiori hanno posto l’IT di Grow di fronte a sfide nuove e complessità sempre crescenti e i modelli basati sui soli framework di ITSM e Project Management non erano più sufficienti.

Per questa ragione abbiamo cominciato ad applicare il Metodo Kanban con l’obiettivo di comprendere più a fondo il funzionamento dei vari servizi gestiti dall’IT per poterli gestire meglio.

distribuzione statistica dei tempi di risposta del Service Desk

Il Service Desk e i processi di Incident Management e Request Fulfillment sono stati la parte relativamente più semplice: dopo anni di lavoro per strutturarli con l’ausilio di uno strumento ITSM sono ottimizzati – si stima che il tempo medio di evasione di un ticket si sia ridotto in cinque anni di un fattore dieci. Introducendo la tipica metrica Kanban di distribuzione statistica dei tempi di risposta come in figura, ci siamo resi conto che in effetti l’attività di Service Desk stava sovra-performando, il 96% dei ticket erano evasi entro 4 ore a fronte di uno SLA concordato con il business di 8 ore per i ticket a bassa priorità che sono la stragrande maggioranza (99%).

distribuzione statistica dei tempi di risposta degli altri servizi IT

Più difficile inizialmente la misura degli altri servizi IT per i quali non si disponeva di strumenti di gestione equipaggiati con metriche Kanban. È stata quindi introdotta una Kanban board dotata di strumenti di misura che nel giro di qualche mese ha permesso di disporre di un grafico di confronto dal quale è risultato che il 96% dei task relativi ad altri servizi erano evasi entro 8 settimane a fronte di un livello di servizio non ancora definito ma che sarebbe stato ragionevole fissare a 4 settimane o meno.

Potendo disporre di tali metriche e di una sostanziale prevedibilità complessiva dei propri servizi il team IT di Grow ha ridistribuito i carichi di lavoro e riallocato la propria capacità produttiva, sostanzialmente lavorando su un’agenda settimanale condivisa degli impegni del team per riequilibrare le performance dei servizi e ottimizzare i livelli di servizio verso il business.

Conversation between a (Kanban Coach) father and a teenage son

“A problem well stated is a problem half solved.” – Charles F. Kettering

“Today I’ve been called from school and told you are always late….”
“Me?! What the…. I mean, not ALWAYS… from time to time maybe yes, but not always, in fact I’m very often on time!”

“All right Son, let’s do something about it!”

A few months later, showing a chart displaying the statistical distribution of delays.

“Son, this is the metric of how often you are on time or late, overall”

“Who? Me? You must be joking!”

“No, I’m not, this is you over the past months, as you can see your on-time-arrival rate is 68% of occurrences, whilst you arrive within 15 minutes of delay 93% of times and 99% of times your are there within half an hour of delay, that is it”

“Dad you are a damn nerd!”

“Yes, I know I am Son, but these are facts, what the psychologists would call a reality check. Which is the rate of delays that the school is ready to accept?”

“No idea Dad”

“All right, then check with them, even though I suspect they have an expectation that is much lower than your current delay rate; by the way the good news is that the statistical distribution is reasonably thin tailed which means that you are consistently predictible…”

“What is this statistical crap Daaad?! Tell me in a way that also the cat can understand!”

“I mean that you do things more or less always the same way, so probably it’s enough that you set an half an hour earlier your alarm in the morning and you will be consistently on time, if you want….”

“Come on Dad, why should I wake up half an hour earlier…. I can instead rush and be on time!”

“It’s your decision Son, you are the master of your fate, your are the captain of your soul….”

“Also the poem crap now, stop it there Dad, got the message….”

Above conversation and the characters represented in it are purely fictional for the sake of explaining some Kanban Method to the folks

I originally posted this article on LinkedIn on February 18, 2024

Personal Capacity Planning: a practice that boosts Kanban teams productivity

The practice of looking at the typical weekly schedule and making a personal analysis of production capacity with respect to the different activities to be carried out – which I have branded as Personal Capacity Planning – is an exercise that I have been prompting to do for more than a decade now the people I’m coaching in many organizations. And it has always boosted their productivity.

Step one: look for personal weekly patterns

The method applied is very empirical and pragmatic. No estimates or scheduling of activities are made – which would be time-consuming and wasteful; instead, the idea is to recall what has been done on average over the last few weeks, looking for a pattern. An alternative approach is to simply track and record what gets done over two to three weeks.

Personal Capacity Planning on a whiteboard in 2011

What emerges is usually a pattern of how loads are typically distributed in order to maintain the current level of activity, and the thing that has always surprised me is how sensible patterns can be detected even in rather chaotic organisations (maturity level between 0 and 3 of the Kanban Maturity Model). It is as if people in such organisations instinctively tend to compensate for the chaos that surrounds them by giving themselves predictable routines on a personal level. Moreover it also retains its usefulness in organizations at higher maturity level.

Step two: adjust the patterns to evolve the workflow

What is interesting is that such instinctive tendency can be leveraged to evolve and stabilise workflows. Just the fact that people are visualising their typical week and become more aware of it, tends to stabilise their behaviour and thus the system. Furthermore, applying other Kanban practices together with the team such as visualising the work, analysing the workflows, collecting initial metrics and understanding the actions that can improve the workflow, the team can act in a shared way on personal capacity planning patterns, trying to modify them to facilitate the improvement of the workflow in the desired direction. Within the Kanban cadences, primarily the Team Kanban Meeting but also the Service Delivery Review, the team can discuss and share how to run safe-to-fail experiments by adjusting each individual pattern in order to evolve the workflows, so that by subsequent adjustments over time the workflows can be stabilised and optimised.

I have found this practice particularly useful when people are engaged in several teams and several different workflows, and I have always observed empirically a tendency to rebalance performance across flows, for example by slowing down workflows that are outperforming against SLAs (agreed service levels) in favour of speeding up worklows that are underperforming.

Personal Capacity Planning on a spreadsheet in 2024

Step three: reserve capacity as you see fit

Adjusting and re-balancing personal capacity may imply reserving some capacity as necessary. When I implemented such practice for the first time back in 2011, I was the delivery manager in a software company leading a group of project managers. The main problem in those days was that many resources engaged on projects were shared and were also engaged in other operations maintenance activities. It was then that we came up with the idea of reserving capacity ‘slots’ so as to avoid conflict with the projects and make sure that the capacity available to the projects was realistic.

Later I used the same approach whenever I found myself in a similar situation. For example, it helped me apply Scrum: if the same people had to participate in different teams, of which only some applied Scrum, the need arose to reserve shared slots in which to work co-located and apply Scrum ‘rituals’. More recently, I have used it for teams that are involved in support and service desk activities as much as in development projects, balancing workloads and reserving shifts as service desk agents.

How can this practice help you?

The initial reaction to the introduction of this practice has always been one of suspicion, as if I wanted to mind the team’s business and control them by putting them in a bit of a ‘cage’. After some time, however, people have always discovered that it is not a ‘cage’ but a method managed autonomously by the team themselves and aimed at supporting stability and predictability of their working system regardless of external interfering factors. Greater stability and predictability of the system means that people, and the teams they are part of, have more and more effective control overtime on the service levels they offer their customers and thus ultimately they become masters of their own fate.

This practice does not limit, does not lock the team in a ‘cage’, instead does the opposite by relieving the team of external pressure. It is a counterintuitive concept that can only be fully understood by experiencing a practice that integrates perfectly with the Kanban Method and is fully in line with its principles.

Agile applicato in azienda: non è vero che un team stabile e co-locato aumenta la collaborazione e la produttività

In questo webinar del gennaio 2021, David J Anderson, autore del metodo Kanban, sottolinea come un mito della comunità Agile sia stato clamorosamente sfatato dalla pandemia: non è vero che rendere i team stabili e co-locati fa automaticamente aumentare la collaborazione e la produttività. Nei fatti, abbiamo sperimentato tutti come lavorando in smart-working dal tavolo della cucina di casa siamo più produttivi e la collaborazione con i colleghi non ha subito cambiamenti nella maggior parte dei casi semplicemente perché non c’era nemmeno in ufficio.

La collaborazione si costruisce dandosi scopo e obiettivi comuni e perseguendoli con costanza, a prescindere dalla stabilità del team e dalla collocazione geografica.

Anderson suggerisce quindi un modello per il futuro: la capacità delle singole persone di pensarsi come una piccola organizzazione orientata ai servizi che lavora per la più ampia organizzazione aziendale; allo stesso tempo la capacità delle aziende di sviluppare quella che viene definita ‘produttività relazionale’, ovvero imparare a collaborare davvero nel lavoro reale per dare risultati di valore ai propri clienti.

Buona visione!

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.

Un’azienda organizzata è fatta di persone organizzate

“Tutto andrebbe semplificato il più possibile, ma non di più” (Albert Einstein)

L’affermazione nel titolo sembra di un’ovvietà disarmante. Lo è in teoria anche se in pratica le cose stanno diversamente perché è proprio la difficoltà delle persone ad organizzarsi a livello personale che spesso fa fallire i sistemi organizzativi aziendali, sopratutto se tale difficoltà è incontrata dalle figure di vertice, che tra l’altro sono quelle maggiormente oberate di impegni e che più necessitano di una buona organizzazione personale.

Insieme ai colleghi condividiamo spesso riflessioni sui progetti organizzativi che ciascuno di noi ha portato avanti negli anni in varie aziende e ci rinforziamo sempre più nella seguente convinzione: l’organizzazione aziendale discende dall’organizzazione personale degli individui, senza quest’ultima anche le migliori pratiche organizzative faticano ad avere successo. Tale convinzione ci porta continuamente a ricercare e adottare metodiche di organizzazione personale che possano rinforzare la capacità di operare nostra e dei nostri team.

In effetti ripercorrendo i miei interventi in azienda, come anche descritto in altri articoli su questo blog, ho sempre cercato di perseguire uno sviluppo armonico in parallelo dell’organizzazione aziendale da un lato e di quella personale dei membri del team di lavoro dall’altro, anche se non sempre ho avuto a disposizione gli strumenti adatti.

Nell’ultimo anno ho quindi approfondito l’applicazione del Natural Planning Model® ideato da David Allen nell’ambito di GTD® – Getting Things Done®.

GTD® e il Natural Planning Model® offrono qualcosa in più, perché favoriscono la creazione di un vero e proprio sistema personale per la gestione di tutte le proprie attività e progetti, rigoroso e allo stesso flessibile. Il metodo, grazie alla sua struttura adattabile e scalabile, si integra perfettamente con qualunque contesto organizzativo, quale che sia la metodologia applicata.

L’aspetto che apprezzo particolarmente di questo sistema di gestione personale rispetto ad altri metodi è che il Natural Planning Model® non impone la calendarizzazione di tutte le proprie attività, ma propone una disciplinata gestione del backlog delle proprie attività, con modalità molto simili a quanto avviene per le varie metodiche agili quali Scrum, Kanban o Agile Project Management, che spesso applico nei progetti aziendali. Questo significa che il Natural Planning Model® può diventare il ‘terminale personale’ di un sistema organizzativo completo per l’azienda.

Sto personalmente applicando il Natural Planning Model®, con risultati molto soddisfacenti, per la gestione della mia vita nel suo complesso (come in effetti deve essere per massimizzarne l’efficacia) e all’interno di essa anche per la gestione di un contesto poco strutturato all’interno di una organizzazione con cui collaboro e che è in rapida evoluzione. Grazie a esso riesco a cavalcare l’onda delle varie attività che spesso fanno la loro comparsa in maniera piuttosto estemporanea e imprevista e a convogliarle in un flusso controllato e organizzato, evitando al tempo stesso il classico fenomeno del “foglio che cade tra due scrivanie” ovvero delle attività che si perdono e nessuno prende in carico. Non che prima non facessi questo, ma mi rendo conto che grazie all’applicazione di un metodo ottimizzato mi ritrovo ad operare in modo molto più efficiente ed efficace.

Il prossimo passo sarà sviluppare la nuova struttura operativa, i processi e gli schemi di flusso di gestione dei progetti per l’organizzazione in questione ma le fondamenta, a livello personale, sono già poste e sono solide. In effetti l’organizzazione già funziona, perché sono organizzati gli individui al suo interno.

Nel frattempo E-quality ha scelto quest’anno di diventare ente di formazione ufficiale per l’Italia di GTD® e io ho accolto con entusiasmo la proposta di diventare uno dei docenti accreditati.

Innovare in modo agile

“I colori non sono più di cinque. Eppure nessuno può dire di avere visto tutte le loro combinazioni”
(Sun Tzu – L’arte della guerra)

Le tecniche di lean management, inventate da Toyota a partire dagli anni ’50 del secolo scorso, ben si prestano all’applicazione per la creazione di nuovi prodotti e la rivitalizzazione di quelli esistenti. Di recente, movimenti come Lean Startup hanno giustamente posto l’enfasi sul loro impiego per un approccio radicale al lancio di idee e attività innovative.

Insieme a Daniela Alderighi abbiamo combinato queste tecniche con la sua esperienza di innovazione in medie e piccole imprese per proporre Eureka, un intervento operativo molto breve – 3 giorni – per tratteggiare opportunità di nuovi prodotti/servizi in passi incrementali successivi, guidati in modo visivo secondo logiche di valore e fattibilità.

Per chi fosse curioso il sito è www.eureka.tips