Project Management – Panta Rei

Transizione da Waterfall ad Agile

Agile-da-Waterfall

Da dove veniamo?

Addio diagramma di Gantt – foglia di fico di molti sedicenti Project Manager. Un tempo, chi sapeva adoperare qualche funzione di MS Project si considerava un “Deus ex Machina”, e si proclamava Project Manager, appendendo un bel diagramma di Gantt nel suo ufficio. In poco tempo, quel diagramma perdeva ogni legame con la realtà e il sedicente Project Manager veniva stritolato dagli stakeholder che non sapevano di quel bel Gantt e che neanche avrebbero saputo leggere. Il malcapitato Project Manager accantonava il diagramma di Gantt e navigava a vista, gestendo problemi e richieste di modifiche scellerate, sperando di cavarsela.

Quanti fanno ancora così?  Spero non molti.

Negli ultimi anni, sono stati diffusi parecchi buoni principi di project management (penso a quanti hanno scaricato la metodologia TenStep). Molti hanno compreso che la conoscenza di un tool non è sufficiente per nominarsi “Project Manager”. Bisogna possedere l’arte di far accadere le cose.

Ultimamente, l’approccio “Waterfall” – sempre valido per progetti complessi – deve gradualmente fare spazio all’approccio “Agile” che si sta imponendo a partire dalla pubblicazione del famoso Manifesto Agile da parte di un gruppo di visionari nel 2001. Nella fase di transizione, non occorre scegliere tra “Waterfall” e “Agile”, ma piuttosto bisogna saper convivere con entrambe le metodologie. La transizione non è un fenomeno spontaneo; anzi  le persone resisterebbero al cambiamento:  le persone che si lamentano della mancanza di novità, appena gli viene chiesto di modificare una propria abitudine,  si trincerano dietro le consuetudini.

Tutto scorre (Panta Rei)

La verità è che tutto evolve (anche in fretta) e la gestione dei progetti non fa eccezione.

Il paradigma del lavoro è cambiato. Oggi, manager e quadri devono collaborare con l’alto management per perseguire le strategie di business. Si dà per scontato che qualcuno sappia svolgere il lavoro tecnico, mentre, bisogna utilizzare più metodologie, combinando l’approccio  tradizionale Waterfall con quello Agile. La non comprensione di questa esigenza pratica produrrà grosse delusioni a molti professionisti e imprenditori poco strutturati.

La transizione richiede la conoscenza del presente e le idee chiare sul futuro. Se non conosci bene il presente, come fai a parlare di cambiamenti per il futuro?

I primi ad avere le idee chiare devono essere i Manager per comprendere cosa chiedere alle persone per adottare l’approccio “Agile”.  Come con MS Project negli anni ’90, oggi, qualcuno crede che adottando SCRUM il problema è risolto. Sbagliato! SCRUM è uno dei tool più potenti nel panorama Agile, ma senza la giusta filosofia e strategia di cambiamento non si va da nessuna parte.

Anche se può apparire semplice l’approccio Agile, la fase di transizione da Waterfall a Agile nasconde un sacco di insidie. Le tecniche ed i ruoli che impone Agile sono molto intuitivi, ma senza regole per il cambiamento culturale, si possono generare molte frustrazioni.

Quando termina un progetto con l’approccio “Agile”? Chi decide quando il prodotto è accettabile? Cosa accade se finiscono i fondi? Quali funzionalità deve garantire il prodotto? Chi è il Project Manager? Che significa lavorare in team?

Un team Agile non può avere nessuno di questi dubbi. Ci deve essere la massima fiducia tra sviluppatori e utente; i requisiti di prodotto, forniti gradualmente, non possono essere infiniti; le funzionalità saranno il frutto della collaborazione e non della contrapposizione tra cliente  fornitore.

A questo punto invito a leggere i principi del Manifesto Agile, per non essere frainteso.

AgileManifesto

Waterfall vs Agile

Uno dei principali problemi che sorge  nella fase di transizione è il linguaggio nella comunicazione tra progetti tradizionali e progetti Agile.

In un progetto tradizionale si raccolgono tutti i requisiti di prodotto e di progetto all’inizio, si analizzano, si disegna il prodotto e si chiede l’approvazione dell’utente. Da questo punto parte la realizzazione (factory) del prodotto in laboratorio. In ultima analisi, si rivede l’utente solo in occasione dei collaudi finali. Se qualcosa non era chiaro, intervengono le modifiche a volte necessarie, a volte pretese dall’utente per nuove idee o nuove esigenze di legge. Il Project Manager – responsabile al 100% degli obiettivi del progetto – analizza tutte le richieste di modifiche e richiede l’approvazione dello Sponsor di progetto, specie se comportano cambiamenti di tempi e di budget. Le richieste di modifiche, inevitabili, di solito, comportano una modifica al prodotto e una distrazione di risorse per il progetto.

In un progetto con l’approccio Agile, i requisiti vengono espressi gradualmente dall’utente, in occasione delle dimostrazioni dell’evoluzione del prototipo iniziale del prodotto. Gli sviluppatori lo arricchiscono con i suggerimenti dell’utente di ciclo in ciclo (sprint).  Il vantaggio è che l’utente non deve fare uno sforo iniziale per definire tutto ciò che gli potrà servire a fine progetto, ma può ragionare in collaborazione con gli sviluppatori che valuteranno di ciclo in ciclo cosa è più opportuno realizzare per soddisfare le esigenze dell’utente, ma anche per mantenere l’equilibrio del progetto. Questo esercizio continua fino all’esaurimento del budget o del tempo disponibile. A quel punto le parti di comune accordo decideranno di rilasciare l’ultima versione del prodotto realizzato con buona pace di tutti.

Chi è abituato ai classici capitolati di appalti farà molta fatica ad entrare in questa ottica di accettare ciò che è stato realizzato ad un certo punto del progetto. Ossia qualcosa di non definito a priori. In più, non c’è un vero e proprio responsabile di progetto, ma la cooperazione di più ruoli: il Product Owner in rappresentanza degli utenti; il Team di Sviluppo; lo SCRUM Master a tutela dei processi.

In realtà, nei progetti tradizionali accade di peggio. Più requisiti sono stati raccolti in un progetto tradizionale e più particolari vengono disegnati e pianificati all’inizio del progetto. L’utente è costretto a richiedere tutto prima, anche le funzioni secondarie. La factory, ossia il team di progetto, realizza sequenzialmente tutte le funzioni pianificate, senza distinzione tra principali e secondarie. Solo se finisce il budget o il tempo, l’utente viene invitato a decidere a cosa rinunciare, altrimenti ne nasce un contenzioso.

Scenari possibili

Con l’approccio Agile, l’utente viene coinvolto nel miglioramento del prototipo di base e sicuramente darà  priorità alle funzioni principali, relegando a fine progetto quelle funzioni di cui potrebbe anche fare a meno. Infatti, con la regola di Pareto (80/20), l’utente è più che soddisfatto del prodotto e ha realizzato l’80% dei suoi desiderata. La parte mancante passa in secondo ordine, anzi è un’opportunità per decidere se effettivamente serve quel 20% di funzionalità secondarie e se ne può fare tranquillamente a meno.

Con l’approccio waterfall, quando finisce il budget o il tempo potrebbe mancare all’appello qualche funzione principale, schedulata nell’ultima fase. L’utente non potrà rinunciare a cuor leggero a quella funzione, pur sapendo che ne sono state realizzate altre di cui forse poteva farne a meno.

Questi due scenari richiedono tanta maturità da parte dei gruppi di lavoro. Addio alla fiscalità del Gantt che prevedeva tutto a inizio progetto, con difficoltà a riconoscerlo da parte dell’utente a fine progetto. Con l’approccio Agile tutti collaborano, dando il meglio, per contribuire al successo del piano strategico.

Non basta vincere le battaglie, bisogna vincere la guerra.

Conclusione

La transizione da Waterfall a Agile richiede il massimo impegno da parte dell’alto management nel sostenere le persone chiamate a passare da un approccio all’altro.

Occorre un cambio di mentalità, comprendendo il valore di business dei  progetti e non i tecnicismi per realizzare il prodotto. Si incontreranno molte resistenze al cambiamento. Bisogna governarle con equilibrio e trasparenza. Agile deve essere vista come una liberazione e non come un’altra metodologia che ci investe, mentre stavamo riposando. Tutto questo è Agile e anche molto di più!

promo

 Sconto del 30% fino al 31/12/2016, più IVA

Agile PMI-ACP Online – € 210,00 anziché € 300,00 
PMI PMP-Prep Online
– €280,00 anziché € 350,00
PMI PBA-Prep Online
– €350,00 anziché € 500,00 

Una Certificazione PMP è per sempre!

Una Certificazione PMP è per sempre!

Fidati di TenStep!