Agile o Waterfall (Sequenziale) – quale è migliore?

Come professionista agile, formatore, coach e consulente, potresti aspettarti che io dica: "Agile è l'unico modo per avere successo—pagami un sacco di soldi e ti mostrerò perché!"

Ma ecco la verità (spoiler): posso rispondere a questa domanda solo con "dipende". Potrebbe sembrare vago, ma è spesso la risposta più onesta e preziosa.

Alla fine, solo tu puoi decidere cosa sia meglio per il tuo progetto e la tua organizzazione, basandoti sui fattori trainanti e sui vincoli che conosci meglio di me. Spero che questo articolo ti aiuti a capirlo da solo.

Iniziamo guardando le idee fondamentali dietro ogni approccio.

La gestione di progetti Waterfall segue un approccio sequenziale e predittivo. L'ambito è solitamente fisso e la soluzione viene spesso specificata completamente prima dello sviluppo. La consegna può avvenire come un singolo 'big bang' o in fasi, dove ogni fase fornisce una parte significativa della soluzione complessiva.

Un tipico metodo waterfall prevede questi passaggi:

1. Analisi: Identificare, documentare, concordare e approvare i requisiti e tutti gli standard di qualità. Nell'IT, questo include i requisiti non funzionali.
2. Progettazione: Creare e approvare una progettazione dettagliata che soddisfi i requisiti concordati e i criteri di qualità.
3. Sviluppo: Costruire la soluzione secondo la progettazione, assicurandosi che soddisfi tutti i requisiti specificati e gli standard di qualità.
4. Test: Testare accuratamente la soluzione per confermare che soddisfi i requisiti concordati, la progettazione e altri criteri di qualità.
5. Distribuzione: Mettere in uso la soluzione per fornire il valore aziendale previsto.

Ogni passaggio deve essere pianificato e dotato di risorse, con tutte le attività chiaramente identificate, stimate e assegnate. In molti casi le attività verranno suddivise in compiti dettagliati e rappresentate sotto forma di diagramma di GANTT. Per un progetto a fasi, l'analisi e la progettazione di alto livello dovrebbero avvenire per prime per stabilire il contesto e l'ambito di ciascuna fase.

L'approccio waterfall richiede uno stile predittivo di gestione del progetto in cui ogni fase produce documentazione che delinea quello che la fase successiva deve fare.

Tutto il lavoro per ogni fase è pianificato basandosi sull'aspettativa (essa stessa una previsione) che il risultato corrisponderà a quello che è stato concordato. La documentazione propriamente approvata è il modo principale per comunicare l'intento del progetto a tutti coloro che sono coinvolti o interessati.

Il controllo del progetto si basa sul dimostrare che il lavoro consegnato corrisponde alla documentazione della fase precedente, così come sul seguire il piano approvato per la fase corrente. Qualsiasi cambiamento dovrebbe passare attraverso un processo formale in cui la documentazione viene rivista e approvata. Idealmente, la documentazione viene esaminata regolarmente per assicurarsi che soddisfi ancora le esigenze aziendali in evoluzione.

I cambiamenti possono essere identificati dal lavoro nelle fasi successive del processo waterfall. Ad esempio, con problemi scoperti durante la fase di Test che identificano una discrepanza tra i requisiti specificati e l'attuale esigenza aziendale. È richiesta un'analisi di tale discrepanza con eventuali cambiamenti concordati che si propagano lungo la waterfall per essere infine testati di nuovo.

La percezione del successo nel metodo waterfall tende, quindi, ad essere correlata a quanto bene la previsione corrisponde al bisogno reale e a quanto strettamente gli output si allineano con la previsione in termini di budget, tempistiche e qualità.

Il processo a cascata può sembrare semplice all'inizio, ma spesso si rivela più complesso del previsto. Si basa fortemente sulla documentazione, utilizza approvazioni gerarchiche e segue una pianificazione centralizzata. Poiché richiede documentazione e pianificazione dettagliate fin dall'inizio, il processo può diventare complicato, con molte parti correlate che devono essere collegate affinché il processo raggiunga il risultato desiderato.

Vantaggi:

• Struttura Lineare: L'approccio passo dopo passo è facile da comprendere per i project manager e da spiegare agli stakeholder.
• Pianificazione Prevedibile: L'analisi e la progettazione complete all'inizio supportano una pianificazione e un budgeting chiari e precisi.
• Monitoraggio Semplice: Il progresso può essere monitorato attraverso la documentazione (mostrando come vengono raggiunte le milestone) e verificato rispetto al piano (per confermare che le attività si completano nei tempi e nel budget previsti).

Svantaggi:

• Gestione delle Modifiche Complessa: Gestire le modifiche necessarie può essere macchinoso, a volte portando i team a bypassare completamente il processo con conseguente perdita di controllo.
• Rilevamento Tardivo dei Problemi: Lo sviluppo in incrementi grandi con test concentrati principalmente alla fine del processo può rivelare problemi troppo tardi, causando ritardi imprevisti e sforamenti dei costi.
• Ridotto Focus sul Valore di Business: L'estesa analisi e documentazione iniziale non offre alcun valore di business diretto; esistono esclusivamente per guidare il processo.

Pur mantenendo un elemento processuale distinto per inquadrare lo sviluppo, un approccio agile alla gestione dei progetti si concentra più sulle persone che sui processi. Il lavoro preliminare è intenzionalmente leggero, delineando solo la soluzione e il piano ad alto livello lasciando i dettagli più specifici fino all'ultimo momento responsabile prima dello sviluppo. Tipicamente, lo sviluppo procede funzionalità per funzionalità all'interno di "Sprint" di durata fissa.

I partecipanti al progetto – e questo è importante, inclusi gli operatori commerciali all'interno dei team di sviluppo – collaborano durante tutto il progetto. Costruiscono incrementi più piccoli rispetto al tradizionale waterfall, utilizzando un processo iterativo.

Ogni iterazione include analisi, progettazione, costruzione, test e idealmente distribuzione, in cicli che possono durare solo poche ore o estendersi per diversi giorni o settimane (anziché le settimane o i mesi spesso visti nel waterfall). L'obiettivo è distribuire parti della soluzione non appena possono fornire valore.

Lo sviluppo si basa sulla collaborazione dettagliata di individui competenti e qualificati, autorizzati dall'organizzazione a sviluppare una soluzione che soddisfi le esigenze aziendali.

Questi individui definiscono i dettagli dell'esigenza prima di pianificare il lavoro di sviluppo richiesto. Poi eseguono questo piano, adattandolo continuamente per rimanere concentrati nel fornire il massimo valore. Per una vera agilità, i team spesso seguono valori come quelli che si trovano in Scrum, che attualmente è l'approccio di consegna agile più ampiamente adottato.

L'approccio iterativo è altamente tollerante ai cambiamenti perché rimanda la pianificazione dettagliata fino all'ultimo momento responsabile, utilizzando dati in tempo reale e cicli di pianificazione brevi. Invece di essere completamente prevista fin dall'inizio, la soluzione emerge gradualmente per soddisfare i bisogni che erano stati delineati (ma non definiti meticolosamente) all'inizio del progetto.

Dando priorità ai requisiti di alto livello fin dall'inizio e gestendo prima quelli più importanti, consente ai team agili di mantenere un controllo stretto su scadenze e budget. Lo sviluppo semplicemente termina in modo controllato una volta raggiunti i limiti di tempo o budget, con solo gli elementi meno preziosi esclusi dalla consegna finale.

Poiché i cicli di sviluppo sono brevi (solitamente circa due settimane) e fissi, ha senso misurare il successo attraverso la consegna incrementale di valore a un ritmo prevedibile.

L'approccio iterativo e incrementale, con cicli brevi guidati da team auto-organizzati e responsabilizzati, spesso appare caotico. Ma quando è composto da persone competenti, collaborative e disciplinate, è altamente efficiente ed efficace. Detto questo, il rischio di utilizzare un approccio agile con individui che non sono competenti, collaborativi e disciplinati molto probabilmente porterà al fallimento. Questo rende la supervisione (ma non la gestione) essenziale finché i team non abbiano dimostrato la loro capacità collettiva di consegnare risultati.

Vantaggi:

• Sviluppo Iterativo: Cicli di sviluppo rapidi con opportunità di collaborazione e feedback continuo riducono il rischio di costruire una soluzione che non soddisfa le reali necessità.
• Consegna Incrementale di Valore: Fornire valore tangibile in intervalli brevi migliora il controllo complessivo rendendo più facile monitorare i progressi e identificare azioni correttive.
• Adattabilità: Lasciare i dettagli all'ultimo momento responsabile consente alle soluzioni di emergere per soddisfare le esigenze attuali piuttosto che quelle previste.

Svantaggi:

• Può sembrare destrutturato: Specialmente per coloro che sono abituati a controlli basati sui processi. Non è adatto a manager e leader con elevate esigenze di controllo.
• Alta competenza e collaborazione da parte di tutti i coinvolti: I leader richiedono fiducia per dare fiducia e competenza per responsabilizzare i loro team collaborativi.
• Potenziale per caos e fallimento: Team privi di competenza e professionalità dimostrate possono fallire senza un'adeguata supervisione.

Nota: gli svantaggi descritti sopra si applicano a team o organizzazioni che sono nuove al modo di lavorare agile; dove c'è una genuina competenza con l'agilità è difficile identificare svantaggi universali, anche se potrebbero sorgere quelli specifici del contesto.

Le principali differenze tra un approccio agile e un approccio waterfall possono essere riassunte in 5 dimensioni:

1. Sviluppo della Soluzione – Emergente vs. Specificato:

• Agile: La soluzione emerge nel tempo per soddisfare le esigenze aziendali in evoluzione. I dettagli si definiscono man mano che ci si avvicina allo sviluppo, mantenendo la soluzione flessibile.
• Waterfall: La soluzione è definita fin dall'inizio per soddisfare un'esigenza prevista. È necessario un controllo accurato delle modifiche per mantenere l'allineamento con le esigenze in cambiamento.

2. Partecipanti al Progetto – Collaborativi e Trasversali vs. Isolati e Specializzati:

• Agile: I membri del team lavorano insieme con ruoli ampi, facendo tutto il necessario per raggiungere il loro obiettivo condiviso. L'obiettivo è evitare la comunicazione tramite documentazione e minimizzare i passaggi di consegne ovunque possibile.
• Waterfall: Pur essendo spesso presente un certo grado di collaborazione, questa è spesso focalizzata su attività specifiche e specializzate (come la raccolta dei requisiti). I partecipanti al progetto tendono ad adottare l'approccio compartimentato dell'Ingegneria Industriale che ha dominato il pensiero del XX secolo, tipicamente con comunicazione e controllo gestiti tramite documentazione.

3. Gestione – Auto-Organizzazione vs. Gestione Diretta:

• Agile: I team si organizzano e si gestiscono autonomamente, decidendo come completare i compiti e adeguando i processi man mano che apprendono.
• Waterfall: I team tipicamente ricevono indicazioni dai manager, che decidono cosa deve essere fatto, da chi e quando. Il livello di dettaglio in queste istruzioni può variare in base al progetto o allo stile del manager.

4. Cambiamento – Abbracciato vs. Resistito:

• Agile: Poiché i team lavorano verso obiettivi ampi senza definire ogni dettaglio fin dall'inizio, accolgono favorevolmente i cambiamenti quando emergono nuove esigenze o intuizioni.
• Waterfall: La gestione del cambiamento è burocratica e costosa perché richiede analisi approfondita, documentazione e approvazione. Di conseguenza, spesso agisce come una barriera ai cambiamenti necessari.

5. Controllo basato su: Disciplina Professionale vs. Conformità ai Processi

• Agile: Si basa molto sulla competenza, disciplina e auto-organizzazione del team. I membri del team si assumono impegni reciproci e possiedono collettivamente compiti e soluzioni.
• Waterfall: Utilizza pianificazione dettagliata e istruzioni chiare. Il ruolo di ognuno è definito fin dall'inizio, e il project manager coordina le attività. Il successo dipende dal seguire il piano e i processi come progettati.

Come ho accennato prima, dipende…

Nel mondo complesso di oggi, è improbabile gestire un progetto completamente agile o completamente waterfall. Più spesso, i team scoprono che un po' di agilità può aggiungere valore a un progetto principalmente waterfall, mentre alcuni elementi waterfall hanno senso in un progetto altrimenti agile. Questa combinazione viene spesso chiamata approccio ibrido, posizionandosi nell'area grigia tra i due estremi.

Quindi, la vera domanda di un project manager non è "Quale metodo puro dovrei scegliere?" ma piuttosto "Dove dovrebbe posizionarsi il mio progetto in questo spettro?" I metodi Agile prosperano in ambienti caratterizzati da elevata volatilità, incertezza, complessità e ambiguità (VUCA). Al contrario, gli approcci waterfall funzionano generalmente meglio quando le cose sono più stabili, certe, semplici e chiare.

Il framework Cynefin può aiutarti a individuare dove il tuo progetto potrebbe collocarsi in questo spettro.

Cynefin, pronunciato kuh-nev-in, è una parola gallese che indica i molteplici fattori interconnessi nel nostro ambiente e nella nostra esperienza che ci influenzano (nel modo in cui pensiamo, interpretiamo e agiamo) in modi che non potremo mai comprendere completamente.

In una semplificazione riconosciutamente eccessiva del Framework Cynefin, l'ambiente in cui stiamo lavorando – in questo caso il nostro ambiente di progetto – può essere collocato su uno spettro caratterizzato come chiaro, complicato, complesso o caotico.

In un ambiente di progetto che è:

• Chiaro, c'è un percorso ovvio tra problema e soluzione.
• Complicato, il percorso tra problema e soluzione potrebbe non essere ovvio, ma una buona analisi rivelerà un percorso verso una soluzione appropriata.
• Complesso, non è possibile identificare un singolo percorso, nemmeno con l'analisi, perché le previsioni possono essere fatte solo sulla base della teoria piuttosto che dell'esperienza.
• Caotico, non c'è alcuna base per le previsioni perché ci sono troppi fattori variabili o in conflitto. L'unico modo per procedere è attraverso la sperimentazione.

In quanto sopra, il dominio chiaro si presta al puro waterfall e il dominio caotico richiede agilità. Gli altri due – i più comuni nella realtà – sono probabilmente meglio serviti da un approccio ibrido. Quindi, chiediti: "quale dei suddetti descrive meglio il mio ambiente di progetto?" e lascia che questo guidi la tua selezione dell'approccio.

Devi anche considerare altri vincoli determinati dalle regole e dalla cultura della tua organizzazione nel decidere l'approccio più sensato per il tuo progetto. Cercare di far funzionare un approccio waterfall in una cultura caratterizzata dall'agilità o un approccio agile in una cultura caratterizzata da comando e controllo causerà problemi.

Un approccio ibrido potrebbe avere maggiori probabilità di "vendere" e riuscire.

Il Manifesto Agile, migliorato per ampliare la sua applicabilità oltre il software, identifica quattro dichiarazioni di valore destinate a orientare i professionisti verso comportamenti agili. Chiunque miri a lavorare in modo agile dovrebbe valorizzare:

Concentrandosi sugli elementi a sinistra pur riconoscendo ancora valore in quelli a destra.

Sebbene ci sia dibattito su se il Manifesto originale si applichi completamente nel mondo odierno – in particolare in un contesto software – le dichiarazioni di valore offrono ancora una guida utile per la governance dei progetti. Ha senso basare la governance per un progetto agile sugli elementi a sinistra, e la governance per un progetto waterfall sugli elementi a destra.

• Persone e lavoro di squadra: Monitoraggio e promozione della disciplina professionale e della collaborazione.
• Fornire valore aziendale: Concentrarsi sul valore che supporta le esigenze aziendali, piuttosto che limitarsi a soddisfare i requisiti dei processi.
• Coinvolgimento attivo del business: Avere rappresentanti aziendali che lavorano a stretto contatto con il team durante tutto il progetto.
• Soddisfare le esigenze attuali al momento del deployment: Garantire che la soluzione corrisponda ai reali requisiti aziendali al lancio, anche se tali requisiti differiscono dal piano iniziale.

• Seguire processi predefiniti: Garantire che tutti rispettino le fasi stabilite e le approvazioni.
• Produrre documentazione predittiva: Sviluppare specifiche chiare e verificare che la soluzione sia allineata con esse.
• Approvare le modifiche correttamente: Validare tutte le modifiche alla documentazione originale.
• Aderire ai piani: Garantire che i piani rimangano accurati e reattivi alle modifiche approvate.

In una configurazione ibrida, la governance deve trovare il giusto equilibrio tra elementi agile e waterfall. Questo comporta personalizzare quali parti di ciascun approccio abbiano più senso per il contesto specifico del progetto.

L'approccio di consegna del progetto più efficace dovrebbe essere guidato dal contesto – sia dalla natura del lavoro che dall'ambiente in cui il progetto si svilupperà. Diffidate da chiunque promuova l'agile puro o il waterfall puro come ricetta universalmente applicabile per il successo.

Con un ultimo riferimento al framework Cynefin – descrive uno stato di Aporia (che significa impasse) o Confusione e non è un posto dove voler essere. Molto probabilmente vi ritroverete, voi e il vostro progetto, a soffrire qui se non siete in grado o non siete disposti ad adattare l'approccio del vostro progetto al suo contesto e al suo ambiente.

Dovete pensare con la vostra testa, analizzare il contesto e agire di conseguenza. Facendo così, avete le migliori possibilità di passare dall'Aporia/Confusione a uno degli altri stati dove un approccio, molto probabilmente ibrido, ottimizzerà le vostre opportunità di successo del progetto.