Rispondere al cambiamento: un caso reale dal settore aerospaziale. Parte 1.

Uno dei principi del Manifesto Agile afferma: “Rispondere al cambiamento più che seguire un piano”. Mai come in un recente progetto di coaching Agile questo principio si è dimostrato cruciale. L’approccio è stato, appunto, quello di adattarsi ovviamente senza venir meno ai principi dell’agilità. E, paradossalmente, questo ha significato in certi casi dover rinunciare ad alcune pratiche ormai cristallizzate nelle metodologie agili.

[Ndr: l’articolo è stato tratto dall’originale pubblicato sul blog di Mokabyte scritto da Stefano Marello]

Il contesto: industria aerospaziale e complessità operativa

L’azienda oggetto della nostra consulenza lavora nel settore aerospaziale, e più precisamente si occupa del ground segment: installa grandi antenne paraboliche per le comunicazioni terra-satellite. È un’attività che richiede un mix di competenze tecniche molto verticali, ma anche operative, organizzative e logistiche.

Queste antenne, con un diametro di 4,5 metri, vengono installate in tutto il mondo — ad eccezione delle nazioni apertamente ostili alla NATO. Questo comporta una varietà di sfide, sia culturali che burocratiche, che influiscono direttamente sulla gestione dei progetti.

Un dettaglio cruciale: i materiali viaggiano in container di alto valore, e devono superare controlli doganali molto rigidi. La documentazione deve essere perfetta e completa all’arrivo del container. In caso contrario, non si procede a un semplice respingimento: il contenuto può essere addirittura distrutto. È facile intuire quanto sia delicata la gestione logistica in un simile contesto.

Visualizzare per comprendere

Il nostro intervento è iniziato con il team di infrastruttura, ovvero il gruppo che si occupa concretamente dell’installazione delle antenne. La prima criticità rilevata era la mancanza di visibilità sullo stato delle attività.

Il team comunicava, sì, ma lo faceva in modo frammentato: messaggi in chat, scambi verbali informali. Mettevano in circolo informazioni, ma non le consolidavano in una rappresentazione condivisa. Il risultato? Una gestione quotidiana reattiva e caotica.

Abbiamo quindi lavorato con loro per creare una rappresentazione visuale dello stato dei lavori: qualcosa che permettesse a tutti di avere una visione d’insieme, sapere cosa stesse accadendo e allinearsi facilmente.

Team crossfunzionali? Non sempre

Nel mondo agile, i team crossfunzionali sono spesso considerati lo standard. Ma in questo progetto ci siamo confrontati con una realtà diversa, che ha messo in discussione alcune certezze consolidate.

Il team infrastruttura era composto da circa dieci persone, suddivise in coppie altamente specializzate. A prima vista, questa configurazione sembrava in contrasto con l’approccio crossfunzionale. Tuttavia, analizzando meglio il lavoro svolto, ci siamo resi conto che era una soluzione sensata.

Ogni coppia si occupava di una fase molto specifica:

• Alcuni cercavano il sito più adatto all’installazione, analizzando conformazione del terreno e bande di frequenza.
• Altri gestivano i rapporti con gli enti regolatori nazionali per le licenze, un compito di natura legale e amministrativa.
• Altri ancora realizzavano i rack elettronici per gestire connessioni e software.
  

In un contesto così specialistico, era irrealistico aspettarsi che un team fosse realmente crossfunzionale. L’approccio più sensato è stato mappare i flussi di lavoro, identificare le interdipendenze e i punti in cui le attività convergevano. Una sorta di value stream mapping che ha permesso di far emergere la struttura del lavoro in maniera più chiara e concreta.

Il limite al WIP non è un dogma

Una volta compresi i flussi operativi, abbiamo costruito una visualizzazione del processo attraverso una sorta di proto-Kanban. L’obiettivo era aiutare i team a capire quando un’attività poteva considerarsi conclusa e quando passava allo step successivo.

Durante questo lavoro è emersa una questione interessante: l’applicazione del principio del Work In Progress Limit, pilastro del metodo Kanban. In teoria, limitare il numero di attività in corso migliora il flusso e riduce l’accumulo. In pratica, però, non funzionava nel nostro caso.

Installare un’antenna può richiedere da 3 a 9 mesi, a seconda della complessità del contesto legale e geografico. Gran parte di questo tempo è occupato da attese: per documenti, risposte, permessi. Attese che rendono impossibile seguire una logica strettamente sequenziale.

Per questo motivo, i team lavorano su piccoli batch di antenne, generalmente 5-6 per volta. Le attività si svolgono in parallelo per sfruttare al meglio i tempi morti e le attese inevitabili. La fase di installazione fisica, invece, segue un ordine più lineare e prioritario: si inizia con le antenne più “semplici” da attivare, per poi passare a quelle più complesse.

Lo strumento giusto per lo scopo giusto

Anche la scelta degli strumenti ha richiesto flessibilità. All’inizio abbiamo utilizzato lavagne collaborative online come Miro. Successivamente, abbiamo configurato Jira per offrire una visione più strutturata delle attività. Questo ha portato, un po’ per volta, alla creazione di una sorta di Gantt.

Sì, proprio un diagramma di Gantt. Lo strumento che, da agilisti, spesso guardiamo con sospetto.

Ma qui è importante distinguere tra principio e pratica: se uno strumento, anche non canonico, aiuta il team a coordinarsi meglio, a visualizzare il lavoro e a prendere decisioni più consapevoli, allora ben venga. Non è lo strumento a fare l’agilità, ma l’intenzione con cui lo si usa.

Il Gantt, in questo caso, è diventato un information radiator efficace: ha permesso al team di organizzare incontri settimanali più focalizzati, tenere traccia delle tempistiche doganali critiche, e avere una mappa condivisa dell’avanzamento dei lavori. Dopo quasi un anno, è ancora lo strumento di riferimento per il team, a riprova della sua utilità concreta.

Rispondere al cambiamento: verso una visione più ampia

Il passo successivo è stato portare questo livello di trasparenza anche al top management. I dirigenti, infatti, avevano difficoltà a comprendere lo stato complessivo dei lavori: quali antenne fossero in fase di attivazione, quali bloccate, quali prioritarie.

Abbiamo quindi lavorato per estendere la visualizzazione a monte del processo, rendendo visibile anche al livello decisionale ciò che stava accadendo sul campo.

Ma questa è un’altra storia… che racconteremo nella seconda parte.