Waterfall vs Agile: 20 anni dopo

L’eterna sfida tra approcci inconciliabili… oppure no?

È passato un ventennio dalla pubblicazione dell’Agile Manifesto.
Come è stato accolto negli anni dagli addetti ai lavori? La maggior parte di loro ha reagito con entusiasmo, apprezzando il cambio di prospettiva e i benefici derivanti; altri si sono semplicemente lasciati coinvolgere dalla nuova moda perché “è così che si deve fare”; qualcuno ha assunto posizioni negazioniste e reazionarie (“l’agile non funziona”); infine, c’è chi è diventato paladino dell’agile, spesso esasperando disapprovazione e rifiuto per chi segue approcci di gestione progettuale più convenzionali. A dire il vero c’è anche chi utilizza il termine agile senza sapere cosa significhi, mascherando in realtà un mancato governo dei progetti.

È indubbio che il modello waterfall, che funziona bene in settori come le costruzioni o l’industria manifatturiera, mostra invece qualche limite quando si confronta con il mondo complesso e intangibile dello sviluppo software: su tutti, l’aspetto chiave è la rigidità nell’accogliere i cambiamenti. Nei progetti con una forte connotazione innovativa od esplorativa, l’approccio agile è essenziale.
Ma questo vale in tutti i contesti? È sempre possibile applicare una metodologia agile?
La verità è che spesso è ancora difficile sviluppare un progetto seguendo una metodologia agile.

Alcune delle motivazioni possono essere:

• Clienti legati a metodi più tradizionali o con una struttura organizzativa che rende difficile l’adozione di una metodologia agile
• Preparazione insufficiente del team o del management (attenzione all’apparente semplicità delle metodologie agili!)
• Non negoziabilità dello scope

In questi scenari, dobbiamo pertanto rinunciare all’agilità?

Trovo che sia data ancora troppa enfasi all’antitesi waterfall-agile: è sufficiente una rapida ricerca su internet per rendersi conto di quanto il tema sia ancora dibattuto.
Personalmente concordo con chi ritiene che non ci sia una dicotomia, ma che esista un continuo di possibilità tra il waterfall e l’agile.
Innanzitutto, è bene ricordare che l’approccio tradizionale PMI/PMBOK non è assolutamente in contrasto con i principi dell’Agile Manifesto. Non lo è mai stato e nelle ultime edizioni del PMBOK è stato rimarcato con forza, dando spazio esplicito ai principi di agilità.
Il Project Management è un’arte, che si può padroneggiare solo con l’esperienza, in cui è possibile attingere ad un insieme di approcci, processi, tecniche e strumenti che sono stati raffinati in decenni di applicazione da parte di esperti del settore. E’È parte del lavoro del Project Manager selezionare quali di questi è opportuno utilizzare nello specifico progetto. Nel caso di aziende più strutturate, l’ufficio PMO dovrebbe avere un ruolo chiave nell’aiutare e supportare il Project Manager in quest’attività, fornendo consigli e linee guida.

È possibile rendere più agile un progetto waterfall, prendendo in prestito strumenti tipici delle metodologie agile. Per esempio:

• È possibile adottare un approccio iterativo. La pianificazione può essere dettagliata e raffinata per fasi successive. Il PMBOK parla storicamente di “rolling-wave planning”: definire una pianificazione a “grana grossa” sull’intero progetto e dettagliarla di volta in volta sulla iterazione di progetto in lavorazione.
• È buona pratica coinvolgere il team nella pianificazione, evitando l’approccio rigido di un PM che impone e controlla e aumentando il commitment e la responsabilità di tutti i partecipanti nel progetto.
• È opportuno organizzare dei brevi meeting giornalieri tra il team di sviluppo simili ai Daily Scrum: questo aumenta la coesione del team, accresce la consapevolezza del progetto e aiuta a identificare rischi e intercettare criticità. L’importanza di un contatto costante è ancora più significativa oggi: la diffusione del lavoro da casa ha ridotto sensibilmente le possibilità di lavoro in presenza, con crescente difficoltà di controllo, confronto e allineamento.
• Ormai tutti i progetti di sviluppo software nascono con un impianto DevOps ben strutturato: questo consente di avere sempre build pronte e sufficientemente testate da poter essere mostrate frequentemente al cliente, evitando il rischio di recepire feedback e richieste di modifica troppo tardi nel progetto, quando risorse come tempo e budget sono irrimediabilmente scarse.
• Nonostante non sia spesso identificabile un ruolo simile al Product Owner, è possibile organizzare il progetto in modo da coinvolgere maggiormente il cliente, così da ridurre ancora una volta i rischi derivanti da incomprensioni o change request dell’ultimo minuto.
• È possibile organizzare momenti formali di retrospettiva tra il team di sviluppo, finalizzati a identificare possibili miglioramenti alla gestione stessa di progetto.
• È possibile descrivere i requisiti sotto forma di user stories.
• Il “software funzionante” è una metrica con cui è possibile definire lo stato di avanzamento effettivo di un progetto. Non è forse la definizione più appropriata di “earned value” nel caso di progetti di sviluppo software?

Conclusione
Il nostro obiettivo come PM o membri di team progettuali è la buona riuscita del progetto. Per raggiungere questo scopo siamo liberi di attingere a tutti gli strumenti (tradizionali o agili) che vogliamo e di integrarli in una efficace gestione progettuale, liberandoci dai vecchi pregiudizi per cui un progetto “o è waterfall o è agile”.

Le considerazioni qui riportate sono alcune delle motivazioni che hanno spinto GFT alla realizzazione del suo nuovo tool di Project Management: Cardinis Kite.