Di cosa ti occupi al momento e quali sono i tuoi obiettivi principali?
Sono amministratore della società unipersonale Oraone. Sono senior consultant, project manager e formatore. Sono ingegnere informatico e questo mi ha permesso di sviluppare tutti questi mestieri.
Come sei venuto a conoscenza del metodo AgilePM? Qual era il tuo bisogno iniziale?
Volevo ampliare le mie conoscenze in ambito Agile relativamente al Project Management. Avevo già iniziato a studiare e ad applicare le Best Practice di Project Management, prima con PMP e poi con PRINCE2, in modo piuttosto tradizionale, ma volevo scoprire il mondo Agile e vedere quello che questi metodi e tecniche potevano darmi relativamente ai miei progetti. Ho seguito un corso di formazione PSD, ma sono rimasto abbastanza deluso per quanto riguarda l’aspetto di Project Management, in particolare relativamente alla governance. Allora ho seguito un corso di formazione AgilePM, basato sul framework DSDM, dove ho potuto ritrovare l’aspetto rigoroso del metodo PRINCE2 unito alle specificità di una gestione di progetto Agile.
Dopo la formazione, hai utilizzato il metodo AgilePM nella gestione di progetti?
Sì, assolutamente! Posso citare l’esempio del mio primo progetto con AgilePM, che resta sempre attuale. Si tratta di un progetto di media portata, nel settore dell’aeronautica e che perdura nel tempo.
Il progetto era stato avviato utilizzando il metodo PRINCE2, che si prestava particolarmente bene ai bisogni e alle esigenze del momento. Tuttavia, abbiamo riscontrato diversi problemi lungo tutta la lavorazione del progetto che riguardavano sia l’interconnessione con il reparto IT che dei problemi di performance, sicurezza, …. . Per porvi rimedio, il gruppo informatico del mio cliente si è formato seguendo la metodologia AgilePM, che ci ha permesso di migliorare la collaborazione tra i diversi servizi e di definire nuovi ruoli, necessari per sviluppare al meglio il progetto. Un Business Analyst del reparto IT, per esempio, è stato inserito nella business unit aviation. Da quel momento, tutto si è semplificato, sia il lavoro che la collaborazione e l’integrazione tra il reparto IT e gli altri.
Una volta che il primo prodotto è stato consegnato, ci sono stati aggiornamenti ogni anno. Da qui l’utilità di passare in modalità Agile per gestire il seguito del progetto, poiché l’agilità è estremamente funzionale nell’aggiornare prodotti e servizi esistenti con il principio di miglioramento continuo. Tuttavia, attenzione: Agile non significa non avere nessun controllo, e questo è il punto di forza del metodo AgilePM. In effetti, il metodo ci ha permesso, sia a me, consulente/fornitore esterno, che al servizio informatico e alla business unit, di mantenere una documentazione rigorosa, di mettere in atto un processo di monitoraggio efficace e di non perdere tutto il rigore messo in atto sulla prima versione del prodotto. Abbiamo anche approfittato delle riunioni regolari richieste dal metodo Agile, che ci hanno permesso di lavorare meglio insieme, in gruppo.
Quali erano i limiti e le sfide?
Da una parte, c’era la sfida di migliorare le relazioni di lavoro con il servizio informatico, per fare in modo tale che l’integrazione e gli aggiornamenti di prodotto funzionassero al meglio. La formazione AgilePM del team ha permesso di portare una visione e dei valori comuni fondamentali, di facilitare le relazioni, di creare un collegamento tra i diversi servizi e business unit e di accelerare e rendere più fluido il progetto.
Dall’altro lato, AgilePM ha facilitato il fatto di passare ad un miglioramento continuo, che richiede di lavorare su un backlog di possibili miglioramenti, quindi ad una lista di requisiti prioritari. AgilePM è il metodo ideale per fare questa tipologia di attività, poiché include un insieme di tecniche Agile quali la prioritizzazione MoSCoW e Timeboxing. All’inizio di ogni versione, potevamo prendere questo backlog e prevedere cosa avremmo fatto sul prossimo incremento.
Infine, poiché si lavora sul miglioramento continuo, l’Agilità è diventata pressoché una necessità, dato che si adatta perfettamente ai bisogni. Il framework Scrum avrebbe potuto funzionare per questo progetto ma non permetteva il rigore imposto da AgilePM. In più, in Scrum ci sono 3 ruoli mentre AgilePM ne conta una dozzina. Questo ci ha permesso di posizionare anche dei ruoli che sarebbero esterni al reparto IT come i ruoli di fornitori, clienti e business.
La declinazione di questi diversi ruoli si nota molto bene dal momento in cui si inizia a lavorare ad un progetto. Se ci si limita a fare attività di sviluppo su dei prodotti già esistenti con dei piccoli backlog di prodotto da correggere, allora si può benissimo lavorare con Scrum, ma per la gestione di un progetto complesso, io sostengo che sia meglio utilizzare il metodo AgilePM, che permette l’interazione di ruoli diversi, di sapere chi sta facendo cosa e di interconnettersi. Se prendo il mio esempio, in qualità sia di fornitore che di sostegno in ambito Project Management, avevo bisogno di avere delle SPECs precise sulle esigenze e mantenere rigore nella gestione.
Com’è avvenuta l’implementazione del metodo?
L’implementazione è stata effettuata abbastanza facilmente poiché il team IT era stato formato e il team di business unit aveva già conoscenza del metodo (e ovviamente io potevo aiutarli). Abbiamo potuto iniziare fin da subito a definire in modo chiaro i ruoli, a scomporre l’elenco dei requisiti, a seguire i progressi in occasione delle riunioni periodiche di avanzamento, il tutto mantenendo aggiornata la documentazione predisposta.
Il Business Analyst ha avuto un ruolo chiave per il successo del progetto, rivelandosi disponibile a sostenere il progetto e facilitare la comprensione tra tutti i dipartimenti (IT e business).
Penso sia importante insistere su questo ruolo, che si ritrova in AgilePM e non sempre in altri metodi Agile. Premesso che c’era stata, inizialmente, qualche difficoltà di comunicazione tra l’IT interno e la business unit aviation (l’azienda era molto grande, il dipartimento IT doveva interagire con molte business unit, non soltanto con la parte di aviation), la scelta del Business Analyst è stata cruciale. Il Business Analyst in questione capiva molto bene le sfide delle varie parti interessate, tra cui le esigenze della BU avion in particolare di modernizzazione della loro documentazione (favorito dal fatto che era sul sito) e le esigenze/limiti/vincoli del servizio informatico.
Come ti ha aiutato la metodologia AgilePM? Quale elemento ti è stato più utile?
Alcuni elementi del metodo ci hanno aiutato: da una parte il rigore imposto da AgilePM per mantenere la qualità della documentazione, ma anche i valori fondamentali comuni a tutti che hanno facilitato la comunicazione e la collaborazione del team. A questo si aggiunge l’importanza dei ruoli, necessari alla suddivisione dei compiti e soprattutto delle responsabilità. Infine, e questo secondo me è l’elemento chiave del metodo, l’efficacia delle tecniche Agile “MoSCoW” e il “Time-boxing” su cui si appoggia AgilePM.
In effetti, AgilePM si basa sulla combinazione MoSCoW / Time-boxing, che si possono trovare o utilizzare anche al di fuori di AgilePM, ma almeno questo metodo ha il merito di definire in modo chiaro queste tecniche come essenziali. Senza la tecnica MoSCoW, i team non avrebbero potuto consegnare in tempo per la fine del Time-box. Queste tecniche permettono di definire la durata di un Time-box e di impegnarsi a consegnare i “MUST” allo scadere del tempo. Questo obbliga il cliente a strutturare i propri bisogni, a esplicitarli in termini di funzionalità classificate secondo priorità: “assolutamente necessarie” (vitali), “dovrebbero essere fatte” (essenziali), “potrebbero essere fatte” (ciliegina sulla torta) e “non saranno fatte adesso ma forse più tardi”.
Con AgilePM, la durata è fissa, mentre con i metodi tradizionali, si tende a posticipare la data di consegna quando il tempo manca. Pertanto, con AgilePM, il team consegna, forse un po’ meno alla volta, ma in tempo, gli elementi prioritari.
Hai riscontrato delle resistenze al cambiamento e alla trasformazione Agile?
Abbiamo affrontato una certa reticenza classica nei confronti di Agile, ovvero lo sponsor, che gioca un ruolo finanziario e dà il suo consenso al budget, spesso spera che tutte le priorità siano “MUST”. C’è quindi una certa resistenza a comprendere che potrebbe pagare per delle cose che “potrebbero” essere consegnate.
Nell’ambito del nostro progetto, per esempio, il responsabile della documentazione doveva proporre progetto e budget affinché fosse validato dalla direzione (lo sponsor). Si è scoperto che è estremamente difficile far comprendere e accettare un budget se non si è precedentemente fatto un processo di evangelizzazione sull’Agilità anche tra le sfere decisionali e non si è spiegato come funziona la mentalità di gestione di un progetto Agile.
Hai dei consigli per i professionisti del settore?
Ci si rende conto che un progetto come questo, se fosse stato realizzato con un metodo tradizionale impiegando 2 o 3 anni, alla fine non sarebbe risultato così efficace. In effetti, grazie all’agilità, questo progetto è stato effettuato nell’arco di 5 anni, in modo incrementale, accogliendo i feedback dei clienti dopo ogni versione. Questo ha portato a dei grandi cambiamenti strategici, a dei miglioramenti continui nella creazione di valore e ad una soluzione a volte lontana da quella inizialmente pensata, ma che alla fine corrisponde e risponde perfettamente al bisogno del cliente. Ciò non sarebbe necessariamente avvenuto seguendo un metodo di lavoro tradizionale.
