Nel 2015, la divisione Software e informatica di Agilent era in difficoltà. Nel bel mezzo di un importante rilascio di un nuovo prodotto, il team si è accorto che non sarebbe stato in grado di rispettare la data di rilascio. Non era la prima volta; la divisione aveva infatti rispettato solo il 20% circa delle date di rilascio.
Le date di rilascio non rispettate hanno creato un'enorme pressione sui team software. "Quando i team sono sotto pressione prendono decisioni sbagliate", ha dichiarato John Sadler, VP e GM della divisione Software e informatica di Agilent. "Sacrificano la qualità e finiscono per pagarla sul back-end. Nel complesso, il team era relativamente demoralizzato e ha avuto difficoltà a rispettare le date di rilascio".
Parte della sfida consisteva nel fatto che la divisione Software e informatica di Agilent contava 150 dipendenti distribuiti in due continenti che collaboravano con appaltatori in un terzo continente. Era una divisione tentacolare di ingegneri, e di addetti al marketing, al controllo qualità, all'assistenza tecnica e alle vendite. L'azienda aveva bisogno di stabilire nuove pratiche del team per aiutarlo a fornire valore più velocemente, con qualità e prevedibilità maggiori, e a rispondere meglio ai cambiamenti. In breve, serviva una trasformazione Agile.
Inizio della trasformazione Agile
Nel 2015 Agilent ha delineato una trasformazione Agile con i seguenti obiettivi:
- Concentrarsi sulla prevedibilità
- Sviluppare una cadenza di rilascio affidabile
- Creare un ciclo di consegna riproducibile
- Promuovere il miglioramento continuo
L'approccio Agile mette la qualità al primo posto, la cadenza riproducibile al secondo e l'ambito al terzo. "Quando i team non seguono queste priorità, spesso mettono l'ambito al primo posto, la timeline viene imposta sotto forma di scadenza e la qualità va sprecata", ha spiegato Sadler.
Agilent desiderava stabilire processi Agile che integrassero le priorità nel processo di sviluppo del software. Stabilire il miglioramento continuo come valore primario ha comportato un cambiamento culturale che ha creato il contesto per la trasformazione. Mettere la qualità al primo posto significava migliorare la soddisfazione dei clienti sia esterni che interni. Agilent era disposta a sacrificare l'ambito per soddisfare le aspettative dei clienti sul campo.
Come seconda priorità, la divisione doveva creare un ciclo di rilascio prevedibile che potesse essere perfezionato nel tempo. Un ciclo di sviluppo più breve e più affidabile significava che il team avrebbe evitato i problemi e mitigato i rischi in anticipo per garantire tempi di risposta adeguati.
Trasformazione Agile passo passo
A partire da agosto 2015, Agilent ha stretto una partnership con cPrime, una società di consulenza esperta nell'aiutare le organizzazioni ad affrontare le trasformazioni Agile, e successivamente con TCGen, una società di consulenza leader nello sviluppo di prodotti.
Implementare lo strumento di gestione dei prodotti Agile Jira è stato il primo passo. Jira ora fornisce un unico sistema di registrazione di tutto il lavoro di sviluppo di Agilent, che include tutti i team globali distribuiti. Lo strumento garantisce trasparenza tramite un'unica fonte di riferimento in cui sono presenti i punti in programma, le relative tempistiche e ciò che è stato realizzato dai team.
Adattato con l'autorizzazione di cPrime, Inc.
La formazione Agile era la priorità successiva, con l'obiettivo di insegnare i principi e i concetti Agile e stabilire una terminologia comune. cPrime ha descritto le sue best practice per il modello RAGE (Agile Governance in the Enterprise) in cui sono delineate le cerimonie chiave, tra cui le riunioni di pianificazione dei rilasci, le riunioni scrum-of-scrum del team, le riunioni scrum-of-scrum degli owner di prodotto, le riunioni di backlog grooming per il rilascio, la revisione del rilascio e le retrospettive sul rilascio.
Agilent ha anche stabilito ruoli di owner di prodotto di area e di program manager e ha misurato l'avanzamento con grafici burn-up. L'azienda ha inoltre adottato tecniche decisionali leggere, eseguito cerimonie, utilizzato artefatti Scrum Agile e adottato altre pratiche Agile.
Agile in azione
Nel novembre 2015, la divisione Software e informatica di Agilent ha tenuto Sprint zero, una sessione di pianificazione Agile di due settimane con quattordici team partecipanti. È stato sviluppato un piano di rilascio del prodotto della durata di otto mesi per il sistema di dati per cromatografia OpenLAB.
Le attività di Sprint zero includevano tre categorie:
- Formare i team sugli obiettivi aziendali e tecnici, sui promotori e sui requisiti generali di OpenLab attraverso presentazioni e poster.
- Usare le nuove tecniche apprese per sviluppare i requisiti e fare una stima di story, epic e difetti.
- Disporre story, epic e difetti nella board Pianificazione dei rilasci e contrassegnare tutte le dipendenze tra i team.
Agilent ha presto scoperto che i miglioramenti Agile andavano oltre il progetto pilota. Uno dei primi indicatori di successo è stato interno. "Poiché dovevamo collaborare con altre divisioni di Agilent, fare ciò che avevamo previsto è stato estremamente importante", ha affermato Sadler.
Agilent ha rilevato anche miglioramenti esterni. Il feedback dei clienti è diventato determinante per una maggiore reattività dei team aziendali ai cambiamenti del mercato. Includendo i clienti nelle prime fasi del processo di sviluppo, Agilent ha incrementato la qualità del software riducendo nel frattempo i rischi legati al mercato e all'integrazione.
Una delle intuizioni di Agilent è stata quella di includere le storie sottoposte ad upgrade in ogni epic Agile per considerare l'epic come completato. Babita Jain, direttrice del reparto di qualità del software, e Stefan Weiss, responsabile dell'integrazione software di Agilent, hanno guidato l'implementazione della trasformazione e aiutato i team a comprendere l'ambito complessivo del progetto. "Non consideravamo un epic come completato se questo non includeva gli upgrade", ha detto Jain.
La trasformazione Agile ha migliorato non solo la qualità, ma anche l'affidabilità. Nel 2016, il sistema di dati per cromatografia OpenLAB è stato rilasciato in tempo. Dalla trasformazione Agile, Agilent ha rilasciato software con una cadenza costante e i difetti segnalati sul campo sono diminuiti.
Misurazione del successo
Agilent definisce e misura il successo della sua iniziativa Agile con "bassi tassi di errore sul campo e alta fedeltà dei clienti", ha affermato Sadler. Anche la fidelizzazione dei clienti è fondamentale. Nel mercato maturo e competitivo del settore delle scienze naturali, l'abbandono da parte dei clienti è un pericolo. La capacità di vendere ai vecchi clienti un nuovo sistema è essenziale.
Di seguito sono riportate quattro metriche critiche rese possibili dal modello di capacità basato su Jira di Agilent:
Grafici burn-down/burn-up
In precedenza, Agilent misurava il lavoro in ore di progettazione, giornate/persona o Story Point. Ora tutti usano i grafici burn-up per tenere traccia del lavoro completato e della mole totale di lavoro. I grafici burn-down mostrano il lavoro rimanente.
Percentuale di capacità immessa sul mercato (payload)
L'abilità di modellare e monitorare la capacità gioca un ruolo essenziale nel modo in cui Agilent misura il successo. Jira ha consentito ad Agilent di creare un modello di capacità dettagliato. "Questo modello ci ha permesso, durante la fase di pianificazione, di comunicare al team di marketing con quanti Story Point doveva collaborare per un rilascio. Il team di marketing può così classificare il backlog per adattarsi a tale capacità", ha detto Sadler.
Conteggio e tempo medio per il rilascio delle correzioni
Il modello di capacità ha fornito una vista più granulare che ha permesso ad Agilent di vedere la capacità impiegata per la correzione dei difetti critici o gravi segnalati sul campo rispetto a quella impiegata per la correzione dei difetti rilevati e segnalati dal team addetto alla qualità.
Percentuale di tempo impiegato per correggere i difetti rilevati mediante test manuali
Il modello di capacità aiuta Agilent a misurare il tempo impiegato per creare funzionalità che i clienti apprezzano rispetto al tempo impiegato per la manutenzione o la gestione dei prodotti esistenti.
In poco più di tre anni la divisione ha più che raddoppiato la percentuale di capacità dedicata al lavoro a valore aggiunto, passando dal 30 al 65 percento. Con il miglioramento della qualità del software, guidato dal nuovo approccio Agile, si sono inoltre verificati meno difetti da correggere in un secondo momento.
Un anno dopo aver iniziato il processo di trasformazione Agile, i membri del team di Agilent descrivono diversi scenari "prima" e "dopo":
 | Prima: le prestazioni venivano misurate in ore di progettazione, giornate/persona o Story Point. |
|---|---|
 | Prima: i team con diversi livelli di formazione Agile definivano in modo diverso epic, story e sottotask. |
 | Prima: gli Scrum Master scrivevano il codice, guidavano le riunioni del team e valutavano le priorità delle funzioni. |
 | Prima: potevano essere approvate delle funzioni con bug che si portavano dietro i difetti nelle fasi di sviluppo successive. |
 | Prima: i problemi spesso si verificavano all'ultimo minuto, causando panico e ritardi significativi. |
 | Prima: non esisteva uno strumento per misurare la capacità di lavoro di un team. |
Il futuro Agile in Agilent
Come ogni cultura che valorizza il miglioramento continuo, la trasformazione Agile di Agilent non è affatto completa. Continuare ad abbreviare la durata del ciclo e affinare la capacità di ottenere informazioni tempestive dal feedback del mercato (alcuni degli elementi chiave delle metriche DevOps) rientrano tra i passaggi successivi.
Agilent ha già ridotto drasticamente la durata del ciclo, suddividendo i rilasci annuali in due cicli di sei mesi, anche se l'azienda commercializza i rilasci ogni anno. La società prevede di dimezzare ulteriormente la durata del ciclo, passando a una cadenza trimestrale.
Anche il coinvolgimento precoce e frequente dei clienti nel processo di sviluppo è un processo sottoposto a miglioramento continuo. Sadler riferisce che il suo gruppo ritiene che, quando ci sono prove chiare del feedback del mercato, ci sia meno arbitrato tra gli interessi concorrenti nelle discussioni sull'ambito del prodotto. Mantenere la qualità e l'usabilità per i clienti sul campo è una priorità costante e il coinvolgimento continuo degli utenti aiuta a mantenere le priorità aziendali: la qualità al primo posto, seguita dalla cadenza dei rilasci e dall'ambito.
Lezioni apprese
Sadler attribuisce il successo al suo team, compresi i leader Jain e Weiss, che hanno adottato lo sviluppo Agile come metodo per promuovere un miglioramento rapido e continuo. L'uso degli strumenti giusti, come Jira e Confluence, ha permesso al team di consolidare il lavoro in un'unica posizione e misurare l'avanzamento.
Agilent ha scoperto che una trasformazione Agile richiede uno sponsor che supervisioni la ricerca e lo sviluppo, l'inbound marketing e la qualità. "Se non si riesce a trasformare tutti e tre questi aspetti, la trasformazione non avrà successo", ha affermato Sadler. "Non è possibile impegnarsi in una trasformazione Agile coinvolgendo soltanto il team R&S". La cosa più importante non è il lavoro svolto all'interno dei diversi team, ma il modo in cui questi lavorano insieme.
Agilent ha inoltre ritenuto essenziale eliminare il presupposto secondo cui la perfetta comprensione delle esigenze dei clienti risieda esclusivamente all'interno dell'azienda. L'approccio Agile consiste nel rilasciare i prodotti secondo una cadenza affidabile e ricevere quindi direttamente il feedback dei clienti. Questo approccio richiede una mentalità in base a cui le date di rilascio sono sacre e il team rilascia il prodotto così com'è quando arriva la data prefissata.
Infine, suggerisce Sadler, il framework Agile rende visibili i problemi. Ad esempio, espone le lacune di capacità. Rivela le parti senza valore aggiunto del processo che causano ritardi e fanno emergere errori di qualità. Il passaggio da un approccio a cascata a un approccio Agile non richiede solo cambiamenti nelle modalità di lavoro dei team, ma anche un cambiamento culturale. Agile guida una cultura del miglioramento continuo che è decisamente contagiosa.
