Rispondere al cambiamento

Uno dei principi del Manifesto Agile recita “Rispondere al cabiamento più che seguire un piano”. In un progetto nel quale sto fornendo coaching agile, mi sono trovato a dover adattare molte delle pratiche agili al peculiare contesto in cui ho operato. 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.

Vediamo di cosa si tratta e quali considerazioni se ne possono trarre.

Il contesto industriale

Partiamo dal descrivere l’ambito industriale in cui opera l’azienda alla quale abbiamo fornito consulenza e coaching agile. Si tratta di un’azienda del ramo aerospaziale, in particolare del cosiddetto ground segment. Cosa fanno, in pratica? Installano antenne paraboliche per le comunicazioni tra la superficie terrestre e i satelliti in orbita: un’attività che, come vedremo, comporta numerose azioni, anche molto diverse tra loro, e delle competenze tecniche e organizzative molto specifiche e verticali.

Per illustare ulteriormente il contesto, va ricordato che queste antenne — paraboliche di 4,5 m di diametro — vengono installate in gran parte del mondo. Eccezion fatta per i Paesi apertamente ostili al blocco NATO, poi tutto il resto del monto è “terreno” fertile per la collocazione di questi impianti.

Un altro aspetto da mettere in luce, che poi si rifletterà su alcune scelte adottate nella gestione di progetto, è il seguente: per l’impianto c’è bisogno di una collocazione geografica adeguata, della creazione di un rack e del montaggio dell’antenna vera e propria. Tutti i materiali necessari vengono spediti a destinazione dentro container e il valore di queste “spedizioni” è molto elevato: visto il tipo di materiale, quando il container arriva alla frontiera di ingresso, devono essere già pronti tutti i documenti che ne certifichino natura, provenienza, destinazione e quant’altro. In certi casi, se anche solo qualche dettaglio manca, non è che il container viene rispedito al mittente. Si procede direttamente alla distruzione del materiale “sospetto”… Si capisce bene quanto diventi delicato gestire anche questi aspetti nel processo di installazione.

Team e comunicazione

Il nostro impegno nell’azienda è iniziato proprio con il gruppo di lavoro dell’infrastruttura, ossia il team che si occupa fisicamente di andare a installare le antenne paraboliche. Abbiamo cercato subito di capire come erano organizzati e in che modo si scambiavano le informazioni. Qui abbiamo compreso come la prima necessità del team era vedere in maniera più chiara e completa che cosa effettivamente stava succedendo.

Loro si organizzavano molto tramite chiacchierate nei corridoi o messaggi di chat, quindi non è che non comunicassero o non volessero farlo. Però quello che mancava era una vera visualizzazione di quello che stava succedendo: le persone non erano aggiornate, non venivano coinvolte e quindi era tutto un po’ caotico e si viveva molto sull’urgenza, alla giornata. Pertanto, il nostro primo intervento è stato quello di farci raccontare queste cose e di trovare un modo che consentisse di visualizzare “lo stato delle cose” e di tenere tutti allineati e con uno sguardo d’insieme più chiaro.

Team crossfunzionali?

Spesso si sente parlare di uscire dalla comfort zone. E, in questo caso, le peculiari caratteristiche del prodotto e del processo ci hanno costretto a ripensare alcune delle nostre sicurezze più assodate.

Quando abbiamo approfondito la conoscenza del gruppo che si occupa dell’infrastruttura, abbiamo visto che si trattava di una decina di persone, ma che queste si suddividevano in 5 “miniteam” di 2 persone. A prima vista, questi sottogruppi ci sono parsi parecchio in contrasto con l’idea di team crossfunzionale che tanti anni di pratiche agili ci hanno permesso di apprezzare. Un team in cui le persone, pur con delle competenze verticali, hanno competenze più orizzontali e sono in grado di aiutarsi e di affiancare nel lavoro altri colleghi, quando necessario.

Però, a un’analisi più approfondita, ci siamo resi conto che, in un contesto come questo, l’idea del team crossfunzionale si adattava male. Infatti, installare un’antenna per le comunicazioni con i satelliti richiede un insieme di competenze talmente diverse e talmente specifiche che, in effetti, una suddivisione in “miniteam” di due persone, con competenze molto verticali, ha senso.

Infatti, nel gruppo infrastruttura ci sono

• coloro che si occupano solamente di cercare la posizione migliore, ossia il sito in cui installare l’antenna valutando la conformazione geomorfologica, lo spettro di frequenze e così via;
• coloro che si occupano dei contatti e delle pratiche con gli enti regolatori delle varie nazioni, per ottenere le licenze installazione e operazione, e devono avere competenze di tipo legale e amministrativo;
• coloro che costruiscono il rack da andare a installare sul sito per gestire poi i collegamenti e il software, e devono avere quindi competenze di elettronica.

Quindi il “mito” del team crossfunzionale in questo contesto specifico non funziona. Troppe competenze diverse richieste. È stata una presa d’atto che abbiamo fatto perché siamo andati dai diversi team, composti da un paio di persone, a farci raccontare nel dettaglio il loro lavoro.

Da quanto emerso in queste “interviste”, abbiamo in qualche modo cercato di fare una specie di value stream mapping, e di capire quali dipendenze i vari team hanno dagli altri team e quali sono i momenti in cui i lavori di tutti questi gruppetti convergono per unirsi.

Limiti al Work In Progress?

Il passo successivo, dopo aver capito il lavoro dei diversi miniteam, è stato realizzare una visualizzazione dei vari passaggi presenti nel flusso di lavoro: una sorta di “protoKanban” in cui era chiaro che un determinato step si considerava raggiunto nel momento in cui determinate condizioni si verificano o vengono soddisfatte.

Questo ci serviva anche a portare la visione a un grado più ampio: disegnare un po’ il processo ad alto livello. Perché ogni team fa queste cose qui, ha questo tipo di processo… ma cosa succede poi se un manager vuole vedere che cosa sta succedendo su tutto il team di Global Infrastructure?

Ci siamo focalizzati su quali cose avvengono sequenzialmente e quali in parallelo ed è in questo momento che è arrivata la presa di coscienza che, per il peculiare contesto in cui stavamo operando, uno dei principi cardine del Kanban classico doveva essere rimesso in discussione: il limite al Work In Progress.

Infatti, nel Kanban classico uno dei principi cardine è quello del WIP Limit: invece di fare mille cose in parallelo, limitare il lavoro svolto in contemporanea, fare una cosa per volta, iniziarle e concludere una cosa per volta. Ma nel nostro caso questo approccio semplicemente non poteva funzionare.

Perché? Perché l’installazione di un’antenna potrebbe richiedere dai 3 ai 9 mesi, a seconda se il team va a agire in un sito già conosciuto, dove è facile acquisire le licenze e installare, o se invece va in una nazione fino ad allora mai contattata, e quindi deve costruire tutto da zero. Il fatto è che questi 3-9 mesi sono in buona parte composti da tempi di attesa di risposte. Quando si ha a che fare con enti regolatori, a una mail inviata oggi, magari si riceve una risposta tra due settimane. E, con queste premesse, non si possono fare le le cose sequenzialmente, una dopo l’altra. Bisogna tenerne “aperte” diverse in contemporanea: magari non troppe, ma un certo numero sì.

E quindi loro lavorano a batch di antenne, con 5-6 antenne per batch e, tipicamente nel giro di un anno vanno a installare e poi ad attivare tutte quante le antenne. L’esecuzione dei vari lavori avviene quindi in parallelo, proprio perché ci sono tanti tempi morti, tanti tempi di attesa su spedizioni o gestione della parte legale o di licenza, che in questo caso consentono di lavorare in parallelo, mettendo da parte certi processi sequenziali che invece come agilisti diamo per assodati.

Discorso diverso invece è sull’installazione fisica e poi l’attivazione: essendoci un team che si occupa fisicamente di andare a installare e poi attivare l’antenna, lì c’è una certa sequenza. Per questo, spesso vengono prima fatte le antenne più “facili” per le quali non ci sono difficoltà particolari a livello legale e di autorizzazione, e poi ovviamente a seguire le altre.

Gli strumenti non fanno l’agilità

Anche l’uso degli strumenti per la visualizzazione dei processi ci ha riservato qualche “sorpresa” a cui non avremmo mai pensato, ma che abbiamo accettato volentieri con il giusto spirito di adattamento e la flessibilità necessaria a salvaguardare i principi Agile.

Inizialmente, il nostro strumento di visualizzazione è stato rappresentato da alcune lavagne virtuali, usando il Miro di turno. Successivamente, abbiamo puntato a implementare questo tipo di visualizzazione sullo strumento che loro stavano iniziando ad usare per organizzare le attività: Jira. Abbiamo fatto pertanto anche un lavoro di configurazione dello strumento di Jira per poter vedere una pianificazione, una sorta di roadmap. E alla fine ci siamo ritrovati anche con una specie di Gantt, delle attività previste e degli step previsti per le varie antenne. E questo è diventato nel giro di poco tempo il loro principale strumento di visualizzazione e discussione per l’avanzamento dei lavori.

Ma come il Gantt?

Capiamoci: da Agilisti, noi non vediamo di buon occhio il diagramma di Gantt. Sappiamo che l’idea delle tempistiche perfettamente stabilite con grande anticipo non ha di solito alcuna relazione con quanto accadrà poi veramente nella realtà. E programmare rigidamente l’andamento del progetto si scontra con tutto quello che abbiamo imparato e che sperimentiamo nel nostro lavoro con le aziende.

Però, da agilisti, dobbiamo anche avere un approccio pragmatico ispirato all’empirismo: se uno strumento mi aiuta realmente a fare meglio il mio lavoro, a seguire in maniera più compiuta il processo, a realizzare cicli di feedback significativi… allora posso tranquillamente usare quello strumento. Non è lo strumento che fa l’agilità, ma il principio con cui lo usi: non è che se usi Trello o Jira sei automaticamente agile, mentre se salta fuori un Gantt, allora l’Agilità non potrà mai affermarsi…

E quindi ci siamo resi conto che questo diagramma tipo Gantt diventava utile per il gruppo di lavoro: non perché consentisse di prevedere realmente in maniera esatta i tempi di consegna, ma perché permetteva alle persone di avere un information radiator davanti al quale fare i loro incontri settimanali, confrontarsi, discutere delle tempistiche e delle sequenzialità.

All’inizio dell’articolo parlavamo di come fosse cruciale che la documentazione richiesta arrivasse agli uffici doganali prima dell’entrata del container, a pena, in certi casi, della perdita dell’intera spedizione. Ecco, in questo senso, il diagramma poteva servire proprio a tener traccia di queste tempistiche e a capire a che punto fossero i vari elementi.

E ormai lo usano da quasi un anno e continuano a usarlo, quindi è qualcosa che gli è utile, gli serve veramente tanto. Perché tutte le persone coinvolte iniziavano a conoscere, a sapere quello che stava succedendo e hanno quindi avuto dei miglioramenti sensibili sulla loro organizzazione del lavoro.

Conclusioni

Il passo successivo è stato portare questo livello di conoscenza e di visualizzazione anche a un livello più alto, vale a dire quello del top management, perché anche il top management non aveva idea, non riusciva a vedere e a sapere che cosa stava 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à.

Ma di questo aspetto, anch’esso supportato da un particolare strumento, parleremo nella seconda parte.

Stefano Marello

Dopo più di dieci anni in cui ho svolto attività di sviluppatore software, ho conosciuto i principi e le pratiche Agile e ne sono rimasto affascinato. Ho quindi approfondito i temi della leadership e del coaching, e ho intrapreso un percorso per diventare Agile Coach.

Mi piace aiutare individui, team e organizzazioni a crescere cercando di massimizzare la fiducia e la collaborazione tra le persone.