“This is your throughput this week Son, what’s gone wrong?”
“Nothing Dad, I just didn’t feel like doing anything.”
“Ok, but what if no one here felt like doing anything….”
“No idea…”
“Come on, don’t fool me around, you know the whole housesold would collapse”
“Don’t think so, Mom and you would fix it.”
“Nope, I mean if NO ONE here felt like doing anything, including Mom and me….”
“You can shift some of last weeks’ cards to this week, can’t you? So my through…how-do-you-call-it would be ok for this week as well, score done!”
“It’ not about a making a score, Son, it’s about doing something to collaborate with the community you live in. That’s the objective.”
“Isn’t it about the score…”
“No it isn’t. Just making the score is called ‘vanity metric’.”
“I am not vain.”
“I’m not saying you are vain, I’m saying that focusing on the score, and not on the underlying event measured by the score, ends up being a vanity metric.”
“Again your nerdish kanban thing, Dad….”
“Yes of course, Son, but let’s go back to the point: are you going to do something for the community this week, or not?”
“If I should….”
“Yes please.”
This 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 May 2nd, 2024
Questa è la storia di come è nato il metodo Kanban. Dopo aver introdotto con successo il primo programma Kanban di Microsoft, il team di Sustaining Engineering, che gestisce le Change Request interne di Microsoft, è passato dall’avere le peggiori performance dell’azienda ad avere le migliori, nonostante la dislocazione geografica sfavorevole, dimostrando l’adattabilità e l’efficacia dei principi di Kanban. Questo caso sfata anche in modo eclatante alcune credenze diffuse sul metodo Kanban: che il metodo Kanban funzioni solo con team piccoli e co-locati e che Kanban sia sinonimo di strumenti visuali e in particolare della Kanban board.
Ho già ricordato in un precedente articolo come David J Anderson abbia creato il metodo Kanban perché non riusciva ad applicare in modo soddisfacente i metodi agili su larga scala e ho evidenziato commentando il case study su BBVA come Kanban possa aiutare invece a migliorare l’efficacia e la scalabilità di Scrum.
Lo scenario
Per comprendere le sfide affrontate dal team di Sustaining Engineering prima dell’utilizzo di Kanban, è utile comprendere la complessità dell’organizzazione IT di Microsoft. All’epoca, Microsoft operava come sette unità aziendali distinte, ciascuna con una propria funzione IT, oltre a un’unità della sede centrale che gestiva i servizi condivisi aziendali. XIT si occupava dei servizi condivisi, concentrandosi sul supporto IT e su applicazioni quali il sistema di anagrafica dei dipendenti per le risorse umane e il sistema di gestione delle buste paga gestito dall’unità finanziaria di Microsoft.
Sustaining Engineering, con sede a Hyderabad, in India, era un piccolo team incaricato di mantenere e migliorare queste applicazioni IT al di fuori delle release principali e degli aggiornamenti delle applicazioni. Tuttavia, il team era afflitto da problemi, tra cui tempi lunghi, scarsa affidabilità e promesse non mantenute. La situazione era ulteriormente aggravata da una differenza di fuso orario di 13 ore tra la sede centrale di Microsoft a Seattle e Hyderabad.
(continua dopo l’immagine)
Le sfide
Una delle principali sfide affrontate dal team di Sustaining Engineering era la mancanza di visibilità sugli obiettivi o sulle iniziative aziendali di alto livello della multinazionale americana. Le richieste di modifiche e correzioni di bug arrivavano spesso in modo isolato, rendendo difficile comprenderne l’importanza strategica. Il team era essenzialmente un servizio che prendeva ordini e spesso non era chiaro il contesto di business in cui queste richieste erano inserite.
Inoltre, il team soffriva di un lavoro arretrato eccessivo, con un tempo medio di cinque mesi per le richieste di modifica. Questo, unito all’abitudine di fare promesse di consegna che non si potevano mantenere, aveva eroso la fiducia dei clienti. Inoltre, il team era vincolato da determinati requisiti, tra cui l’obbligo di utilizzare processi di sviluppo software strutturati che non sempre funzionavano bene in un ambiente virtuale.
Anche la necessità di stimare l’effort e il costo delle singole Change Request contribuiva in modo significativo ai problemi di Sustaining Engineering. Il team doveva calcolare il potenziale ritorno sull’investimento (ROI) di ogni richiesta prima di decidere se procedere, il che richiedeva tempo e sforzi considerevoli. Il lavoro sulle stime doveva essere fatto prima di affrontare qualunque lavoro pianificato e contribuiva a ritardare ulteriormente le consegne.
La soluzione
Come primo passo, il team ha smesso di elaborare stime e le ha sostituite con accordi sui livelli di servizio, sperando che il cambio migliorasse i tempi di consegna e la soddisfazione dei clienti. Il responsabile del team ha anche deciso di introdurre Kanban come soluzione, utilizzando una strategia che prevedeva diversi cambiamenti chiave nel processo:
Limitare il lavoro in corso (WIP): l’imposizione di limiti al WIP nello sviluppo e nei test ha permesso al team di concentrarsi su un numero gestibile di attività alla volta.
Sostituzione della pianificazione mensile: le riunioni di pianificazione mensili sono state sostituite da riunioni di ‘replenishment’ settimanali per adattarsi più efficacemente ai cambiamenti di priorità.
Gestione del flusso: il team si è dato l’obiettivo di dare visibilità della quantità massima di lavoro che poteva essere consegnato tra una riunione settimanale e la successiva, e anche di rendere esplicite le policy che avrebbero fatto funzionare meglio il processo nel suo insieme.
Semplificazione della comunicazione: invece di farsi inviare le nuove richieste di lavoro a Hyderabad per la stima, il team ha comunicato più frequentemente e direttamente con le parti interessate.
Prima di fare partire questo nuovo modo di lavorare, il responsabile del team si è impegnato in una azione ‘diplomatica’. Ha incontrato i singoli stakeholder per spiegare i cambiamenti proposti e chiarire che il loro ruolo nell’organizzazione non veniva messo in discussione o minacciato in alcun modo. L’iniziativa si è rivelata vincente e le parti interessate hanno accettato di impegnarsi nei cambiamenti prima del vero e proprio kickoff.
I risultati
I risultati sono stati eccellenti, tanto che da questa esperienza è stato sviluppato il metodo Kanban che si poi è diffuso in tutto il mondo:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
Il case study completo è disponibile sui siti della Kanban University.
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.
BBVA è una delle maggiori banche internazionali e un pioniere nell’introduzione dei metodi Agile nel settore bancario globale, che ha concretamente migliorato la propria applicazione di Scrum grazie a Kanban. La gestione di servizi e progetti che richiedono un elevato livello di lavoro di conoscenza e devono rispettare scadenze rigorose, richiede un processo decisionale rapido e una gestione flessibile, per cui nel 2014 la banca ha avviato, a partire dai sistemi informativi gestionali del settore finanza, l’adozione di metodi di lavoro Agile e in particolare Scrum per soddisfare meglio le aspettative dei propri clienti.
Le sfide
Tuttavia, i responsabili dei programmi si sono scontrati con difficoltà e sfide legate alla trasformazione delle aree della banca nel loro complesso. I progetti rappresentavano una piccola parte di tutto il lavoro svolto e non era chiaro come il ‘business-as-usual’, il lavoro corrente, dovesse essere gestito in parallelo ai progetti, soprattutto quando c’erano forti dipendenze da persone con determinate competenze. Era inoltre necessario collegare tutti i team che fornivano prodotti e servizi in un’entità che lavorasse in modo sincronizzato per soddisfare le aspettative dei clienti in modo prevedibile e sostenibile. Pertanto, la percezione generale era che, sebbene Scrum fosse appropriato per i team di progetto, per diventare una vera organizzazione Agile sarebbe stato necessario evolvere oltre e introdurre altre pratiche.
E’ a questo punto che Teodora Bozheva, autrice del Case Study, si era unita ai team di coach che facilitavano la trasformazione Agile in BBVA. La prima analisi condotta con l’ausilio del modello di maturità Kanban aveva evidenziato i seguenti problemi:
Scarsa visualizzazione, limitando così la comprensione condivisa del carico di lavoro effettivo.
Mancanza di limiti al lavoro in corso (WIP – Work in Progress). I flussi di lavoro gestiti dai team erano congestionati, con poca o nessuna attenzione all’organizzazione del lavoro e a limitare il WIP per agevolare la stabilizzazione dei flussi di lavoro stessi.
Cattiva gestione di flussi di lavoro, che causava frequenti interruzioni e cambi di priorità, gestione ad hoc delle situazioni bloccanti e mancanza di comprensione qualitativa della domanda e delle capacità dei team.
Mancanza di processi definiti, che costringevano le persone a gestire i compiti da svolgere piuttosto che a concentrarsi sui risultati.
Mancanza di indicatori chiave di performance, che facevano concentrare i manager sull’ottimizzazione delle risorse piuttosto che sul miglioramento dell’erogazione del servizio.
(continua dopo l’immagine)
La soluzione
L’introduzione delle pratiche Kanban per supportare e migliorare l’applicazione di Scrum, insieme all’adozione di una gestione orientata al servizio hanno portato cambiamenti positivi, tra cui una maggiore flessibilità nella gestione dei progetti e nella contemporanea erogazione dei servizi ‘business-as-usual’, un migliore coordinamento delle dipendenze e una migliore collaborazione e comunicazione tra i team. L’adozione di un orientamento al servizio e di un pensiero in termini di flusso è stato essenziale per aumentare l’agilità e raggiungere obiettivi come un più rapido time-to-market, l’adattabilità alle mutevoli esigenze del mercato, la trasparenza, la collaborazione e il miglioramento continuo. L’uso del metodo Kanban e del modello di maturità Kanban ha fornito una preziosa guida e ha aiutato l’area Finance di BBVA a evolversi in un’entità più agile e orientata al cliente. E’ stato quindi possibile nel tempo estendere la modalità di lavoro Agile in modo coordinato e sincronizzato a più di 30.000 dipendenti gestendo in modo efficace le interdipendenze tra i vari team.
Nel maggio del 2020, il team Core Data, che era stato il pioniere dell’introduzione del metodo Kanban in BBVA, riportava i seguenti dati relativi ai miglioramenti effettuati nel solo 2019:
riduzione del 28% dei costi di gestione (tempo dedicato alle cerimonie di Scrum)
riduzione del 25% del tempo di risposta alle richieste di informazioni
17% di riduzione dei tempi di risoluzione degli incidenti
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.
Kanban è molto di più che la semplice ‘kanban board’. Il Metodo Kanban codifica oltre 150 pratiche in relazione a 7 livelli di maturità organizzativa. In un keynote speech del maggio 2017, David J Anderson, creatore del metodo Kanban, ha proposto il Metodo Kanban come un vero e proprio percorso alternativo all’agilità aziendale.
Anderson cita un sondaggio condotto intervistando 300 CIO britannici, dal quale è emerso che “più della metà dei CIO ritiene che la metodologia agile sia ormai screditata, mentre tre quarti non sono più disposti a difenderla come metodo di svolgimento dei progetti. Inoltre, la metà dei CIO ritiene che i processi agili siano solo una moda dell’IT.” Anderson sottolinea quindi come il metodo Kanban sia nato (in Microsoft a partire dal 2004) perché personalmente non era riuscito ad applicare i metodi agili su larga scala nelle grandi aziende per le quali aveva lavorato in precedenza (Sprint, Motorola) e questo prima ancora che i metodi agili si chiamassero così (il Manifesto per lo Sviluppo Agile di Software è del 2001).
Just say #no______ Un percorso alternativo all’agilità aziendale
Il Metodo Kanban si pone quindi come percorso alternativo, come l’approccio meno dirompente all’agilità aziendale e l’alternativa più radicale ad Agile (con la ‘A’ maiuscola) perché si basa sui seguenti elementi:
#noRevolutionaryChange Applicare Kanban significa partire da dove si è, non significa rivoluzionare l’azienda. Con Kanban il cambiamento è evolutivo, per piccoli passi.
#noEstimates Le stime sono costose e inutili. Meglio analizzare i trend storici e la distribuzione statistica dei lead time (tempo di attraversamento del sistema).
#noIterations Lavorare con gli sprint costringe a frammentare gli elementi di lavoro più grandi e si creano delle inutili interdipendenze tra uno sprint e l’altro. Meglio gestire un flusso continuo di lavoro con limiti al Work In Progress (lavoro in corso).
#noPlanning La pianificazione del lavoro è costosa e inutile. Meglio pianificare l’ecosistema in cui avviene il lavoro (servizi, workflow, valutazione dei rischi, policy, classi di servizio, criteri decisionali), cominciando a ottimizzare i singoli servizi dell’organizzazione e poi collegandoli.
#noPrioritization La prioritizzazione è costosa e inutile. Meglio rendere trasparenti gli elementi concreti di rischio e di costo del ritardo e selezionare dinamicamente il prossimo elemento di lavoro in base a quello.
#noBacklogGrooming Che è costoso e inutile. Meglio lasciare il backlog così com’è e usare i filtri decisionali basati sul rischio e sul costo del ritardo per selezionare il prossimo elemento di lavoro.
#noDependencyManagement Mappare le dipendenze è inutile e costoso. Meglio gestire solo le dipendenze con un elevato costo del ritardo e gestire un sistema di prenotazione della capacità produttiva dei servizi a valle che possono causare criticità ai servizi a monte.
#noCrossFunctionalTeams Riorganizzare i team e renderli co-locati è inutile e costoso. Meglio lasciare i team così come sono e dove sono, facendo invece in modo che le persone siano allineate verso il raggiungimento di obiettivi comuni, anche se appartengono a organizzazioni diverse in posizioni geografiche diverse.
e infine
#noPrescriptiveProcessDefinition Kanban non è una metodologia, non è anti-Agile, non vi impone un framework, dei processi o altro e non stravolge quello che state facendo. Vi aiuta però a renderlo migliore e a costruire il vostro percorso verso l’agilità aziendale.
Approfondiremo prossimamente ciascuno di questi temi, qui su Kanban Help.
Cosa ha ottenuto chi ha applicato Kanban
La prima applicazione di Kanban in Microsoft nel 2005 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
La seconda applicazione in Hewlett-Packard nel 2006 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
700% di aumento di produttività
lead time medio di realizzazione del firmware per le stampanti laser di nuova generazione ridotto da 21 mesi a 3 mesi e mezzo
settimana lavorativa di 4 giorni e mezzo
il tutto in meno di un anno e a un costo sostanzialmente nullo
A queste sono seguite numerose applicazioni in tutto il mondo con risultati analoghi, anche in Italia, anche per noi di Kanban Help.
State lavorando con Scrum o altri framework agili e faticate a ottenere dei risultati soddisfacenti? Kanban vi può aiutare a far funzionare meglio quello che fate già!
Qui sotto trovate il link per ascoltare il keynote speech originale su YouTube.
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.
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” – Mark Twain
“Can you please help?” asks Dad to Son
“Why me?!?” answers Son
“Because we live together and any of us helps a bit, it’s called collaboration”
“But I do help a lot already!”
“Nope”
“Yes!”
“Well… not so much”
“YES!”
“All right Son, let’s do something about it!”
After some while the first simple Kanban board appears in the kitchen. Three columns: ‘to do’, ‘in progress’ and ‘done’, very simple one. Anyone has their own coloured pin: blue Mom, yellow Dad, green Son, red his Brother. And the first metric appears. Cards count: very simple one.
“…doing what Son? There isn’t any card under your pin ‘in progress'”
“Yes, but I always do a lot!”
“Let me check your throughput…”
“My through…what Dad?!? You’re still the same old nerd…”
“Your throughput Son, which is the count of the cards which have been processed by you… actually over the past week you don’t seem to have done much, in fact your brother’s card count is four times than yours, let alone mine and Mom’s which are much bigger as they should be. You don’t want to end up looking the laziest in town, do you?”
“No, no, definitely not!”
“All right then, may I ask for your help please?”
“Ok, ok, but… but…”
“But… what?”
“Nothing Dad, doesn’t matter”
This 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 March 29, 2024
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.
“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
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.
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.
