Waterfall vs Agile: differenze, quando usarli e come scegliere

Perché oggi un Project Manager deve conoscere sia Waterfall sia Agile?

Waterfall vs Agile è il confronto tra due modelli di gestione progetti: il primo lineare e sequenziale, il secondo iterativo e incrementale. Non è una questione teorica. È la scelta che determina, concretamente, se un progetto finisce nei tempi previsti o sfoera il budget del 30%.

Il contesto attuale dei progetti ibridi

Waterfall è stato diffuso come modello formale nel 1970, derivando dall’ingegneria dei sistemi degli anni ’60 (fonte: Wrike). Agile invece è arrivato dopo, con l’Agile Manifesto del 2001 che ha codificato principi già in circolazione ma mai scritti nero su bianco. Trent’anni di distanza tra i due. Eppure oggi un Project Manager deve conoscerli entrambi.

Perché? In soldoni: le aziende italiane non lavorano più in modo puro. Un programma di trasformazione digitale in una media impresa manifatturiera, per fare un esempio reale, ha spesso una fase di analisi e design completamente sequenziale — requisiti definiti, approvati, congelati — e poi una fase di sviluppo software che gira su sprint da due settimane. Waterfall nella struttura del programma, Agile nell’esecuzione operativa. Ibrido, sempre.

Waterfall segue fasi precise: Requisiti, Design, Implementazione, Verifica, Manutenzione. Ogni fase deve essere completata e approvata prima che inizi la successiva. Nessun ritorno. Nessuna sovrapposizione. Funziona bene quando i requisiti sono stabili e il costo del cambiamento è alto (come nel settore manifatturiero o nelle infrastrutture fisiche). Agile invece è costruito per situazioni in cui i requisiti cambiano e la validazione precoce conta più di un piano dettagliato fatto in anticipo.

Ma attenzione: la scelta sbagliata di metodologia è una delle cause principali di sforamento di budget. Non la difficoltà tecnica del progetto. Non i fornitori. La metodologia sbagliata applicata al contesto sbagliato. Nei miei anni di formazione con Project Manager ho visto questo errore ripetersi in modo quasi meccanico: team Agile su progetti con requisiti normativi fissi, oppure team Waterfall su prodotti digitali dove il cliente non sa ancora cosa vuole. Entrambi finiscono male.

Cosa cercano davvero le aziende nel 2026

Le offerte di lavoro per ruoli senior di Project Management in Italia, a conti fatti, non chiedono più “conosci Agile?” come requisito differenziante. Lo danno per scontato. Quello che cercano è la capacità di leggere il contesto e scegliere, o meglio, combinare.

Agile valorizza quattro principi fondamentali: individui e interazioni sopra processi e strumenti, software funzionante sopra documentazione esaustiva, collaborazione col cliente sopra negoziazione contrattuale, risposta al cambiamento sopra l’esecuzione di un piano (fonte: BMC Software). Sono principi che un Project Manager deve conoscere a fondo, non citare a memoria. Perché in un contesto ibrido, applicarli a metà o male produce risultati peggiori di un Waterfall puro.

E quindi? Conoscere entrambi gli approcci non è un vantaggio competitivo. È un requisito di ingresso per i ruoli senior. Chi non sa ragionare in termini di cicli iterativi non riesce a gestire il backlog di uno sprint. Chi non sa costruire una WBS sequenziale non riesce a strutturare le dipendenze di un programma complesso. Servono tutti e due. Punto.

A mio avviso, il vero salto professionale non sta nel certificarsi su uno dei due modelli, ma nel capire quando un progetto richiede la rigidità di Waterfall e quando invece quella rigidità diventa il problema. PMI lo ha riconosciuto esplicitamente: Agile deriva dal pensiero Lean, con tutto ciò che questo implica in termini di eliminazione degli sprechi e flusso di valore continuo. Non è il contrario di Waterfall. È una risposta a contesti diversi.

Cos’è Waterfall e come funziona il modello a cascata?

Waterfall è un modello di ciclo di vita lineare e sequenziale in cui le fasi del progetto vengono completate in ordine, una dopo l’altra. Ogni fase ha un inizio e una fine precisi. Prima di passare alla fase successiva, la fase corrente deve essere completata e formalmente approvata, secondo quanto indicato da Adobe e confermato da BMC Software. Non si torna indietro. Almeno non senza costi significativi.

Il principio di fondo è semplice: sai cosa devi costruire, documenti tutto all’inizio, poi esegui. I requisiti vengono raccolti e fissati nella prima fase del progetto, e quella documentazione diventa la base di tutto il lavoro successivo. È un approccio che dà certezze sul percorso, ma presuppone che le certezze esistano davvero già in partenza.

Le origini negli anni ’60 e ’70

Waterfall non nasce per caso. Emerge dall’ingegneria dei sistemi e del software tra gli anni ’60 e ’70, in un contesto industriale in cui il cambiamento in corsa era costoso e i progetti si misuravano in anni, non in settimane. Viene poi popolarizzato nel 1970 come modello sequenziale strutturato, secondo quanto riporta Wrike.

La logica era quella della catena di montaggio: ogni stazione fa il suo lavoro, passa il pezzo alla stazione successiva, e nessuno rimette mano a quello che è già stato validato. Funzionava bene per l’hardware, per i grandi appalti pubblici, per i sistemi dove ogni modifica aveva un prezzo altissimo. E funziona ancora oggi, in certi contesti.

Nei miei anni di formazione in project management ho visto molti team scegliere Waterfall non per ignoranza di Agile, ma perché il loro settore (edilizia, farmaceutica, difesa) non lasciava spazio all’ambiguità. Quando i requisiti sono stabili e il costo del cambiamento è alto, come dice Wrike, Waterfall resta la scelta razionale.

Le 5 fasi del ciclo Waterfall

Il modello si articola in 5 fasi standard, come documentato da BMC Software e IBM:

• Requirements: si raccolgono e documentano tutti i requisiti del progetto. È la fase più critica, perché gli errori qui si propagano su tutto il resto.
• Design: si progetta l’architettura della soluzione sulla base dei requisiti approvati. Si definiscono le specifiche tecniche, i flussi, le interfacce.
• Implementation: il team sviluppa il prodotto seguendo il design. È la fase più lunga in termini di effort operativo.
• Verification: si testa tutto. Il prodotto viene confrontato con i requisiti della prima fase. Se non corrisponde, si corregge.
• Maintenance: il prodotto è in produzione e viene mantenuto. Bug fix, aggiornamenti, piccoli adattamenti.

Ogni fase produce documentazione formale che viene approvata prima di aprire la successiva. E questo è al tempo stesso il punto di forza e il tallone d’Achille di Waterfall. La tracciabilità è perfetta. Ma se a metà del progetto il cliente cambia idea su qualcosa di fondamentale, tornare alla fase di Requirements significa rimettere in discussione tutto ciò che è venuto dopo.

In soldoni: Waterfall funziona quando sai dove stai andando. Quando non lo sai, il modello comincia a scricchiolare.

Cos’è Agile e perché è nato come reazione a Waterfall?

Agile è una pratica incrementale e iterativa di gestione progetti che valorizza “individui e interazioni rispetto a processi e strumenti” (fonte: agilemanifesto.org). Non è uno strumento. Non è un software. È un modo di pensare il lavoro che nasce, storicamente, come risposta diretta ai limiti del modello Waterfall.

Waterfall era già consolidato dagli anni ’70. Requisiti prima, progettazione dopo, sviluppo alla fine. Un’unica sequenza rigida in cui ogni fase doveva essere approvata prima che quella successiva potesse cominciare. Funzionava bene quando i requisiti erano stabili e il costo del cambiamento era alto. Ma in ambito software, i requisiti quasi mai restano stabili.

Ecco il punto di rottura.

Nel febbraio del 2001, diciassette sviluppatori si riunirono a Snowbird, nello Utah, e il 11 febbraio 2001 firmarono il Manifesto Agile (fonte: agilemanifesto.org). Non era un documento tecnico. Era una presa di posizione. Nei miei anni di formazione in project management ho visto molti team trattarlo come una lista di regole da seguire, ma il Manifesto è altro: è una critica esplicita al modello sequenziale che aveva dominato fino ad allora, tradotta in quattro valori precisi.

I 4 valori del Manifesto Agile

I 4 valori del Manifesto Agile sono formulati come scelte di priorità, non come divieti assoluti (fonte: agilemanifesto.org):

• Individui e interazioni rispetto a processi e strumenti
• Software funzionante rispetto a documentazione esaustiva
• Collaborazione col cliente rispetto a negoziazione dei contratti
• Risposta al cambiamento rispetto a seguire un piano

Ogni valore ha un “rispetto a”. Il Manifesto non dice che i processi sono inutili. Dice che le persone vengono prima. Non dice che la documentazione non serve. Dice che il software che funziona ha più valore. È una gerarchia, non un rifiuto. E questa distinzione, a conti fatti, è quella che più sfugge a chi legge Agile in fretta.

Il legame con il Lean thinking è diretto: Agile deriva da quella tradizione di pensiero (fonte: PMI), che mette al centro l’eliminazione degli sprechi e la consegna continua di valore. Waterfall accumula tutto il valore consegnato alla fine del progetto. Agile lo distribuisce lungo il percorso.

Sprint, iterazioni e feedback continuo

In Agile, il lavoro si rompe in feature e task consegnate in timebox brevi chiamati sprint, tipicamente da una a quattro settimane. Non si consegna un prodotto completo dopo sei mesi. Si consegna una parte funzionante ogni due settimane, si dimostra agli stakeholder, si raccoglie feedback e si aggiusta la rotta.

Questo cambia tutto. Davvero.

I team Agile sono cross-funzionali e auto-organizzati: non c’è un project manager che assegna i compiti dall’alto. Il team decide internamente come raggiungere l’obiettivo dello sprint, e questa responsabilità distribuita è sia la forza del modello sia, spesso, il suo punto più difficile da gestire per chi arriva da ambienti Waterfall.

Al termine di ogni sprint si tiene una sprint review: il team dimostra il lavoro completato, gli stakeholder lo vedono girare, fanno domande, cambiano idea. Ma questo non è un fallimento della pianificazione. È esattamente il meccanismo che Agile progetta per funzionare. Secondo me, il feedback di fine sprint è l’elemento che più distingue Agile da qualsiasi approccio tradizionale: non si aspetta la fine del progetto per scoprire che il cliente voleva qualcosa di diverso.

In soldoni, Agile è costruito per situazioni in cui i requisiti cambiano e la validazione precoce vale più di un piano perfetto scritto il primo giorno (fonte: Wrike). Waterfall no. Ed è per questo che, nel confronto waterfall vs agile, la scelta non è mai di principio: dipende dal tipo di progetto che hai davanti.

Quali sono le differenze concrete tra Waterfall e Agile?

La differenza chiave tra Waterfall e Agile è il modo in cui il lavoro viene strutturato nel tempo: Waterfall in fasi consecutive, Agile in iterazioni brevi. Non è solo una questione di metodo formale. È un modo diverso di concepire il rischio, il cambiamento e il valore consegnato al cliente.

Struttura del lavoro: fasi vs sprint

Waterfall progredisce attraverso fasi distinte, una dopo l’altra. Come descrive BMC Software, le fasi tipiche sono: Requirements, Design, Implementation, Verification, Maintenance. Ogni fase deve essere completata e approvata prima che la successiva possa iniziare. Non si torna indietro. Non si sovrappone.

Agile funziona in modo opposto. Si lavora per cicli brevi e ripetuti, chiamati sprint o iterazioni, in cui si progetta, si sviluppa e si consegna una porzione funzionante del prodotto. Poi si ricomincia. Secondo Adobe, questa struttura iterativa è la differenza strutturale fondamentale tra i due approcci.

In soldoni: con Waterfall sai esattamente dove sei nel processo, ma non puoi cambiare rotta. Con Agile la rotta si aggiusta sprint dopo sprint.

Gestione dei requisiti e del cambiamento

Qui la distanza tra i due approcci diventa più evidente.

In Waterfall i requisiti si definiscono a monte, prima che il lavoro produttivo inizi, e in linea di principio restano fissi fino alla consegna finale. Wrike precisa che questo modello è particolarmente adatto quando i requisiti sono stabili e il costo del cambiamento è alto. Un impianto industriale, una centrale idroelettrica, un sistema aerospaziale. Contesti dove una revisione in corso d’opera può costare decine di milioni.

Agile invece è costruito esattamente per la situazione opposta: i requisiti probabilmente cambieranno, la validazione anticipata conta più di un piano dettagliato stabilito in partenza. Nei miei anni a seguire team di sviluppo digitale, ho visto progetti software partire con un backlog di 120 funzionalità e arrivare alla consegna con un prodotto completamente diverso, e migliore, rispetto all’idea iniziale. Non è fallimento. È Agile che funziona.

Ma c’è un rischio. Senza disciplina, “i requisiti evolvono” diventa una giustificazione per non decidere mai nulla. L’iterazione non è un’alternativa alla pianificazione: è un modo di pianificare in modo più realistico.

Ruoli, team e documentazione

Waterfall produce documentazione estesa. Ogni fase genera artefatti formali, specifiche tecniche, documenti di design, report di verifica. Il team è spesso organizzato per funzione: analisti, designer, sviluppatori, tester lavorano in sequenza, ognuno nella propria fase.

Agile valorizza, nelle parole del Manifesto Agile riportate da BMC, “working software instead of comprehensive documentation”. Non significa che la documentazione sparisca. Significa che il software funzionante ha più valore di una specifica di 200 pagine che nessuno legge dopo il kick-off.

I team Agile sono tipicamente cross-funzionali: sviluppatori, designer e product owner lavorano insieme sin dal primo sprint. Invece di passarsi il lavoro come in una catena di montaggio, si ragiona insieme sul problema da risolvere. E questa differenza di struttura cambia profondamente il tipo di conversazioni che si fanno in un team.

A mio avviso, la scelta tra i due approcci non dipende da quale sia “migliore” in assoluto. Dipende da cosa stai costruendo, da quanto puoi permetterti di cambiare idea, e da quanto il cliente è disposto a essere presente durante lo sviluppo. Agile chiede coinvolgimento continuo del cliente: non è un modello per chi vuole sparire dopo il contratto.

Quando conviene scegliere Waterfall e quando Agile?

La scelta tra Waterfall e Agile dipende da due variabili: stabilità dei requisiti e costo del cambiamento. Se entrambe sono alte, Waterfall è quasi sempre la scelta giusta. Se invece i requisiti possono evolvere e sbagliare presto costa meno che sbagliare tardi, Agile funziona meglio. Semplice da dire, meno semplice da applicare.

Progetti adatti a Waterfall

Waterfall ha senso quando sai già, prima di iniziare, cosa devi costruire. Secondo Wrike, il modello a cascata è la scelta più adatta quando i requisiti sono stabili e il costo del cambiamento è alto: modificare le fondamenta di un edificio a struttura completata, o riscrivere il firmware di un dispositivo medico già in fase di validazione regolatoria, non è come aggiungere una feature a un’app.

I settori che tendono naturalmente a Waterfall sono costruzioni, farmaceutica, aerospazio, manifattura hardware. Tutti hanno una cosa in comune: le fasi sono sequenziali per vincoli fisici o normativi, non per scelta ideologica. Non si verifica il collaudo strutturale di un ponte prima che la struttura esista. Non si ottiene l’approvazione FDA retroattivamente.

Anche i progetti con contratti a corpo fisso, dove il fornitore consegna un deliverable definito a una data precisa, spingono verso Waterfall. Il cliente vuole sapere cosa riceve. Il fornitore vuole sapere cosa deve produrre. Ambiguità nei requisiti equivale a contenziosi.

Nei miei anni di formazione su metodologie di progetto ho visto team di sviluppo software tornare a Waterfall non per nostalgia, ma perché il contesto lo richiedeva: integrazioni con sistemi legacy documentati in modo rigido, committenti che non potevano partecipare a sprint review settimanali, requisiti normativi che obbligavano a produrre documentazione completa prima di ogni fase successiva. A volte la risposta giusta è quella scomoda.

Progetti adatti ad Agile

Agile è costruito per i contesti in cui i requisiti cambiano, e cambieranno. Sempre secondo Wrike, Agile è la scelta naturale quando la validazione precoce conta più di un piano iniziale rigido: meglio scoprire che una funzionalità non serve dopo due settimane di sprint che dopo sei mesi di sviluppo.

Sviluppo software, prodotti digitali, startup, piattaforme SaaS. Qui Agile domina. E non è un caso.

In questi contesti il mercato cambia, gli utenti danno feedback che modifica le priorità, e il valore di una feature dipende spesso da cosa fanno i competitor nel frattempo. Congelare i requisiti per dodici mesi in un piano iniziale è una finzione: lo sanno tutti, ma solo Agile lo ammette esplicitamente. Come sintetizza BMC Software, il cuore dell’approccio è “rispondere al cambiamento piuttosto che seguire un piano” e privilegiare “la collaborazione con il cliente rispetto alla negoziazione del contratto”.

Personalmente, trovo che il punto più sottovalutato di Agile non sia la flessibilità in sé, ma la cultura di accountability che impone: ogni sprint finisce con qualcosa di dimostrabile. Non documentazione, non slide. Software funzionante, come ricorda BMC. Questo cambia il tipo di conversazione con il cliente, nel bene e nel male.

Il caso dei progetti ibridi

La dicotomia waterfall vs agile nella pratica è meno netta di quanto sembri sui libri. Molti progetti reali non sono puramente l’uno o l’altro.

Un’azienda farmaceutica che sviluppa un software di gestione dei trial clinici, per esempio, deve rispettare i requisiti normativi della validazione FDA (rigidi, documentati, sequenziali) ma gestisce anche la UX dello strumento in modo iterativo, coinvolgendo i ricercatori sprint dopo sprint. Waterfall per la compliance, Agile per il prodotto. Non è una contraddizione: è ingegneria.

Ma attenzione. L’approccio ibrido non è un alibi per non scegliere. Ho visto team chiamare “ibrido” quello che era semplicemente caos: riunioni Scrum senza backlog pulito, documentazione Waterfall incompleta, nessuna delle due metodologie applicata con coerenza. Il risultato è quasi sempre peggio di entrambe le alternative prese singolarmente.

Quindi, in soldoni: usa Waterfall quando il progetto ha un confine chiaro e cambiare costa caro. Usa Agile quando il confine è mobile e scoprire presto vale più che pianificare tutto. E se hai bisogno di entrambi, definisci con precisione quali parti del progetto seguono quale approccio. Senza quella chiarezza, l’ibrido non funziona.

Approccio sequenziale vs iterativo: quale impatto sulla carriera del Project Manager?

Padroneggiare Waterfall e Agile significa coprire l’intero spettro delle metodologie richieste dal mercato del project management. Non è una questione di preferenze personali o di moda: sono due logiche di lavoro profondamente diverse, radicate in decenni di storia. Il modello Waterfall si è standardizzato già negli anni ’70, derivando dall’ingegneria dei sistemi, e poggia su fasi sequenziali rigide: requisiti, progettazione, implementazione, verifica, manutenzione. Agile è arrivato dopo, ma non per caso: il Manifesto Agile del 11 febbraio 2001 ha formalizzato 4 valori cardine in risposta diretta ai limiti del sequenziale, spostando il baricentro dal contratto alla collaborazione, dalla documentazione al software funzionante, dal piano fisso alla risposta al cambiamento.

Sono due strumenti. E un PM che ne padroneggia uno solo è, a conti fatti, a metà.

Competenze richieste in ciascun approccio

Chi lavora con Waterfall deve essere bravo a costruire piani solidi prima che il progetto parta. La fase di raccolta dei requisiti è critica: una volta approvata, ogni modifica ha un costo alto. Ogni fase deve essere completata e validata prima che inizi la successiva, il che richiede capacità di analisi upfront, gestione della documentazione e controllo delle dipendenze. È un lavoro che premia la precisione metodica e la gestione del rischio strutturata.

Agile richiede un set di competenze diverso, non inferiore. Serve familiarità con i cicli iterativi brevi, con la gestione del backlog, con la facilitazione di cerimonie come sprint planning, retrospettive e daily standup. Ma soprattutto serve una mentalità: Agile è costruito per ambienti dove i requisiti cambiano e la validazione precoce conta più di un piano elaborato a tavolino. Nei miei anni di formazione con Project Manager in transizione ho visto che il blocco più comune non è tecnico, è culturale: smettere di voler pianificare tutto all’inizio.

Quindi le competenze non sono alternative. Si sommano.

Certificazioni allineate: PMP, PRINCE2, PSM I

PMP e PRINCE2 coprono entrambi gli approcci, ma con un’impostazione prevalentemente predittiva. Il PMP, rilasciato dal PMI, ha integrato Agile nel suo framework da alcuni anni, e l’esame attuale include domande su contesti ibridi e adattativi. Ma la struttura concettuale di base resta quella di un PM che governa scope, tempi e costi con logica sequenziale. PRINCE2 segue una logica simile: processi definiti, ruoli chiari, documentazione strutturata.

PSM I (Professional Scrum Master) e le certificazioni Scrum in generale sono invece pensate esclusivamente per contesti Agile. Scrum.org, che rilascia il PSM I, lavora su un framework leggero: sprint, backlog, tre ruoli, cinque eventi. Niente di più. È uno strumento potente, ma verticale.

Ma attenzione: il mercato del lavoro senior non cerca uno specialista verticale. Cerca qualcuno che sappia muoversi su entrambi i piani.

Un PM con doppia competenza, predittiva e iterativa, accede a ruoli che i profili mono-metodologici non possono coprire: Program Manager, PMO Lead, Delivery Lead in contesti ibridi. Questi ruoli esistono perché la maggior parte delle organizzazioni reali non è né tutta Waterfall né tutta Agile. Hanno reparti IT che lavorano in sprint e divisioni operations che gestiscono progetti con Gantt e milestone rigide. Servono persone che parlino entrambe le lingue.

Il profilo full-stack metodologico, a mio avviso, è oggi il più richiesto nelle posizioni senior. Non perché sia “meglio” in assoluto, ma perché risolve un problema concreto: la frammentazione interna alle organizzazioni. Chi porta solo Scrum tende a forzare il framework dove non si adatta; chi conosce solo Waterfall fatica nei contesti dove i requisiti sono fluidi e il cliente vuole visibilità continua. Chi conosce entrambi, invece, sceglie. E scegliere, per un Project Manager, è la competenza più rara.

Come allenare entrambi gli approcci con un percorso strutturato?

Un percorso strutturato è il modo più efficiente per imparare a usare Waterfall e Agile nello stesso progetto senza confusioni metodologiche. Non si tratta di scegliere una volta per tutte: si tratta di capire quando applicare le 5 fasi sequenziali di Waterfall (Requirements, Design, Implementation, Verification, Maintenance, ricorrenti sia nel PMBOK che in ISO 21502) e quando passare ai cicli iterativi di Agile, formalmente codificato nel 2001 con un manifesto che ruota attorno a 4 valori e 12 principi. Saperli alternare è la competenza che il mercato cerca.

Studio autodidatta vs corso strutturato

Lo studio autodidatta funziona. Ma ha un costo nascosto: il tempo.

Se hai disciplina ferrea e una finestra di 12-18 mesi, puoi costruire una preparazione solida su entrambi gli approcci partendo da zero. Leggi il PMBOK per Waterfall, studi il Manifesto Agile su agilemanifesto.org, segui le guide ufficiali di PMI e Scrum.org. È fattibile. Però ho visto decine di candidati che si perdono esattamente a metà percorso, quando la mole di materiale diventa ingestibile e non c’è nessuno che dica loro cosa conta davvero per l’esame e cosa è teoria accessoria.

Il problema più sottile è un altro. Studiare Waterfall e Agile in modo separato, ciascuno con le sue fonti, crea una dicotomia mentale che poi si paga cara nelle domande situazionali d’esame. Il PMP dal 2021 mescola scenari predittivi e adattativi nella stessa prova. Chi ha studiato i due metodi come compartimenti stagni tende a bloccarsi su certi casi ibridi che non rientrano in nessuno dei due schemi che ha memorizzato.

Un corso strutturato comprime questo percorso. Non perché semplifichi i contenuti, ma perché li sequenzia in modo che Waterfall e Agile si parlino dall’inizio, con simulazioni d’esame che rispecchiano il formato reale e casi pratici che forzano il candidato a ragionare sui confini tra i due approcci invece di tenerli separati.

Tutto sommato, la differenza non è tra chi studia tanto e chi studia poco. È tra chi allena il ragionamento situazionale e chi accumula nozioni.

Cosa offre Management Academy

I percorsi di Management Academy coprono Waterfall e Agile in modo integrato, non come due cataloghi paralleli.

Sul versante predittivo ci sono i corsi per PMP e PRINCE2, che insegnano a gestire progetti con requisiti stabili e alto costo del cambiamento, esattamente il contesto in cui Waterfall dà il meglio. Sul versante adattivo ci sono i percorsi dedicati a Scrum e PSM I, costruiti sui 4 valori del Manifesto Agile: individui e interazioni, software funzionante, collaborazione col cliente, risposta al cambiamento. Ma la parte che fa la differenza è come i due mondi vengono messi in relazione durante la formazione.

L’allenamento su casi reali è il fattore che separa chi passa l’esame da chi lo rimanda. Non è una frase fatta. Le simulazioni d’esame di Management Academy replicano la struttura delle domande situazionali del PMP e le domande di scenario dello PSM I, quelle in cui devi decidere quale approccio usare e perché, non semplicemente definire un termine. Personalmente, a mio avviso, è proprio su queste domande che si vince o si perde una certificazione ibrida nel 2025.

E poi c’è un aspetto pratico che spesso viene ignorato. Un percorso strutturato ti dà anche una sequenza di studio difendibile: prima i fondamentali metodologici, poi i framework specifici, poi i casi applicati. Chi studia da solo spesso inverte quest’ordine, parte dai framework e torna ai fondamentali solo quando si accorge di non capire le domande d’esame. A quel punto ha già bruciato mesi.

Domande frequenti su Waterfall vs Agile

Le domande più frequenti su Waterfall vs Agile riguardano l’attualità del modello a cascata, l’applicabilità di Agile fuori dall’IT e la coesistenza dei due approcci. Sono domande legittime, perché i due modelli hanno storie diverse e rispondono a logiche diverse: Waterfall è stato popolarizzato nel 1970 come modello sequenziale, mentre Agile è stato formalizzato nel 2001 con l’Agile Manifesto. Trent’anni di differenza che, a conti fatti, si sentono ancora oggi.

Waterfall è obsoleto nel 2026?

No. E chi lo dice non conosce i settori in cui lavora davvero.

Waterfall resta lo standard ogni volta che i requisiti sono stabili e il costo di un cambiamento in corsa è alto. Costruire un ospedale, sviluppare un dispositivo medico certificato, realizzare un impianto industriale: in questi contesti non si fa uno “sprint” e si aspetta il feedback. Ogni fase, dai requisiti al design all’implementazione, deve essere completata e approvata prima di passare a quella successiva, come spiega Adobe. La sequenzialità non è un difetto. È una garanzia.

Nei miei anni di formazione su questi temi ho visto molti project manager di settori regolamentati sentirsi in colpa per non usare Agile, come se Waterfall fosse una vergogna. Non lo è. È uno strumento. Usarlo bene è il punto.

Agile funziona per progetti non software?

Funziona. Anzi, in certi contesti non-IT funziona meglio che nell’IT stesso.

Il marketing è l’esempio più ovvio: campagne lanciate in sprint settimanali, A/B test continui, pivot rapidi basati sui dati. Ma anche l’HR lo usa per riprogettare processi di selezione, e i team di R&D lo applicano per gestire la ricerca esplorativa, dove per definizione i requisiti cambiano mentre si lavora. Il PMI ricorda che Agile nasce dal pensiero Lean, che ha radici manifatturiere giapponesi, non informatiche. Quindi no, non è “roba da sviluppatori”.

La vera domanda da porsi è un’altra: nel tuo progetto i requisiti cambieranno? E la validazione anticipata conta più di un piano rigido? Se la risposta è sì, Agile ha senso. Se no, probabilmente no.

Si possono usare Waterfall e Agile nello stesso progetto?

Sì, ed è quello che fa la maggior parte delle organizzazioni mature.

I modelli ibridi, come Disciplined Agile, combinano fasi predittive tipiche di Waterfall con sprint iterativi tipici di Agile. In pratica: si pianifica l’architettura generale in modo sequenziale, si eseguono le singole componenti in cicli brevi, si rilascia per incrementi. Ma è una scelta che va costruita sul contesto specifico, non copiata da un framework alla moda.

Però attenzione: un ibrido mal progettato è peggio dei due approcci separati. Ho visto team che chiamavano “ibrido” quello che era semplicemente disorganizzazione con un nome più presentabile. La coesistenza funziona quando c’è chiarezza su quale parte del progetto segue quale modello, con confini espliciti e responsabilità definite.

Quale certificazione scegliere tra PMP, PRINCE2 e PSM I?

Dipende da due cose sole: il contesto aziendale in cui lavori e il ruolo che vuoi coprire.

Il PMP (Project Management Professional del PMI) è la certificazione più riconosciuta a livello globale e copre sia approcci predittivi che Agile. È la scelta giusta se gestisci o vuoi gestire progetti complessi in contesti internazionali, indipendentemente dal settore. PRINCE2 è molto diffuso nel settore pubblico europeo e nelle grandi organizzazioni strutturate, soprattutto nel Regno Unito e in Italia nei contesti istituzionali. PSM I (Professional Scrum Master di Scrum.org) è specifica per chi vuole operare come Scrum Master o lavorare in team Agile con un focus pratico sullo Scrum framework.

A mio avviso, per chi parte da zero e vuole massima spendibilità sul mercato, il PMP è ancora la scelta più solida. Non perché le altre siano peggio, ma perché copre un territorio più ampio e forza a capire entrambi gli approcci, waterfall e agile, senza escluderne nessuno.

Tutto sommato, la scelta della certificazione non è una questione di quale sia “la migliore in assoluto”. È una questione di dove vuoi arrivare e in quale tipo di organizzazione. Fai prima il punto su quello, poi scegli.