Autore: Marco Re

Pubblicato il

Pillole di Kanban applicato: domande e risposte con la spiegazione della terminologia che utilizziamo

Nei precedenti articoli ho illustrato alcuni esempi di applicazione del metodo Kanban, facendo riferimento ad alcuni concetti tipici del metodo. Penso che possa essere utile per chi si approccia per la prima volta a Kanban e non ne conosce i tecnicismi, una spiegazione della terminologia che utilizziamo. Nel seguito ho quindi provato a spiegare brevemente alcuni concetti basilari per l’applicazione del metodo Kanban:

  • lead time
  • distribuzione di probabilità
  • aspettative del cliente rispetto alla data di consegna desiderata
  • costo del ritardo
  • classe di servizio

Che cos’è il lead time?

Definiamo il lead time come un tempo che inizia dal commitment point concordato (momento in cui ci impegniamo a fare un lavoro) e continua fino a quando l’elemento di lavoro è pronto per la consegna. In altre parole, iniziamo a contare il lead time dal momento in cui il cliente può legittimamente aspettarsi che noi lavoriamo sul prodotto, fino a quando noi possiamo legittimamente aspettarci di consegnarlo al cliente. Qualsiasi ulteriore attesa al momento della consegna non viene conteggiata. Questa definizione non è ambigua e funziona in modo coerente per qualsiasi flusso di lavoro e servizio.

In base agli studi sul Modello di Maturità di Kanban, dovremmo tuttavia riconoscere che questa definizione funziona in modo affidabile a livello di maturità 3 e oltre, mentre a livelli di maturità inferiori è problematica. A livelli di maturità inferiori, il punto di commitment è spesso ambiguo e, nel migliore dei casi, asincrono, cioè il cliente fa una richiesta prima che ci sia l’effettivo commitment a svolgere il lavoro. In questo caso di commitment asincrono misuriamo il lead time a partire dal secondo punto di commitment, dal momento in cui il lavoro da fare viene inserito nel flusso di lavoro ed entra a fare parte del WIP (Work In Progress – lavoro in corso). Spesso nei flussi di lavoro di livello di maturità 2 non esiste un concetto forte di commitment e quindi si tende a misurare il lead time dal momento in cui un elemento di lavoro viene richiesto.

Il termine “lead time” significa quindi: “Se si sa quando si deve consegnare il prodotto, il lead time è la quantità di tempo di cui si ha bisogno in anticipo per effettuare un ordine e aspettarsi la consegna il giorno o prima di quando si ha bisogno dell’elemento di lavoro richiesto”, o semplicemente, il periodo di tempo in cui il commitment deve precedere la consegna.

Che cos’è la distribuzione di probabilità?

La funzione di densità di probabilità del lead time (probability density function – PDF) è una curva che mostra la distribuzione dei dati effettivi del lead time di un sistema Kanban. Viene rappresentata su un grafico in cui l’asse orizzontale delle ascisse mostra il numero di giorni di lead time, mentre l’asse verticale delle ordinate mostra il numero di occorrenze di tale tempo all’interno dell’insieme di dati campione (il numero di elementi di lavoro passati attraverso il sistema Kanban). La funzione di densità di probabilità del lead time tipicamente assume due forme di distribuzione:

Distribuzione a coda grassa (Fat-tailed)

Scarsa prevedibilità, impatto potenzialmente elevato da ritardi prolungati.

Distribuzione a coda grassa (Fat-tailed)

Distribuzione a coda sottile (Thin-tailed)

Buona prevedibilità, basso impatto, ritardi più brevi

Distribuzione a coda sottile (Thin-tailed)


L’esempio in alto proviene da un gruppo di IT Operations e quello in basso da un team di sviluppo di prodotti software. Quello in alto si dice che sia “a coda grassa”: c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. In generale, la “coda grassa” è indesiderabile, rischiosa e rende difficile la pianificazione. Quello a destra è detto “a coda sottile”: non c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. Questa convenzione di denominazione può sembrare controintuitiva per i non matematici. La verità è che, dal punto di vista matematico, queste code corrono all’infinito. Quindi, se la coda è visibile, deve essere grassa. Una coda sottile è di fatto invisibile lungo l’asse delle ascisse.

I concetti di distribuzione del lead time con coda grassa e con coda sottile sono molto importanti e sapere quale dei due è presente nel vostro sistema Kanban, fa una differenza fondamentale per la pianificazione, la gestione del rischio e la probabilità di ottenere la soddisfazione del cliente e di essere considerati un fornitore di servizi affidabile.
In assenza di dati sulla distribuzione di probabilità dell’elemento di lavoro, si consiglia di assumere una distribuzione a coda grassa. È importante ricordare questo semplice mantra: “il rischio è sempre nella coda”. Le distribuzioni a coda grassa richiedono un approccio diverso alla gestione del rischio.

Quali possono essere le aspettative del vostro cliente rispetto alla data di consegna desiderata?

“Non importa“. I vostri clienti sono indifferenti alla data di consegna e non si preoccupano? La data è puramente consultiva o non esiste una data specifica, ma è stata semplicemente indicata perché richiesto ? Potremmo dire che non importa quando il prodotto viene consegnato, purché alla fine venga consegnato? Se è così, l’aspettativa del cliente è “Non importa”.

Entro lo SLA. Esiste uno SLA/SLE con il cliente e quindi, se iniziamo una lavorazione, c’è l’aspettativa che la consegniamo entro quel tempo? Se sì, l’aspettativa del cliente è “Entro lo SLA”.

Scadenza. La data di consegna desiderata è accompagnata dall’indicazione di una scadenza? La scadenza può essere reale, come una data fissa per un evento esterno o qualcosa di stagionale. Oppure può essere semplicemente un espediente in un ambiente con poca fiducia: la scadenza viene usata per pressarci, come fattore di stress per spingerci all’azione, o in qualche modo per responsabilizzarci, in una cultura altrimenti poco fiduciosa nei risultati. Indipendentemente dal motivo, se il cliente indica una scadenza, dobbiamo tenerne conto.

“Tolleranza zero“. Quando il costo di un ritardo oltre la data di consegna desiderata è veramente elevato, il cliente può avere “tolleranza zero”. Si tratta di una forma più estrema di scadenza: quando c’è tolleranza zero per i ritardi, tutti capiranno le conseguenze e l’impatto sulla nostra attività di un mancato rispetto della scadenza. È probabile che si sacrifichino molte altre richieste di lavorazione per rispettare la data.

Il prima possibile. Infine, l’aspettativa del cliente può essere “il prima possibile” (ASAP); in questo caso, se decidiamo di svolgere il lavoro, dobbiamo accelerare la richiesta.

Cosa si intende per costo del ritardo?

Un ritardo significa che si ottiene meno valore da un’opportunità. Il costo del ritardo cerca di approssimare il valore perso a causa del ritardo nello svolgere un lavoro. Il costo del ritardo può essere modellato come una curva che si accumula nel tempo. Se la forma della curva presenta un picco iniziale, il rischio di ritardo è significativo.

Quali possono essere le classi di servizio in funzione del costo del ritardo?

Accelerato (Expedite). Il costo del ritardo aumenta molto rapidamente.

Accelerato (Expedite)

Data fissa (Fixed date). In una data relativamente vicina, entro due volte l’intervallo della distribuzione del lead time, ci aspettiamo un costo del ritardo distribuito secondo una funzione a gradino (o una funzione a curva S inclinata ma molto vicina a una funzione a gradino) in un giorno noto e molto specifico, tipico della domanda stagionale o di eventi specifici (come tornei sportivi o festività pubbliche).

Data fissa (Fixed date)

Standard. Il costo del ritardo aumenta inizialmente con un andamento convesso e infine concavo. La forma è una curva a S inclinata che cresce su un periodo di tempo medio-lungo.

Standard

Intangibile (Intangible). Il nome deriva dal fatto che il costo del ritardo è intangibile o insignificante per un periodo superiore a 1 o 2 cicli dell’intervallo di lead time. Sebbene la classe di servizio Intangibile sia stata modellata come se avesse una forma di funzione convessa, in realtà si tratta pure di una curva a S inclinata che cresce su un periodo di tempo molto lungo. Il lavoro appartenente alla classe di servizio Intangibile tipicamente è quello relativo ad aggiornamenti di piattaforma, introduzione di nuovi componenti o tecnologie in un progetto esistente, o riprogettazione, rielaborazione o, in generale, manutenzione di un sistema di prodotto o servizio.

Intangibile (Intangible)

Classe di servizio – come viene trattata rispetto ad altre richieste?

Tipicamente nel pondo dei servizi e dei progetti si parla di “mettere in priorità” le lavorazioni. Ma a bene vedere il termine è ambiguo. Priorità può significare che qualcosa è selezionato (o scelto) e quindi “prioritario”. Può anche implicare la sequenza, l’ordine o la regola di accodamento in cui un insieme di elementi devono essere lavorati. Oppure la priorità può implicare il momento in cui qualcosa dovrebbe essere programmato: ora, più tardi e, se sì, quando; o non del tutto. Oppure può implicare il modo in cui qualcosa viene trattato una volta inserito nel sistema: la sua classe di servizio.
Le tabelle di triage presenti nel metodo Kanban sono state progettate per facilitare la decisione rispetto agli ultimi due dei quattro significati della priorità. Vi aiuteranno a programmare il lavoro e a determinare la classe di servizio da applicare a un elemento di lavoro in base alla data di inizio prevista. Le tabelle di triage sono scaricabili dal sito Kanban+ della Kanban University.

Questo articolo è liberamente tratto e tradotto dal sito di Mauvisoft, clicca qui per leggere il contenuto originale.

Pubblicato il

Pillole di Kanban applicato: affrontare il problema dei tempi di attesa dei passaporti con Kanban

Ai recenti Stati Generali delle Ingegnerie Digitali, tenutisi a Milano gli scorsi 18 e 19 Aprile, ho fatto un intervento dal titolo ‘Utilizzare lean e kanban per il miglioramento dei servizi: l’Enterprise Services Planning (ESP)‘ che ho voluto concludere con una provocazione: Proviamo ad applicarlo… per esempio per risolvere il problema dei tempi di attesa dei passaporti?
Perché sono convinto che si potrebbe affrontare il problema dei tempi di attesa dei passaporti con Kanban. L’applicazione di concetti e pratiche del metodo Kanban potrebbe infatti dare una grossa mano a snellire tutti quei i servizi al cittadino che si trovano a essere ‘ingolfati’, non solo il rilascio dei passaporti. Migliorando i livelli di servizio offerti ai cittadini e al contempo riducendo la pressione e il conseguente stress lavorativo che grava sugli uffici preposti.

Tempi di attesa troppo lunghi

Non conosco in dettaglio il flusso di lavoro per il rilascio dei passaporti, osservo il problema della lunghezza dei tempi di attesa dalla prospettiva del semplice cittadino. Sono però ben noti al pubblico due fenomeni ai quali si sente imputare la forte crescita di richieste di passaporti: la brexit, che obbliga chi si reca nel Regno Unito a dotarsi di passaporto (prima bastava la carta di identità) e la pandemia, che ha fortemente limitato i viaggi per un paio d’anni, facendo rinviare a molti il rinnovo del passaporto. Ora che nel dopo-pandemia c’è la frenesia di tornare a viaggiare, i due fattori menzionati hanno generato un carico superiore a quello che le strutture preposte sono evidentemente in grado di evadere in tempi rapidi.
La situazione non è omogenea, ma in alcune zone di Italia (per esempio a Milano) occorre attendere diversi mesi per ottenere il passaporto. Come sempre accade il servizio in sofferenza ha ingenerato meccanismi distorti, c’è chi acquista biglietti aerei low cost per ottenere un appuntamento prioritario e pare che a un certo punto ci fosse anche chi faceva incetta di appuntamenti per rivenderli a caro prezzo. Questi espedienti non possono essere ovviamente la soluzione, invece il sovraccarico di un servizio al cittadino è una tipica circostanza che può trarre un grande beneficio dall’applicazione del metodo Kanban.

Immagine fonte Wikipedia licenza Creative Commons CC BY 3.0

Introdurre le classi di servizio

In effetti alcune pratiche suggerite dal metodo Kanban già stanno venendo applicate. Recentemente la Polizia di Stato ha introdotto l’Agenda Prioritaria degli appuntamenti, per gestire in modo codificato le situazioni in cui il cittadino non può attendere i mesi necessari per il rilascio standard.
Tale pratica in Kanban la si definirebbe come l’introduzione di classi di servizio, ovvero il modo in cui qualcosa viene trattato una volta inserito nel sistema. In un sistema Kanban si attribuisce la classe di servizio a una determinata lavorazione in base a quanto costa ritardare detta lavorazione. Più elevato è il costo di rimandare la lavorazione, prima si dovrà effettuare la lavorazione.
Nel caso dei passaporti, i cittadini che lo richiedono non sono tutti nella stessa situazione, qualcuno può aspettare il tempo di evasione standard mentre qualcun altro ha necessità di viaggiare in tempi brevi e non può aspettare. Nel sistema di prenotazione dei passaporti possiamo quindi identificare due classi di servizio: una che potremmo definire come ‘standard‘, il passaporto viene rilasciato nei tempi tipici previsti dal sistema (qualche mese) e un’altra classe di servizio che potremmo definire come ‘accelerata‘ (‘expedite‘ nell’originale in inglese), che permette il rilascio del passaporto in base all’Agenda Prioritaria (qualche giorno).

Introdurre le policy per il servizio

Le classi di servizio però da sole non sono sufficienti per stabilizzare il servizio, occorre anche definire delle regole per l’assegnazione di una determinata classe di servizio a una lavorazione. Lasciando libero l’utente di attribuire alla propria lavorazione una classe di servizio, ci si troverebbe solo con lavorazioni di classe ‘accelerata’ e sappiamo che se tutto diventa urgente, allora nulla è più urgente perché chi si trova a dover effettuare la lavorazione non riesce più a indentificare le vere urgenze. E infatti se andiamo a vedere nel sistema di prenotazione dei passaporti la pagina dell’Agenda Prioritaria, un avviso in testa alla pagina indica chiaramente le regole per ottenere un appuntamento:
“Gli appuntamenti disponibili valgono solamente per i residenti nella provincia.
Rientrano tra le condizioni di priorità i viaggi da intraprendere nei prossimi 30 giorni per le seguenti motivazioni: studio, lavoro, salute, turismo.
All’atto dell’appuntamento verrà richiesta la documentazione comprovante l’effettiva priorità e la data del viaggio.”
Tale pratica in Kanban sarebbe definita come l’introduzione di policy di servizio, appunto le regole da applicare per garantire un corretto funzionamento del servizio. Quindi regole non solo per l’assegnazione della classe di servizio, ma regole in generale che permettano al servizio di funzionare in modo stabile e affidabile. E infatti se andiamo a leggere il vademecum sul sito della Questura di Milano, si può notare che si applicano anche alcune ulteriori regole, ovvero che nell’Agenda Ordinaria si possono “prendere fino ad un massimo di n.4 appuntamenti complessivi” mentre nell’Agenda Prioritaria si possono “prendere fino ad un massimo di n.2 appuntamenti non modificabili”. Questo a ulteriore garanzia del corretto utilizzo del sistema di prenotazione e per evitare almeno il più possibile i funzionamenti distorti.

Accelerare il collo di bottiglia

Osservata con la lente del metodo Kanban, la direzione intrapresa per la gestione del sistema di rilascio dei passaporti è corretta, innanzitutto è necessario stabilizzare il sistema. Una volta che il sistema è stabile, analizzando e misurando le fasi del flusso di lavoro, è possibile individuare il collo di bottiglia e, come ho già illustrato in un precedente articolo a proposito dei flussi autostradali, vincolare tutto il sistema alla velocità del proprio collo di bottiglia.
Al flusso che procede alla stessa velocità del collo di bottiglia è possibile quindi applicare i concetti propri della teoria dei vincoli e della teoria delle code, provando ad accelerarlo, per diminuire il tempo medio di lavorazione, nel nostro caso il tempo medio di rilascio dei passaporti, e per aumentare per converso il numero di passaporti rilasciati per unità di tempo (o come si chiama in Kanban, ‘throughput‘ o ‘delivery rate‘).
C’è da augurarsi che le autorità preposte vogliano portare fino in fondo il percorso intrapreso per la gestione dei passaporti, applicando questi concetti per migliorare questo e altri servizi ai cittadini.

Pubblicato il

Migliora l’efficacia di Scrum con Kanban: Microsoft XIT Sustaining Engineering (case study in inglese)

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.

Leggi il case study sul sito della Kanban University

Scarica l’Executive Summary di questo caso dal sito della Kanban University

Pubblicato il

Migliora l’efficacia di Scrum con Kanban: BBVA Finance Division (Spain) – From Team-Focused to Fit-for-Purpose in One Year (case study in inglese)

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

E il viaggio continua. . . .

Leggi il case study sul sito Kanban+ della Kanban University

Scarica l’Executive Summary di questo caso dal sito della Kanban University

Pubblicato il

Migliora l’efficacia di Scrum con Kanban: un percorso alternativo all’agilità aziendale

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.

Pubblicato il

Pillole di Kanban applicato: conversazione tra un padre (Kanban Coach) e il figlio adolescente

“Un problema ben esposto è un problema per metà risolto.”
Charles F. Kettering

“Oggi mi hanno chiamato da scuola e mi hanno detto che sei sempre in ritardo….”.
“Io?! Ma che…. cioè, non SEMPRE… di tanto in tanto forse sì, ma non sempre, anzi molto spesso sono puntuale!”
“Va bene figlio mio, facciamo qualcosa!”

Qualche mese dopo, mostrando un grafico con la distribuzione statistica dei ritardi.

distribuzione statistica dei ritardi

“Figlio mio, questa è la metrica di quanto spesso sei puntuale o in ritardo, nel complesso”.
“Chi? Io? Stai scherzando!”.
“No, non sto scherzando, questa è la tua situazione negli ultimi mesi, come puoi vedere arrivi puntuale il 68% delle volte, mentre arrivi entro 15 minuti di ritardo il 93% delle volte e il 99% delle volte sei lì entro mezz’ora di ritardo, ecco tutto”.
“Papà sei un dannato nerd!”.
“Sì lo so figlio mio, ma questi sono fatti, quello che gli psicologi chiamerebbero un esame di realtà. Qual è il numero di ritardi che la scuola è pronta ad accettare?”.
“Non ne ho idea, papà”.
“Va bene, allora controlla con loro, anche se sospetto che abbiano un’aspettativa molto più bassa rispetto al tuo attuale numero di ritardi; tra l’altro la buona notizia è che la distribuzione statistica è ragionevolmente una curva cosiddetta ‘thin tailed’, il che significa che sei costantemente prevedibile…”.
“Cos’è questa roba statistica, papaaaa?! Dimmelo in un modo che anche il gatto possa capire!”.
“Intendo dire che fai le cose più o meno sempre allo stesso modo, quindi probabilmente basta che tu anticipi di mezz’ora la tua sveglia al mattino e sarai sempre puntuale, se lo vorrai….”
“Dai papà, perché dovrei svegliarmi mezz’ora prima…. posso invece correre ed essere puntuale!”.
“È una tua decisione figlio mio, sei tu il padrone del tuo destino, sei tu il capitano della tua anima….”
“Anche la cavolo di poesia ora, smettila papà, ho capito….”

Questa conversazione e i personaggi in essa rappresentati sono puramente fittizi con lo scopo di spiegare ai lettori il Metodo Kanban

traduzione in italiano del post originale pubblicato su LinkedIn https://www.linkedin.com/feed/update/urn:li:linkedInArticle:7164921766983725056/

Pubblicato il

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.

il semaforo in autostrada

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.

Pubblicato il

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

Pubblicato il

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.

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.

carichi di lavoro del sistema misurati per orario della giornata

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.


Pubblicato il

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, e che 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, 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.