“Sicuramente possiamo dire che agile sta trasformando il mondo del project management e cambierà radicalmente il modo in cui business e IT lavorano insieme per affrontare con successo il cambiamento.”
Queste parole segnano l’inizio dell’indagine “Agile Project Delivery 2017 Survey”, e danno un’idea molto chiara dell’aumento di importanza di Agile nel mondo del Project Management.
Nonostante la differenza tra metodi di project management Waterfall e Agile sembri essere ben conosciuta nella comunità PM, è più difficile trovare una visione chiara e realistica di cosa “Agile” significhi veramente: il nostro obiettivo con questa intervista è quello di evidenziare come le aziende digitali utilizzino diversi framework, e come developer, project manager e team member lavorino insieme.
Abbiamo deciso di intervistare Pàu, una delle aziende digitali in rapida crescita in Belgio: il loro team è formato da diversi profili che vanno da conceptual UX a frontend/javascript developer a sviluppatori backend. Pàu ha recentemente realizzato progetti di successo per Telenet, BNP Paribas Fortis, Colruyt-Group, KBC, De Persgroep, Mediahuis, Essent, Proximus, Boondoggle e molti altri.
“Viviamo in un ambiente in continuo cambiamento dove il cliente ha richieste più ampie. Per poter soddisfare queste richieste, le organizzazioni sono costrette a rispondere molto velocemente ai nuovi sviluppi di mercato” (da KPMG “Agile Project Delivery 2017 Survey”)
Lo stesso vale per Pàu: come specificato chiaramente nel loro sito web www.pàu.be : “Invece di avere un solo metodo di lavoro, adottiamo elementi di ITIL, PRINCE2, AgilePM e SCRUM per applicare in maniera dinamica la metodologia che si adatta meglio ai bisogni di ogni specifico incarico”.
Per questo motivo abbiamo intervistato Kevin Pauwels, consulente sviluppatore, certificato AgilePM, Scrum Master in Pàu. Con lui abbiamo voluto approfondire i collegamenti tra Agile e un altro framework molto ben conosciuto, come Scrum, e abbiamo cercato di capire come questa conoscenza l’abbia aiutato nel corso del progetto.
Abbiamo discusso con Kevin del suo ruolo, del suo parere riguardo metodi come Agile e framework come Scrum, e delle sfide e successi di uno Scrum Master che sta diventando Project Manager.
I: Sei certificato Scrum e AgilePM. Ci puoi spiegare perché hai scelto Scrum in primo luogo?
K: «Scrum è ben conosciuto all’interno di organizzazioni che fanno sviluppo software e la maggior parte delle organizzazioni ha visto i benefici di avere piccoli team che lavorano fianco a fianco per realizzare progetti e rispettare scadenze. Utilizzano e conoscono SCRUM perché hanno visto i risultati da altre organizzazioni. Non penso ci sia una discussione in particolare se “Scrum o altri metodi” nel mondo dello sviluppo Software in questo momento, Scrum è semplicemente ben conosciuto nella comunità ed è visto come il cammino da seguire”».
I: Come mai hai scelto AgilePM?
K: «Perché ho scelto Agile dopo Scrum Master? Perché aspiro ad essere sempre meno una “risorsa tecnica” e ad essere sempre più una “people person”, quindi voglio spostarmi di più verso il ruolo del Project Manage, e non solo Scrum Master. Inoltre, cosa molto importante: Agile è un termine molto utilizzato al giorno d’oggi ma penso che la maggior parte delle persone non sappia cosa sia esattamente Agile. Ecco perché ho voluto capire da me cosa fosse Agile, e chi fosse l’Agile Project Manager. Rispetto a essere Scrum Master, vedo AgilePM come il passo successivo, come un modo di aggiornare il mio ruolo e le mie competenze, da un ruolo principalmente tecnico ad uno meno tecnico
I: Quali sono i benefici di entrambi
K: «Vedo due grandi benefici: i ruoli ben definiti, e la libertà che è data ai team in entrambi gli approcci. In Scrum per esempio, c’è un costante bisogno di migliorare il team nel suo insieme, e il modo in cui Scrum funziona, con un certo periodo di tempo a disposizione per gli sprint per esempio, e il modo di guardare a ciò che hai fatto dopo ogni sprint, ti rende in grado di migliorare ad ogni sprint, e migliori di volta in volta.
In Agile il più grande beneficio è che tutti concordano all’inizio alcune regole semplici, per esempio le tempistiche del progetto sono fisse. Quindi quando ci sono nuove features da aggiungere durante il progetto, tutti sanno che bisognerà abbandonare un’altra funzionalità. Non c’è discussione. Il vantaggio è vedere i miglioramenti già durante il progetto, e ogni volta che il business vuole rivedere ciò che hai fatto, puoi presentare loro qualcosa. È veramente importante nello sviluppo Software dimostrare che c’è un progresso costante.
Un terzo ulteriore beneficio è che imparando un nuovo metodo o framework, acquisisci così tanti strumenti da implementare nei tuoi progetti. Quindi penso sia importante scoprire e trovare nuovi strumenti da utilizzare, ma dopo sta a te adottarli ed adattarli al tuo ambiente.»
I: Quali sono state le più grandi sfide? Quali ostacoli hai incontrato?
K: «La più grande sfida che sto affrontando ora è quella di passare da Scrum a AgilePM, da un ruolo più tecnico ad uno più di Project Management. In questo momento sono responsabile del mio team all’interno di un progetto, ma aspiro a diventare responsabile per l’intero progetto. Vorrei essere in grado di avere un impatto sul modo di lavorare complessivo e non solo sul modo di lavorare del mio team.
Inoltre, molti sviluppatori parlano di agile come se “Puoi fare quello che vuoi, e questo è Agile”. Utilizzano il termine agile per diverse cose, solo perché agile è una parola inglese abusata e può essere veramente generica, ed è principalmente usato con l’accezione di “flessibile”. Penso che la maggior parte delle persone non conosca la metodologia e la teoria alla base di Agile ad esempio che le tempistiche sono invariabili. La mia sfida è quella di spiegare che agile non vuol dire fare tutto quello che vuoi, ma in realtà crea focalizzazione. Penso questa sia stata la parte più difficile dopo il corso, spiegare cosa Agile sia e cosa significhi veramente, non solo ai colleghi, ma anche ai manager e Product Owner.»
I: Di quali successi sei più orgoglioso?
K: «Il più grande successo è quello di essere arrivato in un team di 10 persone, dove c’erano già uno Scrum Master e un certo modo di lavorare, e, dopo il corso Agile, essere riuscito in poco tempo ad educarli su cosa voglia dire veramente lavorare in maniera agile, insegnare cosa vuol dire lavorare insieme e collaborare. Li ho indirizzati verso il raggiungimento di obiettivi a livello di squadra, e non individuale. Sono veramente orgoglioso perché non ci sono tanti team che lavorano con lo stesso spirito di appartenenza e voglia di cooperare e lavorare insieme. Nel mio team sappiamo che se qualcuno ha una domanda non è per dare più lavoro agli altri, ma per aiutarci l’un l’altro e condividere. Il modo in cui lavoriamo ora è un modo divertente di lavorare. E questo è il più grande successo.»
I: Come misuri il successo?
K: «Il modo più facile di valutare un successo è quello di vedere se hai avuto implementazioni di successo. Ma il miglior modo di valutare il successo, secondo me, è provare e vedere la crescita della mentalità del gruppo nel suo insieme. Si tratta di dinamiche di gruppo migliorate, noti che tutti sono più felici di venire al lavoro, le persone fanno più domande, si fidano di più e ci sono meno problemi all’interno dei team perché c’è comunicazione. É un successo quando vai via una settimana, e al tuo ritorno ogni cosa è state fatta nella maniera in cui doveva esser fatta. Io, in quanto Scrum Master, non ho nemmeno più bisogno di essere lì. Questo vuol dire che il team crede veramente nel suo metodo di lavoro. Nel modo di lavorare scrum o agile, misurare il successo significa parlare di gestione delle persone.
Un altro modo di misurare il successo è sicuramente quello di chiedere feedback al team.»
I: Quali sono le tue best practice? (Cose da fare e non fare)
K: «Sicuramente la più importante è: COINVOLGERE TUTTI. Cerca di ottenere qualcosa che tutti vogliono. Con ogni metodologia che userai, è facile dire “implementiamo tutto”, ma se il team non ti segue non avrai successo. Quindi ascolta e coinvolgi il tuo team. Dovrai adattare il metodo ai tuoi bisogni e a quelli dell’ambiente e del team.
STABILIRE OBIETTIVI CHIARI PER TUTTI: non solo “consegnare X entro Y” ma anche obiettivi riguardo la comunicazione, la cooperazione. L’obiettivo deve essere chiaro per tutti.
NON ESSERE SEMPRE TROPPO SERIO: le risorse in un team sono persone. Apprezzano le battute, si rendono conto se qualcosa non va bene, non dovrebbero sentirsi male se il progetto non funziona, non devono sentirsi frustrati, hai la responsabilità di stabilire e influenzare l’umore. Devi motivarli. Il team non dovrebbe mai sentirsi perdente, anche quando il progetto non sta andando perfettamente, dovrebbero essere felici di venire a lavoro.
NON CONSIDERARE AGILE O SCRUM COME UNA RELIGIONE. Sono strumenti, da adottare ed adattare. Non applicare quello che hai letto nella tua organizzazione, devi farlo funzionare per la tua azienda, le realtà non è uno “scenario perfetto”.»
I: Quali lezioni vorresti trasmettere ad altri?
K: «Quando prendi la certificazione tutti gli esempi che affronti cercano di seguire lo scenario perfetto. Nella realtà non sarai mai capace di avere uno scenario perfetto. Quindi cerca di rendere Agile adatto alla tua organizzazione.
CAMBIA UN PASSO ALLA VOLTA. Non puoi cambiare troppo in una sola volta, le persone sono molto sensibili sul modo di lavorare. Alla gente piace sapere che sta lavorando bene, non cambiare tutto nello stesso momento (a meno che non inizi qualcosa da zero in una nuova organizzazione, ma in quel caso non stai veramente cambiando, stai implementando). Non cercare lo scenario perfetto, ma lo scenario perfetto per la tua organizzazione.
E, FIDUCIA NEL TEAM. Lo Scrum master ha bisogno di credere ed aver fiducia nel team. Anche quando non hai un team particolarmente esperto, devi cercare di ottenere il miglior risultato possibile.
E per finire: NON SMETTERE MAI DI IMPARARE.»
