Il Caso E80 Group

Il progetto in E80 Group è iniziato con un esperimento nel febbraio 2021, in cooperazione con Maxwell Consulting, per iniziativa della direzione aziendale.

Insieme a Daniela Rinaldi, memori delle esperienze precedenti, coinvolgiamo i capi funzione direttamente o indirettamente interessati allo sviluppo di nuovi prodotti, predisponendo un breve percorso formativo pensato per  loro. Senza questo passaggio fondamentale non saremmo partiti.

L’interesse mostrato ha spinto la direzione, nonostante le nostre perplessità, a effettuare un esperimento su due progetti di sviluppo prodotto già in corso.

I 2 progetti vedono coinvolti due Product Manager dell’azienda dinamici e con esperienza, Gianluca Clementini e Alberto Lodini, che sono entrati velocemente nel ruolo di Product Owner. Con l’aiuto del direttore tecnico Marco Casarini, figura storica dell’azienda e sponsor dell’esperimento, individuiamo in Francesco Monica e Juan José Contreras González, che lavorano nella Ricerca e Sviluppo, le persone ideali alla quali chiedere un supporto per questa prova di transizione agile, promuovendoli sul campo al ruolo di Scrum Master.

Dopo una rapida formazione dei team operativi siamo entrati subito nel vivo dei progetti, in particolare partendo con una rivisitazione delle ragioni di ciascun progetto e individuando la proposta unica di valore con il Lean Canvas.

Nonostante si trattasse di una rivisitazione, l’iniziativa è stata molto apprezzata perché ha fatto sì che persone dell’area vendite e tecnici cooperassero nella definizione di requisiti già definiti in una forma preliminare ma ulteriormente affinati nel frattempo. Questo ha permesso di lasciare emergere le esigenze commerciali non sufficientemente chiarite, e di far lavorare insieme i progettisti meccanici, elettrici e software con gli acquisitori dei materiali e le persone della produzione, come mai era avvenuto in precedenza con gli approcci tradizionali a cascata.

Sono state introdotte poi alcune metodologie operative, come:

• La scomposizione del progetto con lo Story Mapping.
• La distribuzione delle caratteristiche tecniche del prodotto sugli elementi principali del Backlog mediante la Matrice di Impatto delle Caratteristiche.
• Lo svolgimento ritmato dei lavori con lo Scrum, comprese le Retrospettive.
• Il Daily Scrum di officina con i Flash Meeting.
• La gestione dei rischi di progetto.
• Lavagne digitali per la cooperazione a distanza.
• Un sistema di pianificazione web per la gestione agile del progetto.

Si è sperimentata la cooperazione sia in presenza che a distanza, in una modalità ibrida confacente con la distribuzione nel raggio di alcune decine di chilometri delle unità produttive di E80 Group, che potremmo definire come una “azienda diffusa”.

Sono state introdotte le Retrospettive, che hanno consentito di apportare piccoli miglioramenti ai processi e di far crescere la motivazione dei team. Questi ultimi si sono appassionati a tale modo di lavorare, manifestando apertamente il desiderio che divenisse una loro modalità di lavoro permanente.

Sebbene i progetti fossero già in corso, i risultati dal punto di vista dei feedback dei partecipanti sono stati molto buoni: meccanici, elettronici, gestione materiali e sviluppatori SW lavoravano insieme ascoltandosi e iniziando a comprendere le esigenze gli uni degli altri.

I team hanno infatti iniziato a cooperare raggiungendo velocemente uno spirito di squadra che ha sorpreso sia Daniela che me, indice di una cultura aziendale che ancora ricorda lo spirito artigiano delle sue origini.

«Sono le nostre paure a limitare i nostri successi. Non gli errori» è uno degli slogan che si trovano quando si entra in azienda.

Tale approccio ha anche evidenziato i punti deboli dello Sviluppo Prodotto di E80 Group, tipici della maggioranza delle imprese che ho conosciuto, come la difficoltà a gestire lo sviluppo dei prototipi dei nuovi prodotti all’interno del flusso produttivo dei materiali per gli ordini clienti.

È emersa anche la criticità di avere un processo di gestione dei materiali che, per  la ragione appena indicata, non è tutt’oggi integrato con il processo di progettazione. 

È stata rapidamente compresa l’importante opportunità che il processo agile si realizzi anche in fabbrica, e che vi sia la necessità di persone degli Acquisti da dedicare al progetto.

I due PO molto operativi nel campo del business e chiamati a questo ruolo di guida dei progetti hanno vissuto l’esperimento così come qui riportato con le loro parole.

Gianluca Clementini:

Nel momento in cui ho iniziato questa esperienza insieme a Claudio la cosa più difficile è stata riuscire a convincere le persone che un modo diverso di affrontare lo sviluppo di un progetto nuovo avrebbe potuto dare valore aggiunto ed efficienza.

Ciò che ha funzionato e ha dato la svolta all’applicazione del processo agile è stato il momento della creazione del team di lavoro, gli incontri periodici di condivisione dello stato del progetto, gli incontri di presentazione dello stato dei lavori agli Stakeholder: in queste fasi ho visto un grande coinvolgimento di tutti i partecipanti, probabilmente dovuto alla responsabilizzazione di ognuno nel portare avanti un certo numero di task e condividerne con il resto del team i risultati.

Posso dire che il valore aggiunto è stato rappresentato dal continuo allineamento di tutti i reparti su ciò che si stava portando avanti e dalla responsabilizzazione di ognuno per il raggiungimento dell’obiettivo finale.

Come in tutte le esperienze nuove, esistono anche i momenti di difficoltà; nel caso particolare si sono verificati dal momento di fine progettazione fino alla realizzazione fisica del prototipo. Qui sono emerse problematiche riguardo a ritardi sull’approvvigionamento materiali che hanno ritardato il progetto di un paio di mesi, rendendo il lavoro del team molto duro. La pressione dall’esterno si è fatta sempre più intensa, e qui ho notato che il lavoro di squadra si è molto indebolito e sono emerse solo le difficoltà del singolo inteso come reparto, fornitore ecc…

La “Lesson Learned” di tutto questo è che è necessario avere la forza di agire nel medesimo modo sia quando le cose vanno bene che quando emergono le criticità, e in ogni istante deve essere chiaro l’obiettivo finale, che è quello del team e non quello individuale.

Tutto ciò può avvenire con il tempo e con il coinvolgimento delle persone giuste nei momenti opportuni.

Alberto Lodini:

Ho un ricordo molto vivido del mio primo approccio all’Agile – anche perché decisamente traumatico – avvenuto proprio con Claudio e Daniela quando iniziarono il loro percorso formativo di un ristretto numero di persone in E80, di cui ovviamente facevo parte anch’io.

Il loro entusiasmo e i tentativi per creare un rapporto di fiducia, sia in loro che nella metodologia agile, si scontravano continuamente con la mia visione, fondata principalmente su precedenti esperienze troppo distanti da quanto raccontato.

Il glossario utilizzato, a me per lo più sconosciuto, non aiutava, e nemmeno i Case Studies portati puntualmente ad esempio non riuscivano ad aprirmi occhi e meningi perché ritenuti troppo lontani dal mio “mondo”. In tale clima di estremo scetticismo, più per volontà altrui che mia, iniziammo comunque il primo vero cammino agile affrontando il progetto Easy Store Girona. Si trattava di sviluppare un nuovo veicolo autonomo, denominato Satellite (o, per i più intimi, “maialino”), impiegato in integrazione con una flotta di LGV (Laser Guided Vehicle), sempre di nostra produzione, nella realizzazione di magazzini automatici per lo stoccaggio di pallet in multiprofondità. La vera difficoltà era legata al fatto che il progetto doveva essere direttamente sviluppato su un ordine di vendita avente importanti penali su ritardi di consegna e relativa a un cliente strategico per l’azienda: in pratica non era possibile fallire. Ad ampliare ulteriormente i miei dubbi vi era il fatto che il progetto in questione era già iniziato, anche se non da molto, con il tipico approccio waterfall, e molte decisioni in ambito progettuale erano già state prese. Dentro di me sapevo che non ero l’unico all’interno del Core Team –  composto da una decina di tecnici provenienti da diversi dipartimenti aziendali – a nutrire dei dubbi, ma in quel momento il mio ruolo richiedeva di esternare fiducia per creare spinta e motivazione in una fase così delicata, e così ovviamente feci.

Anche la definizione dei ruoli che si sarebbero poi dimostrati di fondamentale importanza – quali Product Owner, Scrum Master, Core Team, Shell Team e Stakeholder – era stata fatta assecondando le idee e la competenza di Daniela e Claudio, piuttosto che per una reale comprensione di quanto stava avvenendo. Comprensione che, personalmente, iniziò solo al termine della sessione in cui, tutti insieme, andammo ad affrontare il Lean Canvas.

Non fu certo, ancora una volta, la terminologia utilizzata ad aiutarmi, bensì l’apporto che dette una parte di azienda fino a poco prima da me sempre ritenuta ostile alla costruzione di un vero progetto in quanto spesso non competente, improntata a continue richieste senza adeguate motivazioni e poco rispettosa del lavoro svolto all’interno delle Operations. Ebbene sì: chi mi fece aprire gli occhi fu l’apporto dato dalla parte commerciale che, inserita nella condivisione iniziale di definizione delle motivazioni di progetto, con lucidità e puntualità di argomentazioni diede un contributo fondamentale nella compilazione di quello che, man mano che veniva riempito, mi accorgevo essere il più straordinario documento di specifica tecnica mai visto prima: in un unico e semplice colpo d’occhio era riportato, con disarmante sintesi, tutto ciò che il nostro progetto doveva contenere o non contenere, il perché di tutto ciò e quali sarebbero stati priorità e obiettivi fondamentali. Il tutto con l’avallo o addirittura la compiacenza del commerciale: non riuscivo a crederci…

Poco dopo iniziarono gli Sprint con la partecipazione del team di lavoro. A eccezione di qualche rara occasione di Brainstorming a inizio progetto, non mi era mai capitato di lavorare a un tavolo con la presenza contemporanea di così tanti enti tecnici, e la curiosità era forte: come avrebbe fatto il Softwarista o l’uomo di produzione a non annoiarsi durante riunioni che avrebbero interessato solo meccanici ed elettrici per diverse settimane? Bastarono veramente pochi incontri per farmi capire quanto lontano io fossi dalla realtà agile: non solo Softwarista e produzione non si annoiavano, ma fornivano interessanti punti di vista su gran parte degli argomenti, regalando spunti inediti per chi aveva sempre ragionato a cascata, quindi pensando che i progetti partissero dalla costruzione meccanica, poi elettrica ecc.

La partecipazione e l’interesse da parte di tutto il team si rivelarono da subito talmente elevati da farmi apparire la cosa quasi irreale; mi tornarono in mente immagini di tanto tempo fa quando, dopo anni di allenamenti in squadra, si scendeva in campo affiatati con la voglia di giocare tutti uniti per vincere. Così la “squadra” di progetto iniziò a giocare la partita, Sprint dopo Sprint, creando ovviamente il proprio prodotto, ma creando anche un ambiente di forte condivisione in cui le scelte si prendono insieme e dove viene inoltre naturale la formazione reciproca in quanto ognuno insegna sempre qualcosa agli altri.

Alla fine, il risultato più sorprendente non è stata la creazione del nuovo prodotto in sé, il Satellite, peraltro avvenuta con soddisfazione e nel rispetto dei tempi, ma anche e soprattutto la creazione di un gruppo di persone che ha continuato a imparare e crescere grazie allo scambio di competenze reciproche, comprese quelle provenienti dall’area commerciale, e che certo avranno oggi più consapevolezza e ulteriori strumenti per affrontare al meglio le future sfide lavorative.