Agile e il Caso Breton

Quando arrivai in azienda, nell’autunno del 2010, il presidente – molto attivo nello sviluppo dei prodotti con continui suggerimenti ai team – mi chiese di proporgli una diversa modalità organizzativa, che rendesse l’azienda capace di proseguire senza rallentamenti anche quando egli non fosse stato più in grado di dare la spinta necessaria. Era una richiesta molto illuminata e che guardava al futuro, e mi ricordo che gli posi due condizioni che accettò e rispettò negli anni che seguirono e delle quali sono stato personalmente garante:

• Vince l’idea migliore, anche se viene dalla persona con la posizione gerarchica minore.
• Per sviluppare cose molto innovative occorre rischiare, e pertanto occorre accettare il fallimento, che è inevitabile possa accadere.

La motivazione che addussi per spingere la direzione aziendale a intraprendere una nuova modalità di sviluppo dei prodotti, assolutamente rivoluzionaria per il contesto aziendale, fu la valutazione del costo del ritardo che l’azienda inconsapevolmente sosteneva.

Per fortuna non partivo da zero, e quando arrivai in Breton portai con me le esperienze ancora sperimentali fatte dal 2008 con l’approccio agile. A partire dal 2013 iniziai a effettuare con i miei team i primi esperimenti di approccio iterativo e incrementale. Nel 2014 mi resi conto di avere bisogno di un aiuto, e coinvolsi Stefano Leli di Agile Reloaded; insieme a lui e ai miei team lavorammo per mettere a punto un processo sostenibile di sviluppo di prodotti fisici in modalità agile.

Per prima cosa potenziai il reparto di ingegneria a supporto delle vendite, con l’obiettivo di avere persone che potessero approfondire i bisogni del mercato grazie alla loro continua interazione con i clienti. Queste persone divennero in seguito i primi Product Owner, che portammo a guidare le riunioni di valutazione dei prodotti impiegando a volte i Vision Canvas e molto più frequentemente i Lean Canvas.

In un’azienda tecnica come questa, il marketing dei nuovi prodotti è governato principalmente dai due fratelli titolari dell’azienda. Tale ruolo attivo dei PO che guidavano lo sviluppo in team dei Canvas alla presenza dei due fratelli, dei dirigenti e dei capi funzione interessati fu molto apprezzato.

Questo spostò molto la focalizzazione dello sviluppo da una prospettiva molto tecnica a una prospettiva orientata al valore portato al cliente. 

I PO si rivelarono assai efficaci anche nelle attività promozionali legate al prodotto, occupandosi delle quattro dimensioni del Marketing Mix e cooperando con l’Ufficio Marketing nella creazione dei contenuti promossi nelle riviste, sul Web e alle fiere di settore.

Il ruolo dei Product Owner ne risultò pienamente compreso da parte della direzione aziendale, tanto che a due di loro – fra i più esperti nelle rispettive linee di business – fu conferito il ruolo di Business Developer.

Ne risultò una organizzazione a matrice, dove i Team Leader dello sviluppo dei nuovi prodotti non erano più i “capi dei gruppi di progettazione”  chiamati “capigruppo” – cioè il Middle Management con la competenza di dominio – ma i Product Owner.

Volutamente non venne costituito un gruppo di persone delegate al solo sviluppo dei nuovi prodotti, così che la partecipazione ai team di sviluppo fosse aperta a tutti e in questo senso molto meritocratica e stimolante.

Tutti noi, per motivi personali o fisici o altro, potremmo non essere sempre in grado di affrontare le sfide dello sviluppo di un nuovo prodotto, e per questo penso che possa essere conveniente optare per un lavoro a rotazione. A volte si ha infatti bisogno di poter stare nelle “retrovie” per riuscire a rigenerarsi, in quanto la “sfida continua” rischia di logorare.

Una volta terminata la fase di sviluppo, il ritorno delle persone che componevano i team di sviluppo all’evasione degli ordini permise una migliore comprensione del reale comportamento dei prodotti, e nel contempo di portare all’interno del processo di evasione ordine di macchine spesso personalizzate ulteriori competenze acquisite nel corso dello sviluppo dei nuovi prodotti.

Per rendere più efficiente e sostenibile il lavoro, dividemmo i team cross-funzionali di sviluppo in Core e Shell.

• Un “Core Team” composto da persone impegnate a tempo pieno.
• Uno “Shell Team” composto da persone impegnate a tempo parziale secondo ben definite regole di ingaggio.

Le persone di entrambi i team devono lavorare insieme quando è necessario, partecipando agli incontri di ogni iterazione (Sprint).

Parallelamente al ruolo “interno” del PO era necessario introdurre il ruolo di Scrum Master, inizialmente rivestito dalla consulente Daniela Rinaldi. È stato necessario attendere il 2019 per assumere Giovanni Melis come Senior Scrum Master. Daniela e Giovanni hanno poi fatto emergere altre figure di Scrum Master, in questo caso part time, che hanno reso sostenibile tale nuova modalità di sviluppo. Con l’arrivo di Daniela prima e di Giovanni poi iniziammo a ridurre la presenza della consulenza, fino a procedere completamente in autonomia con Giovanni.

Nella prima fase ci concentrammo sulla progettazione (Agile for Design), perché si riteneva che questa attività fosse l’anello debole dell’intero processo, ma ben presto ci accorgemmo che la progettazione rappresentava solo una parte del problema. 

I risultati ottenuti erano soddisfacenti per la progettazione, ma i tempi complessivi di sviluppo risentivano della costruzione e dell’approvvigionamento, eseguiti con le stesse modalità di evasione delle commesse.

La questione stava proprio nello sviluppo fisico del prodotto, e per questo convinsi la direzione a predisporre un reparto dedicato – una sorta di mini-fabbrica completamente agile – con un acquisitore dedicato e dei pianificatori dedicati a gestire direttamente i materiali. Nel 2019 tale nuova modalità di lavoro divenne operativa, e questa cosa si rivelò vincente perché i tempi vennero ulteriormente ridotti. L’aspetto più rilevante era la possibilità di avere uno staff di tecnici del montaggio e collaudo maggiormente coinvolti nel progetto. Questo migliorò la qualità dell’industrializzazione, abilitando di fatto il Design for X.

La Fabbrica Agile attinge a quanto la tecnologia rende oggi disponibile, come le stampanti 3D o le modalità di costruzione accelerate permesse da fornitori specifici; attinge inoltre a una virtualizzazione (si pensi ai Gemelli Digitali) che permette di posporre la costruzione fisica rendendo possibile un maggiore sviluppo iterativo.

La Digital Transformation è stata spinta dalle esigenze della Fabbrica Agile e ha avuto un impatto positivo sulla gestione Web di pianificazione dei lavori, produzione e distribuzione dei documenti di progetto, portando allo sviluppo di un PLM leggero che ha permesso la diffusa consultazione di documenti e disegni 3D.

Il tutto è stato inoltre abilitato dall’Architettura Modulare adottata per tutti i nuovi prodotti, che ha consentito in diversi casi di sviluppare separatamente specifici moduli delle macchine, o lo sviluppo di soluzioni tecniche trasversali e innovative che abbiamo denominato “Mattoni Tecnologici”.

La Fabbrica Agile ha portato a un cambio di paradigma sul significato di prototipo. 

Finché si resta in ufficio si è portati a pensare al prodotto più vicino a quello definitivo e si tende a concentrare le verifiche delle assunzioni progettuali nel momento della disponibilità del prototipo.

La Fabbrica Agile ha condotto inoltre a un approccio rivoluzionario per quanto riguarda la validazione delle soluzioni progettuali. I progettisti, vista la velocità elevata di costruzione dei componenti consentita, sono spinti naturalmente a validare al più presto le soluzioni elaborate costruendo dei veri e propri antesignani del prototipo, ovvero dei “Pretotipi”. 

Ricordo in particolare il caso dello sviluppo di una testa di levigatura e lucidatura del granito: durante la progettazione con il CAD 3D – accompagnata da verifiche strutturali agli elementi finiti – ci rimase il dubbio sulla montabilità di alcune soluzioni e sull’effettiva possibilità di passaggio di cavi e tubi flessibili. Queste verifiche potevano essere solo sperimentali. I due principali elementi erano realizzati con fusioni in lega leggera in conchiglia. La costruzione degli stampi e la prima campionatura avrebbero richiesto circa quattro mesi. 

Il team insieme al PO decise di sviluppare la cassa in lega leggera con Additive Manufacturing (mediante apposita stampante 3D si produce lo stampo all’interno del quale si fonde la lega). In un mese fu possibile ottenere i due componenti fusi e lavorati, pronti per le verifiche di montaggio. La cosa si rivelò provvidenziale, poiché le verifiche di montaggio evidenziarono la necessità di modificare le geometrie dei componenti fusi. I disegni furono così modificati in tempo affinché l’ordine di costruzione dello stampo non subisse ritardi e rifacimenti. Il costo del prototipo in stampe 3D fu pari a circa 18 volte il costo del componente fuso in conchiglia, ma permise che cinque mesi dopo la macchina con più di 20 mandrini potesse essere completata senza errori. Sicuramente l’extra-costo venne largamente compensato dal netto anticipo nel rilascio del prodotto.

L’aspetto rivelatosi in assoluto più significativo penso sia l’Outcome, ovvero il risultato ottenuto sulle persone e l’organizzazione.

Mi sto riferendo agli aspetti umani del cambiamento e dell’impatto che l’applicazione della Fabbrica Agile ha avuto sulle persone interessate.

Grazie al lavoro nei team cross-funzionali le persone coinvolte hanno acquisito nuove competenze, non solo tecniche ma anche relazionali. Questo ha portato a un maggior riconoscimento reciproco di ruoli e funzioni.

Le persone sono davvero al centro del processo di sviluppo, e questo è testimoniato da diversi casi nei quali ho potuto verificare il primo principio del Manifesto Agile: persone e interazioni più di processi e strumenti.

La loro intraprendenza ha fatto e fa la differenza, e vedere team che agiscono da soli dà una grandissima soddisfazione.

Ci sarebbero tanti episodi citabili, fra i quali mi piace ricordare un caso relativo allo sviluppo di una macchina che in fase di collaudo rompeva il prodotto che doveva processare. Il fatto avviene di mattina e, insieme con il team, identifichiamo la possibile causa e decidiamo cosa fare. Un operaio del team ricorda che in magazzino, ricoperto dalla polvere, c’è un materiale particolare in lastre dal quale sarebbe possibile ricavare i pezzi che ci servono. Un progettista disegna su carta quadrettata i profili dei pezzi da tagliare, e un altro operaio si candida per tagliarli su una macchina a taglio con acqua in pressione la sera stessa. Lo stesso operaio la mattina seguente, con gli altri colleghi del primo turno, pulisce tutti i pezzi dai residui del taglio ad acqua e li porta alla macchina. Insieme tutto il team installa questi nuovi componenti e mette la macchina nelle condizioni di ripartire. Entro mezzogiorno la macchina parte, e questa volta il processo è perfetto.

Il tutto è avvenuto per decisione del team, e senza alcuna pressione da parte di noi dirigenti presenti. Anzi, l’unica cosa che abbiamo fatto è stata chiamare il nostro collega che gestiva il reparto con la macchina necessaria, chiedendogli di renderla immediatamente disponibile. 

È veramente emozionante vedere accadere queste cose, e ti fa capire fin dove possano arrivare le persone quando si sentono motivate. L’approccio agile favorisce a tutti gli effetti l’auto-organizzazione delle persone nei team cross-funzionali.

Importantissima anche la raccolta dei feedback attraverso le Retrospettive: veri momenti di riflessione che hanno consentito di apportare miglioramenti nelle modalità di lavoro. Gli Scrum Master hanno svolto un ruolo delicato e fondamentale guidando questi incontri ristretti al solo team di sviluppo, riportandone a me una sintesi e mantenendo sempre la necessaria riservatezza su quanto le persone dicevano.

La transizione agile non è stata una passeggiata: abbiamo dovuto affrontare diverse difficoltà.

Per questo specifico argomento il mio maggiore impegno personale è stato dedicato a  convincere e a motivare i capigruppo di progettazione (il Middle Management) che, in questa nuova organizzazione, si trovavano di fronte alla richiesta di fare un passo indietro. Chiedevo loro di selezionare i loro migliori collaboratori, per farli partecipare ai progetti di sviluppo guidati dai PO, e di entrare in un ruolo molto più vicino al mio: di mentore, di consigliere in supporto ai team.

A ogni Sprint Review i capigruppo sono al mio fianco e a fianco della direzione aziendale nel valutare le soluzioni sviluppate. Al contempo sono i clienti interni dei prodotti che poi dovranno gestire all’interno delle commesse cliente.

È umanamente comprensibile, mettendosi nei loro panni, che non sia stato facile interiorizzare che il passaggio da un ruolo meno da giocatori e più da allenatori avrebbe potuto dare altrettante soddisfazioni. 

Ben presto scoprirono che tale ruolo consentiva di attuare fortissime innovazioni, attraverso le iniziative prese dalle persone dei team, e che in molti casi loro stessi nel precedente ruolo non le avrebbero attuate in prima persona perché troppo rischiose per la loro reputazione. 

In questo modo giovani collaboratori molto brillanti potevano fare proposte estremamente innovative e prendersi dei rischi che i “capigruppo” non avrebbero facilmente preso. 

E questo consentiva un fiorire di idee senza precedenti.

Altrettanto importante si è rivelata la risposta delle persone coinvolte nei team agili una volta riportata nelle commesse clienti, proprio per favorire la diffusione della conoscenza che altrimenti resterebbe elitaria. 

Ebbene, questo ha generato l’aspirazione da parte di altre persone a partecipare a tali team di sviluppo, per quanto più competitivi e impegnativi, perché spesso i prodotti rappresentavano i capostipiti di nuove famiglie di prodotti.

C’è stata la possibilità, per moltissimi di loro, di farsi conoscere dalla direzione che prima conosceva principalmente i “capigruppo”, e questo ha fatto sì che anche i più giovani diventassero  protagonisti, all’interno di team dove le forti sfide richiedono la cooperazione intergenerazionale.

Le persone sono davvero al centro del processo di sviluppo. Questo è testimoniato da diversi casi in cui ho potuto verificare in prima persona il primo principio del Manifesto Agile: persone e interazioni più di processi e strumenti.

La loro intraprendenza ha fatto e fa la differenza, e vedere team che agiscono da soli dà una grandissima soddisfazione. Al termine del progetto, le persone inserite all’interno del processo di evasione degli ordini cliente ben presto chiedono di tornare allo sviluppo di nuovi prodotti, a testimonianza del fatto che alle persone piace lavorare in modalità “agile”.