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

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.