Log in




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

March 8th, 2024 by

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

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: misurare ed equilibrare i carichi di lavoro di una funzione IT

March 1st, 2024 by

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.

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.

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

February 28th, 2024 by

“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.


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

January 15th, 2024 by

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 effective control over time of 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à

February 10th, 2023 by

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: quali comportamenti favoriscono la collaborazione in un team agile

July 19th, 2022 by


Alcuni comportamenti sono fondamentali perché un team possa davvero collaborare in modo efficace e coerente con i principi agili.

Scrum applicato in azienda: anche un progetto agile deve avere una giustificazione

June 3rd, 2022 by

I progetti agili, come tutti i progetti, devono avere alla base un rapporto tra costi sostenuti e valore generato che ne giustifichi la realizzazione. Nel video ho utilizzato la versione Project Brief Canvas proposta da Praxis Framework, che ringrazio.

Scrum applicato in azienda: il Project Brief Canvas per avere sempre la visione di tutto il progetto

March 3rd, 2022 by

Nel corso di un progetto agile, come di qualunque progetto, è importante avere sempre sott’occhio una visione complessiva dei razionali di progetto per mantenerne il controllo. Il Project Brief Canvas è uno strumento pratico e visuale che permette di farlo in maniera concreta ed efficace. Nel video ho utilizzato la versione Project Brief Canvas proposta da Praxis Framework, che ringrazio.

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

January 11th, 2022 by

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.

Scrum applicato in azienda: scrivere i requisiti in un progetto agile

November 26th, 2021 by

Perché un progetto possa essere davvero agile, i requisiti devono essere scritti in modalità outcome based: in questo video provo a spiegare cosa significa e a fare qualche esempio.