Agile o Waterfall: il dibattito tra i team di progettoè in corso da decenni. Ma la risposta è davvero così chiara come pensiamo? In questo articolo, Milly Gladstone sfata il mito ed esplora quale approccio porti effettivamente a termine un progetto.
Dal 2001, anno in cui è stato pubblicato il Manifesto Agile, i professionisti della gestione dei progetti hanno discusso la questione: dovremmo gestire i progetti utilizzando Agile o Waterfall? Negli ultimi anni il dibattito sembra essersi risolto. Agile è moderno, veloce e flessibile; Waterfall è tradizionale, rigido e obsoleto.
Tuttavia, molte organizzazioni che dichiarano di utilizzare Agile fanno tutt'altro. Hanno adottato la terminologia e i rituali: il lavoro è organizzato in sprint, le riunioni diventano stand-up e (a volte) ci sono revisioni etichettate come retrospettive. Ma la mentalità o la filosofia inerente all'Agile, che sta alla base di questi rituali, è spesso implementata solo in modo frammentario, se non addirittura ignorata.
Il risultato è un'illusione di agilità. I progetti possono sembrare più veloci in superficie, ma rimangono vincolati da processi legacy e comportamenti immutati. Questa tensione è particolarmente evidente nell'apprendimento e nello sviluppo, dove i team bilanciano la progettazione creativa, l'allineamento strategico e la consegna logistica. Un fraintendimento su come e quando utilizzare Agile o Waterfall (o, come vedremo più avanti, su come applicarli in combinazione) porta spesso a iniziative di apprendimento tardive, eccessivamente complicate o scollegate dall'esperienza dello studente.
Il vantaggio di Waterfall
La gestione dei progetti Waterfall consiste nel pianificare in anticipo e in dettaglio, per poi eseguire il piano. È interessante perché fornisce struttura, chiarezza e controllo. Il lavoro procede attraverso fasi chiaramente definite: requisiti, progettazione, implementazione, test e consegna. Ogni fase viene completata prima che inizi la successiva. Agli stakeholder viene comunicato in anticipo quale sarà il risultato finale, quando sarà pronto e quanto costerà.
In determinati contesti, questo approccio funziona bene. Ad esempio, nella formazione e nello sviluppo è adatto a progetti di conformità su larga scala, in cui i contenuti devono essere standardizzati, verificati dal punto di vista legale e distribuiti in modo coerente in tutte le regioni. L'ambito è facile da definire e fissare, potrebbe esserci una tempistica da rispettare per mantenere la conformità e c'è una certa complessità da pianificare in termini di sequenza dei risultati finali.
La prevedibilità e il controllo offerti dalla gestione dei progetti Waterfall possono tuttavia limitare l'innovazione. Se i requisiti vengono fissati troppo presto, si perde l'opportunità di adattarsi al feedback degli studenti o alle esigenze organizzative emergenti. Quando arriva il feedback dal mondo reale, è costoso agire o, più probabilmente, è troppo tardi per agire se si vuole rispettare la scadenza.
In altre parole, Waterfall è ottimo per fornire risultati affidabili, ma questi potrebbero non essere i risultati giusti.
L'alternativa Agile
Agile è stato creato proprio per ovviare a questa limitazione.
Il suo fondamento è il Manifesto Agile, che sottolinea:
- Gli individui e le interazioni piuttosto che i processi e gli strumenti;
- Soluzioni funzionanti rispetto alla documentazione completa;
- Collaborazione con il cliente rispetto alla negoziazione del contratto;
- Risposta al cambiamento rispetto al seguire un piano.
È utile ricordare che Agile è stato sviluppato in risposta alle esigenze di enormi progetti di sviluppo software per applicazioni governative e di difesa. Questi progetti erano così complessi e di così ampia portata che gli strumenti e le tecniche tradizionali hanno smesso di funzionare. Era necessario un altro approccio e così è nato Agile.
I principi del Manifesto Agile si adattano bene alla formazione e allo sviluppo. Ad esempio, dare valore alle persone e alle interazioni incoraggia i team interfunzionali a progettare insieme esperienze di apprendimento con le parti interessate e gli studenti, piuttosto che affidarsi esclusivamente a briefing statici. Dare priorità alle soluzioni funzionanti rispetto alla documentazione consente ai progettisti della formazione di prototipare e testare rapidamente i contenuti, invece di passare mesi a perfezionare le risorse prima di ottenere un feedback reale. La collaborazione tra clienti e studenti garantisce che le soluzioni siano basate su esigenze reali, e l'accettazione del cambiamento incoraggia l'iterazione quando il feedback o le priorità aziendali cambiano.
Per i team di formazione e sviluppo, l'adozione di queste idee può provocare un cambiamento di mentalità che trasforma il modo in cui vengono realizzate le iniziative di apprendimento. Invece di progettare un intero programma di sviluppo della leadership o delle vendite in modo isolato, i team possono sperimentare moduli, raccogliere feedback e perfezionare il loro approccio. L'apprendimento diventa basato su prove concrete, reattivo agli utenti e più in linea con i risultati previsti.
“Agile” come teatro
L'Agile, tuttavia, viene applicato in modo superficiale, apportando pochi benefici (e spesso costi aggiuntivi). Alcune organizzazioni cadono nella trappola di adottare il linguaggio dell'Agile e i suoi metodi di implementazione primari senza abbracciare sufficientemente la sua filosofia o cambiare mentalità per ottenere risultati. I team possono tenere riunioni chiamate “stand-up” e denominare le fasi di lavoro “sprint”, ma il processo decisionale e l'interazione con i clienti rimangono invariati rispetto ai vecchi metodi.
Questo è ciò che a volte viene chiamato teatro Agile: la forma esiste, ma non la funzione.
Nella formazione e nello sviluppo, questo può tradursi in team che eseguono “iterazioni” ma continuano a consegnare tutto alla fine; revisioni degli stakeholder etichettate come “retrospettive”, senza un reale apprendimento o adattamento, o test degli studenti che vengono ritardati fino al rilascio finale, impedendo un vero miglioramento iterativo.
Approcci ibridi efficaci
La verità è che sono pochissime le organizzazioni che adottano un approccio Agile “puro” e quelle che lo fanno tendono ad essere nel settore dello sviluppo di software su larga scala, l'industria per cui Agile è stato originariamente concepito.
Questo solleva alcune domande: come possono le altre organizzazioni passare dalla gestione dei progetti Waterfall e ottenere alcuni dei vantaggi di Agile?
Una strada è quella di adottare un approccio ibrido ben progettato che bilancia la pianificazione e il controllo di Waterfall con la flessibilità e la creatività di Agile.
Ad esempio:
- Utilizzare Waterfall per l'allineamento iniziale, definendo obiettivi, budget e dipendenze.
- Utilizzare Agile per la progettazione e la consegna, prototipando esperienze di apprendimento, raccogliendo feedback e perfezionando i contenuti sulla base delle risposte reali degli utenti.
Questa combinazione consente ai team di mantenere la responsabilità e promuovere al contempo il miglioramento continuo. Fondamentalmente, il suo successo dipende dalla leadership che crea una cultura che valorizza l'apprendimento, l'adattamento e l'evidenza rispetto alla semplice conformità al processo. Senza questo cambiamento culturale, i progetti ibridi torneranno inevitabilmente a comportamenti simili a quelli Waterfall.
Un semplice esempio di come rendere possibile tutto ciò è che i leader interiorizzino il fatto che i prototipi non sono destinati ad essere rifiniti o definitivi.
Il divario culturale
Il dibattito Agile contro Waterfall riguarda meno il processo e più la mentalità.
Waterfall rappresenta il controllo, la convinzione che il successo possa essere ottenuto attraverso una pianificazione e una documentazione adeguate. Agile rappresenta la curiosità, la consapevolezza che l'incertezza è inevitabile e che l'apprendimento è continuo.
Alcuni aspetti da tenere in considerazione quando si valuta l'efficacia dell'uso dell'Agilità nei progetti di formazione e sviluppo sono:
- Gli studenti sono coinvolti sin dalle prime fasi di sviluppo del progetto?
- Gli stakeholder (compresi i clienti) accettano prototipi imperfetti come strumenti di apprendimento?
- Le intuizioni e le prove hanno la priorità rispetto alla rifinitura?
- Il feedback è ben accetto come dato, piuttosto che come forma di disturbo?
Queste pratiche riflettono i valori del Manifesto Agile in azione. I team che le interiorizzano sono meglio attrezzati per fornire un apprendimento che si adatta alle esigenze del mondo reale, piuttosto che contenuti statici che possono diventare rapidamente irrilevanti.
La questione non è quale sia l'approccio migliore per la gestione dei progetti. Entrambi sono metodi che possono essere applicati in vari modi, singolarmente o in combinazione. Ciò che conta di più è la mentalità con cui vengono applicati: la volontà di pianificare con attenzione, testare costantemente e adattarsi in modo intelligente.
Mentre i team cercano di affrontare le sfide e le opportunità derivanti da un panorama in rapida evoluzione, tra cui l'ascesa dell'IA sia come strumento di apprendimento che come competenza da acquisire, questa mentalità è la vera fonte di agilità.
