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

Dopo aver esplorato il contesto operativo del cliente nell’articolo precedente – un’azienda specializzata nell’installazione di antenne satellitari terrestri – ci siamo presto resi conto che la nostra analisi doveva andare oltre. Non bastava lavorare con i team tecnici: era necessario estendere la visibilità e la comprensione dei processi anche al livello dirigenziale.
Il top management, infatti, non aveva una visione chiara del quadro complessivo: non sapeva esattamente quali antenne fossero in fase di attivazione, quali ostacoli ci fossero in corso, o quali priorità fossero effettivamente in gioco.
Per colmare questo gap, abbiamo lavorato per connettere i flussi operativi con le logiche decisionali: da come nasceva l’esigenza di installare nuove antenne, fino alla pianificazione concreta delle attività.

Definire i criteri di priorità: impatto ed effort

Abbiamo quindi coinvolto i manager in sessioni strutturate per comprendere quali fossero i criteri che guidavano – o avrebbero dovuto guidare – la scelta delle aree geografiche su cui intervenire. L’obiettivo era esplicito: portare maggiore consapevolezza e trasparenza nei processi decisionali.
Per farlo, abbiamo introdotto la matrice impatto–effort. Ma con una particolarità: invece di valutare iniziative o progetti, abbiamo applicato la matrice alle aree geografiche.
Insieme ai mission manager, che sono un po’ gli stakeholder nel nostro caso, si andava a definire quali erano i driver di business, i driver di impatto che dovevano essere considerati; con i team, con gli operativi, abbiamo parlato dei driver di effort. Quindi definire come i team consideravano un’area geografica più rognosa da lavorare rispetto magari a una più semplice. In questo modo di procedere, c’è comunque un aspetto di agilità importante: come succede nella pianificazione dello Sprint in Scrum, a decidere dell’effort sono coloro che, in concreto, poi l’effort lo devono fare…

Uno spazio di conversazione condivisa

Oltre al valore analitico, la matrice ha avuto un impatto importante anche sul piano relazionale: ha favorito la creazione di uno spazio di dialogo tra stakeholder e team. Finalmente, le discussioni su dove installare le antenne e perché si sono svolte in modo strutturato e condiviso.
Inizialmente, abbiamo testato lo strumento sulle installazioni in corso, analizzando le decisioni già prese per verificarne la coerenza con i driver individuati. Dopo qualche aggiustamento, la matrice è diventata il punto di riferimento ufficiale per decidere il batch di installazioni del 2025.
Il cambiamento è stato netto: per la prima volta, ogni stakeholder coinvolto era in grado di rispondere alla domanda “Perché stiamo lavorando in quest’area e non in un’altra?”. La matrice era accessibile, visibile a tutti e ha reso il processo decisionale tracciabile e trasparente.

Miglioramento continuo

Man mano che l’esperienza si accumulava, anche la qualità della pianificazione migliorava. In un contesto così complesso, dove ogni antenna può richiedere attività ingegneristiche civili, permessi legali, contratti con fornitori di energia e di connettività, si è rivelato fondamentale avere una checklist ben definita prima di far partire ogni fase.
Abbiamo quindi introdotto una serie di “gate” operativi: controlli essenziali che dovevano essere soddisfatti prima di procedere con attività come l’inizio dei lavori civili. Questi gate sono stati mappati in Jira, rendendo immediata la visualizzazione delle dipendenze: se si pianificava qualcosa fuori sequenza, lo strumento lo rendeva evidente.
Questa struttura ha portato maggiore rigore nella gestione e ha aiutato i team a evitare errori potenzialmente molto costosi.

Dove siamo oggi

Attualmente l’organizzazione lavora pienamente sul batch di installazioni previsto per il 2025. Gli strumenti messi in piedi nei mesi scorsi sono attivamente utilizzati e le retrospettive mensili sono diventate un appuntamento consolidato. Noi come agile coach continuiamo a fornire supporto, ma il team ha ormai sviluppato una buona autonomia, come auspicato.
Un esempio? Quando ci si è trovati a dover scegliere tra due aree geografiche per una nuova installazione, il team – guidato dal Chief Product Officer – ha deciso di avviare un’esplorazione su quella con maggiore impatto potenziale, ma effort più alto. Dopo un mese, sulla base delle evidenze raccolte, hanno deciso di virare sull’alternativa. Un caso concreto di sperimentazione rapida e adattamento delle strategie in corso d’opera.

Adattare l’agilità al contesto, senza tradirne i principi

Come già evidenziato nella prima parte, lavorare in un contesto così specializzato ha messo alla prova molte convinzioni tipiche del mondo agile.
La cross-funzionalità, ad esempio, non è sempre praticabile: quando i ruoli richiedono competenze altamente verticali e non intercambiabili – come avviene tra chi costruisce rack elettronici, chi gestisce la parte legale o chi seleziona i siti – forzare la collaborazione orizzontale rischia di creare inefficienze.
Allo stesso modo, il limite al Work In Progress, principio cardine del metodo Kanban, non poteva essere applicato in modo rigido. Nel caso dell’azienda in questione, le attività richiedono spesso lunghi tempi di attesa, durante i quali sarebbe controproducente mantenere inattivi i team. Lavorare su più antenne in parallelo, per loro, non è una deviazione dai principi agili, ma una necessità operativa.
L’importante è saper distinguere tra i principi fondanti – come trasparenza, collaborazione, miglioramento continuo – e le pratiche specifiche, che vanno adattate al contesto.

Gli strumenti non fanno l’agilità. Ma possono aiutare.

Ripetiamo spesso che non sono gli strumenti a fare l’agilità, ed è vero. Ma è anche vero che uno strumento ben configurato, come nel nostro caso Jira, può rivelarsi un alleato prezioso per far emergere criticità, visualizzare dipendenze, rendere il lavoro più trasparente.
Perfino un diagramma di Gantt, se usato con consapevolezza e non come oracolo predittivo, può offrire valore. In un progetto in cui la logistica ha un peso determinante – come nel caso di spedizioni multimilionarie – strumenti tradizionali possono fornire un supporto utile alla pianificazione, a patto che non sostituiscano il pensiero critico.
L’agilità può ricorrere, con le dovute cautele, anche a strumenti che agili non sono, perlomeno per certi aspetti più predittivi dello sviluppo di un intero progetto… Ma quel che deve rimanere Agile è la mentalità, i valori e i principi. E rispondere al cambiamento è sicuramente uno tra i più importanti.