Un quadro più ampio

Dopo esserci resi conto delle peculiarità dell’azienda in cui operavamo, legate proprio alla specificità del loro business, cioà installare antenne satellitari a terra, abbiamo capito come fosse importante allargare il quadro che ci eravamo fatti.

Il passo successivo, infatti, è stato portare questo livello di conoscenza e di visualizzazione anche a un livello più alto, vale a dire quello del top management, perché in effetti loro non riuscivano a vedere e a sapere che cosa stesse succedendo complessivamente: quali erano le prossime antenne in attivazione o se c’erano eventuali impedimenti.

Quindi qui il lavoro è stato partire da quello che avevamo fatto all’interno del team e capire quali erano i processi a monte dell’operatività: da come nasce l’esigenza di installare delle nuove antennein certe arre a come creare il piano operativo per fare effettivamente le installazioni.

Quindi anche qui abbiamo fatto degli incontri con i manager, quindi con le persone un po’ più ad alto livello, per capire come oggi loro decidevano le aree erano più interessanti per il business e in quali dovevano andare a installare le prossime antenne. Anche qui abbiamo trovato una situazione inizialmente un po’ caotica, dove quasi letteralmente veniva detto che i manager non sapevano esattamente il perché si andasse a lavorare in una nazione invece che in un’altra. Non c’era questa conoscenza.

Driver per la prioritizzazione

Noi volevamo capire se c’erano dei driver chiari che guidavano la scelta delle aree in cui andare ad installare; pertanto, abbiamo iniziato a fare qualche esperimento con tecniche di priorizzazione.

In particolare abbiamo provato ad applicare la matrice impatto–effort sulle diverse aree geografiche. Quindi, se in un contesto “normale”, nella matrice impatto–effort puoi valutare dei progetti, delle iniziative, nel contesto di questa azienda si andavano a valutare 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…

Conversazione

Altro aspetto importante è che lo strumento matrice impact-effort, ha permesso finalmente di avere una conversazione all’interno del gruppo. Cioè, al tavolo ci sono stati gli stakeholder e gli operativi del team, a conversare, a discutere su quali erano effettivamente le antenne, le aree geografiche su cui era più interessante installare le antenne. Eccolo.

L’abbiamo prima fatto come esercizio sulle antenne, sulle aree geografiche che già stavano venendo installate, stavano venendo attivate, per provare i driver che avevamo portato alla decisione e vedere un po’ cosa usciva. Una volta fatto qualche aggiustamento, l’abbiamo poi usato per decidere il batch di antenne del nuovo anno, del 2025, ed è stato lo strumento ufficiale per prendere poi delle decisioni strategiche, decisioni di business, e finalmente queste strategie sono condivise e chiunque, stakeholder, manager, è in grado di rispondere alla domanda: “Perché si va in quest’area invece che che in un’altra?”. Perché questo strumento, questa matrice, è aperta, è condivisa da chiunque.

E quindi siamo partiti dal risultato della matrice, unito ad alcune simulazioni che hanno fatto i mission manager, e abbiamo trovato la configurazione di antenne e aree geografiche più interessante e su cui concentrarci per il 2025. E questo è stato sicuramente di grande aiuto e di grande valore per loro.

Miglioramento continuo

Diciamo anche che questo approccio ha subito un raffinamento grazie all’accumularsi di esperienza nel riscontare gli effetti derivanti dalle decisioni prese. Proprio per la natura molto complicata del loro lavoro, in alcuni momenti era importante essere sicuri di avere una checklist di cose da controllare per evitare poi di avere problemi in futuro.

Per esempio, nel caso di un nuovo sito da installare da zero dove c’è bisogno di fare dei lavori di ingegneria civile, come creare fisicamente la struttura che contenga poi il rack e l’antenna, devono essere sicuri che ci siano:

• i contratti legali firmati;
• la licenza attiva per fare i lavori civili;
• i contratti con gli operatori di fornitura dell’energia elettrica e di internet

Tutta una serie di cose che devono essere controllate per poter proseguire. Questo tipo di gate li aiuta tantissimo anche poi nella pianificazione, quindi loro sanno, hanno tutti i task per ognuna di queste cose, li mettono come dipendenza per, per esempio in questo caso, l’inizio dei lavori civili e a livello visuale sullo strumento di Jira è immediato se vengono pianificate delle attività che non rispettano quelle dipendenze. Quindi quello è stato un ulteriore passo che li ha aiutati nell’organizzazione del lavoro.

La strada fin qui

Oggi dove siamo? Ormai stanno lavorando al 100% sul batch del 2025, continuano a usare gli strumenti che abbiamo messo in piedi nei mesi scorsi e periodicamente facciamo ancora delle retrospettive, quindi tipicamente mensilmente facciamo ancora insieme delle retrospettive dove cerchiamo di portare avanti il processo di miglioramento continuo. Noi, come agile coach, diamo sempre il nostro supporto, ma abbiamo visto che i gruppi di lavoro hanno imparato a muoversi in autonomia, come deve essere.

Per esempio, loro hanno il Chief Product Officer, il CPO, che è la persona che prende in ultimo la decisione sulle aree in cui fare installazione. Chiaramente è una decisione comunque fatta insieme al team e agli stakeholder, quindi ci si è trovati al tavolo e si è condiviso poi quali erano le aree. Però ecco, c’è stato in particolar modo, anche per il nuovo batch, un caso di incertezza. Erano in ballo due aree geografiche: una era più interessante per certi aspetti e l’altra per altri. La strategia del team è stata: iniziamo a lavorare per l’area più interessante dal punto di vista business ma che aveva un effort elevatissimo e proviamo a vedere se si conferma l’effort elevato o meno. Un mese dopo hanno deciso di abbandonare quell’area geografica e di andare sulla seconda scelta. Quindi c’è stato anche un tentativo di andare in una direzione per poi cambiare.

Adattare l’Agile senza tradirlo

Lavorare in un’azienda come questa richiede anche la capacità di adattare la nostra mentalità Agile a certi aspetti di cultura aziendale che poi magari cozzano, anche in maniera stridente, con tutte le nostre conoscenze, i nostri strumenti, i nostri punti di riferimento.

Come scrivevamo nell’articolo precedente, è stato emblematico il primo incontro, quando ci hanno spiegato un po’ il contesto, e ci hanno detto che il team di infrastruttura era composto da cinque team, ma in tutto dieci persone: due persone a team. È stato in automatico nella mia testa dire: ma questi non sono cinque team, è un team solo. Poi, approfondendo meglio il contesto, ho capito che le competenze sono così diverse tra un team e l’altro che non è pensabile che uno aiuti a fare il lavoro di un altro. Uno che costruisce i rack non può aiutare il legale a fare i contratti e tutti i cavilli legali. Non ha competenze geologiche per trovare qual è il miglior sito. E quindi, almeno in questo caso, il concetto di cross-funzionalità andava messo da parte.

Stesso discorso per quel che riguarda un altro nostro mantra, che il più delle volte è giusto: ridurre il limite al Work In Progres, cioè le attività totali svolte in contemporanea. Noi raccontiamo a tutti che ridurre il WIP limit è il modo migliore per velocizzare il flusso, per far uscire le cose. Se si fa software o anche altri prodotti, è proprio così.

Ma In un contesto come quello della nostra azienda aerospaziale è un suicidio: non puoi finire di installare un’antenna per volta. È proprio una cosa che non ha senso. Vuol dire che le persone stanno l’80% del loro tempo a guardare in aria e ad aspettare risposte da altri.

Tutto questo ci ha insegnato che si devono adattare le nostre mentalità agili al contesto in cui si va ad operare. Gli strumenti possono anche cambiare, e anche certi processi. Non cambia, ad esempio, la pratica della trasparenza: quind far vedere le cose, condividerle, renderle disponibili a tutti. Non cambia il lavoro in cui team e business stanno a stretto contatto: collaborazione, scambio. E non cambia il miglioramento continuo: questa è una cosa che non facevano proprio e che noi abbiamo introdotto: confrontarsi sul loro modo di lavorare e prendere degli accordi per migliorare.

Gli strumenti non fanno l’agilità…

Ripetiamo sempre che gli strumenti non fanno l’agilità, ed è stato vero anche in questo contesto. Però va anche detto che uno strumento come Jira, che ho usato davvero in maniera intensa ed estensiva, ha aiutato le persone con cui lavoravamo a capire alcuni concetti e a riformare di conseguenza alcuni aspetti del loro processo di lavoro. Chiaramente, occore “guidare” il tool.

E, se per fare la cose bene, ti tornasse utile un Gantt, devi essere in grado di usare anche quello. Lo so che può sembra “blasfemo”, ma l’importante è non diventare schiavi del Gantt, pensando che possa davvero darci tutte le indicazioni. Però in certi casi potrebbe servire, limitatamente.

Per esempio: a volte partono dei container con tutto il materiale per l’installazione dell’antenna. Ogni “pezzo” vale circa mezzo milione di euro. Ecco, se il container arrivasse nella nazione di destinazione prima dell’arrivo del documento con il clearance, l’autorizzazione completa… in certi Stati fanno poche storie: prendono il container e lo distruggono prima che entri nel Paese. E quindi, magari limitatamente a questi aspetti, uno stumento di gestione di progetto più tradizionale si può tranquillamente usare… 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.