Agile nel 2026: guida pratica al metodo, ruoli e ROI

Cos’è Agile e perché domina il project management nel 2026

Agile è una filosofia di gestione dei progetti basata su sviluppo iterativo e incrementale, in cui grandi progetti complessi vengono scomposti in parti più piccole sviluppate, testate e rilasciate frequentemente. Non è un metodo da seguire passo passo. È prima di tutto una mentalità: un modo di stare davanti all’incertezza senza fingere di avere tutte le risposte.

E questa distinzione non è retorica. Agile Alliance lo chiarisce senza ambiguità: Agile guida come creare e rispondere al cambiamento, come gestire ciò che non si può prevedere. Chi lo confonde con un semplice processo a sprint, in soldoni, ha già perso metà del punto.

Le origini: dal paper di Takeuchi e Nonaka al Manifesto

Tutto inizia nel 1986. Hirotaka Takeuchi e Ikujiro Nonaka pubblicano su Harvard Business Review un articolo intitolato “The New New Product Development Game”. Non parlano di software. Parlano di rugby. Descrivono come certi team ad alte prestazioni si passano la palla in modo fluido, adattandosi al campo, senza che ogni singolo gesto sia pianificato dall’alto.

Quella metafora colpisce Jeff Sutherland, che nel 1993, insieme a John Scumniotales e Jeff McKenna presso la Easel Corporation, la trasforma in qualcosa di pratico. Due anni dopo, nel 1995, Ken Schwaber presenta al mondo “The Scrum Development Process” alla conferenza OOPSLA di Austin, Texas. Ma Scrum è un’altra storia. Agile come filosofia formale arriva più tardi.

Nel febbraio 2001, diciassette esperti di sviluppo software si riuniscono a Snowbird, Utah. Vedono lo stesso problema da angolazioni diverse: i processi dominanti sono pesanti, rigidi, sommersi di documentazione. Il risultato di quell’incontro sono 4 valori e 12 principi raccolti nel Manifesto Agile. Quei 17 firmatari non stavano lanciando un brand. Stavano cercando un terreno comune.

Nei miei anni di formazione su questi temi ho visto che quasi tutti i candidati conoscono il Manifesto a memoria, ma pochissimi capiscono davvero il contesto storico che lo ha generato. Eppure è lì che si trova la logica.

I 4 valori e i 12 principi del Manifesto Agile

I 4 valori non eliminano processi, strumenti, documentazione o contratti. Li spostano in secondo piano rispetto a qualcosa di più utile. Individui e interazioni prima dei processi. Software funzionante prima della documentazione esaustiva. Collaborazione col cliente prima della negoziazione contrattuale. Rispondere al cambiamento prima di seguire un piano.

Ma attenzione: “prima” non significa “invece di”. Questo è l’errore che vedo più spesso. Il Manifesto non dice di buttare la documentazione. Dice che, quando le due cose entrano in conflitto, sai già da che parte stare.

I 12 principi traducono quei valori in comportamenti concreti. Consegnare software funzionante con frequenza, anche ogni settimana. Accogliere i requisiti che cambiano, anche tardi nel processo. Costruire progetti attorno a persone motivate. Misurare il progresso con software che funziona davvero, non con slide o gantt.

A mio avviso il principio più sottovalutato è il quattordicesimo: l’attenzione continua all’eccellenza tecnica. Perché senza qualità nel codice, o nella consegna, il ritmo sostenibile che Agile promette diventa solo un modo per accumulare debito tecnico più in fretta.

Nato in ambito software, Agile oggi viene applicato in settori che sembrano distanti anni luce da una sprint review. Farmaceutico, moda, hardware, marketing. La struttura iterativa funziona ovunque si lavori con incertezza alta e feedback disponibili. Però, e questo conta, non funziona uguale dappertutto. Applicare Agile a catena di montaggio o a costruzioni civili senza adattarlo è un errore che costa.

Alla fine della fiera, Agile domina il project management nel 2026 non perché è diventato uno standard imposto, ma perché risponde a qualcosa di reale: i mercati cambiano più in fretta dei piani. E un metodo che lo nega, per quanto ordinato, è già in ritardo.

Perché molti team falliscono nell’adottare Agile?

Il problema più comune è che molte aziende scambiano Agile per un insieme di cerimonie, perdendo di vista il principio fondante: consegnare valore misurabile in cicli brevi. Si organizzano daily stand-up, si aprono board Kanban, si rinominano i project manager “Scrum Master”. E poi ci si chiede perché niente cambia davvero. La risposta, a conti fatti, è quasi sempre la stessa: si è adottato il vestito di Agile senza cambiare il modo di pensare.

I sintomi di un’adozione superficiale

Il primo segnale è il busy work senza valore. Riunioni che si moltiplicano, backlog che crescono a dismisura, sprint che si chiudono con deliverable che nessuno usa. Tutto questo movimento dà l’impressione di produttività. Ma non lo è.

Il secondo sintomo è l’ossessione per la velocity. Misurare quanti punti storia si completano per sprint non è sbagliato in assoluto, ma diventa un problema quando diventa l’unico metro di giudizio del lavoro di un team. I trainer di Scrum.org Todd Miller e Ryan Ripley, nel format Scrum Myth or Fact, lo dicono esplicitamente: l’idea che la velocity sia la misura principale di successo per un team Scrum è un mito. Il successo si misura sul valore consegnato, non sulla velocità con cui si spostano i ticket da una colonna all’altra.

Nei team che ho seguito negli ultimi anni, questo errore è quasi sistematico. Si ottimizza per la metrica più facile da misurare, non per quella più importante. E il cliente, alla fine, si accorge sempre della differenza.

Terzo sintomo: la mancanza di retrospettiva reale. In Scrum, ogni sprint prevede un momento di riflessione su come migliorare il processo, non solo sul cosa è stato fatto. Quando le retrospettive diventano rituali formali di 30 minuti in cui nessuno dice niente di utile, il framework è già svuotato dall’interno.

Confusione tra filosofia e framework

Agile non è Scrum. Questa distinzione sembra ovvia, ma nella pratica viene ignorata con una frequenza sorprendente.

Agile è prima di tutto una mentalità. L’Agile Alliance lo definisce come «la capacità di creare e rispondere al cambiamento», un orientamento che informa ogni decisione del team, non un insieme di regole da seguire. Scrum, invece, è uno dei framework concreti che rendono quella mentalità azionabile: iterazioni time-boxed chiamate sprint, ruoli definiti, artefatti precisi, eventi regolari per ispezionare e adattare.

Ma ecco il punto, e a mio avviso è quello che fa la differenza tra un’adozione riuscita e una fallimentare: puoi applicare Scrum alla lettera e non essere minimamente Agile. Puoi fare ogni cerimonia prevista dalla Scrum Guide con precisione chirurgica e consegnare lo stesso software inutile di prima, solo in pacchetti più piccoli.

La confusione nasce perché i framework sono visibili e insegnabili. La mentalità no. Si può certificare uno Scrum Master in due giorni. Non si può certificare la capacità di un’organizzazione di rispondere davvero al cambiamento, di cambiare rotta quando i dati lo dicono, di mettere il cliente davanti ai processi interni.

Quindi quando un team dice “abbiamo adottato Agile” e poi mostra sprint rigidi come waterfall ritagliati in trenta giorni, documentazione pesante riconfezionata come backlog items, gerarchia decisionale invariata con un nuovo vocabolario sovrapposto, quello non è Agile. È teatro Agile. E il teatro costa tempo, costa denaro e, soprattutto, costa fiducia.

Il Manifesto Agile, scritto nel 2001 da 17 esperti come alternativa ai processi guidati dalla documentazione, contiene 4 valori e 12 principi. Nessuno di essi parla di stand-up, di board o di velocity. Parlano di individui, interazioni, software funzionante, collaborazione col cliente, risposta al cambiamento. Anzi, il primo valore mette esplicitamente gli individui e le interazioni sopra i processi e gli strumenti. Dimenticare questo è il modo più rapido per trasformare un’adozione Agile in un progetto fallito con un nome nuovo.

Qual è la differenza tra Agile e Scrum?

La principale differenza tra Agile e Scrum è che Agile è una filosofia di project management ampia, mentre Scrum è un framework specifico e leggero che rende l’approccio Agile praticabile nella quotidianità. In soldoni: puoi essere Agile senza usare Scrum, ma non puoi usare Scrum senza essere Agile. Questa distinzione sembra sottile. Non lo è.

Agile come filosofia

Agile è prima di tutto una mentalità. L’Agile Alliance lo dice esplicitamente: Agile è un insieme di valori e principi che guidano come creare, rispondere al cambiamento e gestire l’incertezza. La radice storica è il Manifesto Agile del 2001, firmato da 17 esperti dello sviluppo software che cercavano un’alternativa ai processi pesanti e guidati dalla documentazione allora dominanti. Quattro valori, dodici principi. Tutto lì.

Non è un processo. Non ha sprint, cerimonie o ruoli definiti. È un orientamento: consegna continua, collaborazione con il cliente, risposta al cambiamento. Come lo realizzi concretamente dipende dal framework che scegli.

Tra i candidati ajail che ho seguito negli ultimi anni, la confusione più comune è proprio questa: studiare Agile aspettandosi istruzioni operative e trovare invece principi astratti. È frustrante finché non si capisce che quella astrazione è intenzionale. Agile non ti dice come fare il tuo lavoro, ti dice perché farlo in un certo modo.

Scrum come framework

Scrum è la risposta alla domanda “ma concretamente, come si fa?”. È un framework strutturato, con ruoli precisi (Product Owner, Scrum Master, team di sviluppo), eventi fissi (sprint, daily, review, retrospettiva) e artefatti definiti (product backlog, sprint backlog, incremento). Come sottolinea la Northeastern University, Agile è la filosofia o l’orientamento, Scrum è la metodologia specifica che la rende operativa.

La storia è più lunga di quanto molti pensino. Il concetto nasce da un articolo del 1986 di Takeuchi e Nonaka su Harvard Business Review, che paragonava i processi creativi allo sport del rugby. Nel 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna applicarono quelle idee per la prima volta ai team software presso la Easel Corporation. Due anni dopo, nel 1995, Ken Schwaber presentò ufficialmente il framework con il paper The Scrum Development Process alla conferenza OOPSLA di Austin, Texas.

Ma Scrum è diventato davvero uno standard solo nel 2010, quando Schwaber e Jeff Sutherland pubblicarono la prima Scrum Guide ufficiale, aggiornata poi nel 2011, 2013, 2016, 2017 e 2020. Quel documento minimalista, poche decine di pagine, definisce ruoli, eventi e artefatti nel modo più essenziale possibile. Nel framework Scrum il lavoro si suddivide in iterazioni time-boxed chiamate sprint, durante le quali i team consegnano incrementi di prodotto potenzialmente rilasciabili e riflettono su come migliorare nella retrospettiva successiva.

Una precisazione che vale la pena fare: il successo in Scrum non si misura sulla velocità (velocity) del team. I trainer Todd Miller e Ryan Ripley di Scrum.org lo definiscono un mito diffuso. La metrica che conta è il valore consegnato, non la quantità di lavoro completato per sprint. Anzi, ossessionarsi sulla velocity è uno dei modi più efficaci per sabotare un team Scrum.

Quando scegliere Scrum, Kanban o approcci ibridi

Scrum non è l’unico framework Agile. Esistono Kanban, Extreme Programming (XP), SAFe per la scala enterprise, e varie combinazioni ibride. La scelta dipende dal contesto, non da una gerarchia di valore.

Scrum funziona bene quando il lavoro è iterativo, i requisiti cambiano spesso e il team può operare in modo autonomo su sprint di durata fissa. Una differenza chiave tra Agile e Scrum è che Agile punta sulla consegna continua in senso generale, mentre Scrum enfatizza il miglioramento continuo all’interno di cicli definiti. Quindi: se ti serve struttura e cadenza regolare, Scrum è probabilmente la scelta più solida.

Kanban, invece, è più adatto a flussi di lavoro continui dove le priorità cambiano quasi ogni giorno, senza la possibilità di bloccare un backlog per due settimane. Non ha sprint, non ha ruoli fissi, lavora sulla limitazione del lavoro in corso (WIP). È più flessibile, ma richiede una disciplina diversa.

Gli approcci ibridi, tipo Scrumban, mischiano elementi dei due. A mio avviso, però, i team che adottano ibridi prima di aver capito bene uno dei due framework rischiano di prendere il peggio da entrambi: la rigidità di Scrum senza la struttura degli sprint, la fluidità di Kanban senza la visibilità sul flusso. Prima si impara un framework per intero. Poi, se serve, si adatta.

Tutto sommato, la scelta tra Scrum, Kanban e approcci ibridi non è una questione filosofica. È una questione di come lavora il tuo team, quanto cambiano i requisiti e quanto controllo hai sulla pianificazione. Capire la differenza tra Agile come orientamento e Scrum come strumento operativo è il primo passo per rispondere a quella domanda in modo onesto.

Come funziona Agile nella pratica quotidiana di un team?

Un team Agile opera in cicli brevi e ripetuti: pianifica un incremento, lo sviluppa, lo consegna, raccoglie feedback e adatta il piano successivo sulla base di ciò che ha imparato. Non è una metafora. È la struttura concreta della giornata lavorativa, settimana dopo settimana, sprint dopo sprint. Agile, come sottolinea la stessa Agile Alliance, è prima di tutto una mentalità: i valori e i principi del Manifesto guidano come un team gestisce l’incertezza e risponde al cambiamento, non solo come consegna software.

Iterazioni, sprint e incrementi

Lo sprint è l’unità base del lavoro in Scrum. Un periodo definito, solitamente da una a quattro settimane, dentro il quale il team prende un sottoinsieme di obiettivi, li lavora e produce qualcosa di funzionante. Qualcosa che potrebbe essere rilasciato. Non un documento di analisi, non una bozza: un incremento reale di prodotto.

Nei miei anni di formazione su questi framework ho visto squadre che faticavano proprio qui, all’inizio. L’idea che ogni sprint debba terminare con un pezzo di prodotto potenzialmente consegnabile al cliente sembra ovvia sulla carta, ma cambia completamente la logica di prioritizzazione. Si finisce per fare prima le cose che contano di più, non quelle tecnicamente più comode. Come riportato da Atlassian, nel framework Scrum il lavoro è suddiviso in sprint time-boxed con incrementi potenzialmente rilasciabili: questa definizione, semplice nella forma, ha conseguenze enormi nel modo in cui un team si organizza ogni mattina.

Ma attenzione a una cosa. La velocity, cioè quante unità di lavoro si completano per sprint, è spesso usata come metro di successo principale. È un mito, come spiegano Todd Miller e Ryan Ripley di Scrum.org: il vero successo si misura sul valore consegnato al cliente, non sulla velocità del team. In soldoni, correre forte nella direzione sbagliata non serve a nessuno.

Ruoli, eventi e artefatti

Scrum ha una struttura volutamente leggera. Tre ruoli: Product Owner, Scrum Master, team di sviluppo. Cinque eventi: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Tre artefatti: Product Backlog, Sprint Backlog, Incremento. Tutto qui.

La prima Scrum Guide ufficiale è stata pubblicata nel 2010 da Ken Schwaber e Jeff Sutherland, e da allora è stata aggiornata nel 2011, 2013, 2016, 2017 e 2020 (fonte: agile42.com). Ogni revisione ha cercato di alleggerire, non di aggiungere. La versione 2020 è la più snella di tutte: 13 pagine. Non è una guida procedurale, è un framework minimalista che i team adattano al proprio contesto.

La Scrum Alliance, fondata nel 2002 da Mike Cohn, Esther Derby e Ken Schwaber, ha poi introdotto il curriculum Certified Scrum Master per diffondere queste pratiche su scala globale. E ci è riuscita: oggi il CSM è una delle certificazioni Agile più diffuse al mondo. Però, a mio avviso, ottenere un certificato senza capire il perché dietro ogni evento Scrum produce esattamente il tipo di team meccanico e burocratico che Agile voleva eliminare.

Il ciclo feedback-ispezione-adattamento

Alla fine di ogni sprint c’è la Sprint Review. Il team mostra ciò che ha costruito. Il cliente o il Product Owner reagisce. E quella reazione alimenta il backlog del prossimo ciclo. Non è un collaudo formale. È una conversazione sul valore.

Poi c’è la Retrospective, che molti team sottovalutano o, peggio, saltano quando sono sotto pressione. È l’evento in cui il team guarda se stesso: cosa ha funzionato, cosa no, cosa cambiare nel prossimo sprint. La differenza chiave tra Agile in generale e Scrum in particolare sta proprio qui: Agile punta alla consegna continua, Scrum enfatizza il miglioramento continuo dentro cicli definiti, come evidenzia Agile Sherpas. Non è la stessa cosa.

Quindi il ciclo non è lineare. È ricorsivo. Ogni giro insegna qualcosa che cambia il giro successivo. Tra i team che ho seguito nel tempo, quelli che crescevano davvero erano quelli che usavano la Retrospective per prendere una decisione concreta, anche piccola, da applicare subito. Non per lamentarsi del processo. Alla fine della fiera, Agile funziona perché tratta l’incertezza come un dato di partenza, non come un problema da risolvere prima di cominciare.

Quanto ROI genera davvero un progetto Agile?

Il ROI di un progetto Agile non si misura a fine progetto, ma a ogni iterazione: ogni incremento rilasciato deve produrre un valore tangibile per gli stakeholder. Questo è il punto che distingue Agile da quasi ogni altro approccio di project management. Non si aspetta il collaudo finale per capire se i soldi erano ben spesi. Si verifica già al secondo sprint.

ROI precoce attraverso la consegna iterativa

Il PMI lo dice esplicitamente: l’obiettivo di Agile è creare un ROI precoce e misurabile attraverso la consegna iterativa. Non è una promessa di marketing. È la logica strutturale del framework: lavoro scomposto in incrementi potenzialmente rilasciabili, feedback del cliente raccolto rapidamente e spesso, cicli brevi che espongono gli errori prima che diventino costosi.

Nei miei anni di formazione su questi temi ho visto decine di team che, arrivati al terzo sprint, avevano già identificato un requisito sbagliato che in un progetto waterfall sarebbe emerso sei mesi dopo. A conti fatti, quel singolo ciclo di feedback aveva giustificato da solo l’intero investimento nella transizione Agile.

E qui sta il punto centrale: scomporre il lavoro in parti piccole non è solo una tecnica organizzativa. È un meccanismo di riduzione del rischio finanziario. Ogni sprint è un punto di controllo. Se la direzione è sbagliata, si corregge subito, non dopo aver bruciato il budget.

Agile, come sottolineato da AgileSherpas, pone al centro la consegna di valore reale e scoraggia attivamente il cosiddetto “busy work”, cioè il lavoro che occupa ore ma non produce niente di utile per chi ha commissionato il progetto. Questa è una scelta di sistema, non un dettaglio implementativo.

Come misurare il valore consegnato

La velocity è un mito. O meglio: è utile internamente, come indicatore di pianificazione, ma non è la misura giusta per valutare il successo di un team.

Todd Miller e Ryan Ripley, trainer certificati di Scrum.org, lo hanno detto esplicitamente nel format “Scrum Myth or Fact”: l’idea che la misura più importante di successo sia l’aumento della velocity è un mito. Il successo si valuta sul valore consegnato, non sulla velocità con cui il team chiude i ticket. Un team che chiude venti story point a sprint consegnando funzionalità che nessuno usa non sta generando ROI. Sta solo bruciando ore.

Quindi come si misura il valore in modo concreto? Tre domande che pongo sempre ai team:

• Questa funzionalità è in produzione e viene usata? Se la risposta è no, la story era davvero “done”?
• Il cliente ha cambiato comportamento grazie all’incremento rilasciato? Questo è l’unico segnale che conta.
• Il costo del ciclo è inferiore al valore generato? Se non sai rispondere, il progetto non ha un KPI misurabile.

Personalmente trovo che molti team Agile, anche quelli strutturati bene dal punto di vista tecnico, continuino a monitorare la velocity per abitudine o per rassicurare il management. Ma presentare uno sprint review con “abbiamo consegnato 34 punti” senza collegarlo a un impatto misurabile sugli stakeholder è esattamente il tipo di rendicontazione che Agile doveva eliminare.

Il KPI corretto è il valore consegnato. Tutto il resto è contorno.

Studio autodidatta vs corso strutturato: quale percorso porta alla certificazione Agile?

Hai due strade per padroneggiare Agile: studio autodidatta sui materiali ufficiali gratuiti, oppure percorso strutturato con docente, simulazioni e certificazione finale riconosciuta. La scelta non è banale, perché le due strade portano a destinazioni diverse, non solo a velocità diverse.

Il Manifesto Agile esiste dal 2001, firmato da 17 esperti che volevano un’alternativa ai processi di sviluppo appesantiti dalla documentazione. È disponibile oggi in oltre 60 lingue su agilemanifesto.org. La Scrum Guide ufficiale, scritta da Ken Schwaber e Jeff Sutherland, è gratuita dal 2010 e scaricabile direttamente da scrum.org. Aggiornata nel 2011, 2013, 2016, 2017 e infine nel 2020, è il testo di riferimento assoluto. Tutto questo, senza spendere un euro.

E allora perché non tutti i team Agile funzionano?

Limiti dell’autoformazione sul lungo periodo

Leggere quattro valori e dodici principi è un punto di partenza, non un traguardo. L’Agile Alliance sottolinea che Agile è prima di tutto una mentalità, non un manuale di istruzioni. E le mentalità non si assorbono leggendo un PDF.

Il problema con l’autoformazione non è l’accesso ai materiali. È la mancanza di un contesto in cui applicarli. Nei miei anni di formazione nel settore ho incrociato decine di professionisti che sapevano citare a memoria i quattro valori del Manifesto, ma non riuscivano a condurre uno sprint review senza trasformarlo in una riunione di aggiornamento di stato. Conoscevano la teoria. Non avevano mai visto come si applica in una situazione reale, dove il cliente cambia idea a metà sprint e il team deve decidere cosa fare.

C’è poi un problema di distorsione cognitiva. Studiando da soli, si tende a confermare ciò che si crede già. Un esempio concreto: molti autodidatti convinti di padroneggiare Scrum misurano il successo del team sulla velocity. I trainer certificati di Scrum.org, Todd Miller e Ryan Ripley, hanno chiarito esplicitamente che questa è una credenza sbagliata: il successo si misura sul valore consegnato, non sulla velocità. Ma questa distinzione, in un percorso autodidatta, è facilissima da saltare.

Ma il limite più pesante, a conti fatti, è uno solo: senza certificazione riconosciuta, nessuno sa quanto hai studiato.

Cosa cambia con un percorso accreditato

Un percorso strutturato copre tre cose che l’autoformazione non può garantire: simulazioni d’esame calibrate, casi reali discussi con un docente esperto, e una certificazione finale che ha peso nei processi di selezione.

Il supporto del docente non è un dettaglio di comfort. È la differenza tra capire che Agile si concentra sulla consegna continua mentre Scrum enfatizza il miglioramento all’interno di sprint definiti, e capire quando questa distinzione conta davvero in un progetto reale. La teoria la puoi leggere ovunque. Qualcuno che ti chiede “ma in questo caso specifico, tu cosa faresti?” non lo trovi in un PDF.

Le simulazioni, poi, fanno un lavoro preciso: tolgono l’ansia da esame. Chi arriva a una certificazione Agile senza aver mai risposto a domande a tempo, in condizioni simili a quelle dell’esame vero, spesso si blocca su quesiti che in teoria sa rispondere. Non è una questione di intelligenza. È allenamento.

Personalmente, credo che la credibilità di una certificazione accreditata sia sottovalutata da chi è già dentro il settore e sopravvalutata da chi è fuori. La realtà è nel mezzo: in un colloquio per una posizione senior, due candidati con competenze simili vengono valutati anche su ciò che possono dimostrare con carta. La certificazione non sostituisce l’esperienza, però, nella prima scrematura dei CV, fa la differenza. Punto.

Scrum Alliance è nata nel 2002 proprio con questa missione: supportare il movimento Agile tramite formazione e comunità, introducendo curricula come il Certified Scrum Master. Da allora il mercato delle certificazioni è cresciuto, ma non tutte le certificazioni pesano allo stesso modo. Un percorso accreditato porta una firma riconoscibile, non solo un attestato da stampare.

In soldoni: i materiali gratuiti servono per capire di cosa si parla. Un percorso strutturato serve per dimostrare che sei in grado di farlo sul serio.

Quali certificazioni Agile portano avanzamento di carriera nel 2026?

Una certificazione Agile è un attestato rilasciato da enti riconosciuti (Scrum.org, Scrum Alliance, PMI) che valida competenze su framework, ruoli e pratiche del mondo Agile. Non è un titolo accademico, non è un corso da mettere nel cassetto. È una credenziale che i recruiter cercano attivamente quando aprono posizioni senior, e la differenza tra averla o non averla si vede subito, già alla prima selezione.

Scrum è oggi il framework Agile più diffuso al mondo, secondo i dati di Agilesherpas.com. Questo significa che le credenziali che ruotano intorno a Scrum, PSM I e CSM su tutte, sono quelle che aprono il maggior numero di porte. Ma il punto non è solo la popolarità del framework: è che certi ruoli, come Agile Coach, Product Owner senior o Scrum Master su programmi complessi, restano semplicemente chiusi a chi non ha una credenziale formale. Non è una questione di skill reali, è una questione di filtri.

PSM I di Scrum.org

Il Professional Scrum Master I (PSM I) è l’esame di Scrum.org, l’organizzazione fondata da Ken Schwaber, uno dei due autori della Scrum Guide originale. La Scrum Guide stessa è stata pubblicata per la prima volta nel 2010 e aggiornata più volte, l’ultima nel 2020, per mantenere Scrum minimale e adattabile.

Il PSM I valuta la comprensione profonda del framework: ruoli, eventi, artefatti, e soprattutto il perché dietro ogni elemento. Non è un test nozionistico. Todd Miller e Ryan Ripley di Scrum.org, in uno dei loro interventi formativi, sottolineano che la velocity è un mito come misura principale del successo di un team Scrum: quello che conta è il valore consegnato. L’esame riflette esattamente questo tipo di ragionamento. Ti mette davanti a scenari reali e ti chiede di scegliere l’opzione più coerente con i valori Agile, non quella più ovvia.

Tra i candidati che ho seguito nel tempo, quelli che si preparano solo memorizzando definizioni di solito si fermano sotto il cut score. Quelli che capiscono perché gli sprint sono time-boxed, perché l’incremento deve essere potenzialmente rilasciabile a fine sprint, perché la retrospettiva non è facoltativa: quelli passano. E spesso al primo tentativo.

A conti fatti, il PSM I è la credenziale Agile con il miglior rapporto tra costo dell’esame, riconoscimento sul mercato e solidità dei contenuti.

Certified ScrumMaster di Scrum Alliance

La Scrum Alliance è stata fondata nel 2002 da Mike Cohn, Esther Derby e Ken Schwaber con la missione di supportare il movimento Agile attraverso formazione, comunità e ricerca. Fu proprio la Scrum Alliance a introdurre il curriculum Certified ScrumMaster (CSM), che è diventato nel tempo una delle credenziali Agile più riconoscibili in assoluto.

Il CSM ha una struttura diversa dal PSM I. Richiede la partecipazione obbligatoria a un corso con un trainer certificato, due giorni di formazione dal vivo o in modalità remota, prima di poter sostenere l’esame. Questo lo rende più costoso e meno flessibile come percorso, ma anche più diretto per chi parte da zero e ha bisogno di un contesto guidato. L’interazione con il trainer e con gli altri studenti è parte integrante dell’esperienza.

Ma c’è un elemento che pesa nella scelta: il CSM ha una scadenza e richiede rinnovo biennale con crediti formativi. Il PSM I no. Personalmente trovo che questo aspetto venga sottovalutato da chi inizia il percorso, poi diventa un costo ricorrente che non tutti mettono in conto.

Detto questo, il CSM ha una community attiva, eventi dedicati, e un riconoscimento forte soprattutto nelle aziende che hanno già adottato la Scrum Alliance come riferimento per la formazione interna. In certi settori, finanza e assicurazioni in Italia soprattutto, lo vedono ancora come il “bollino” di riferimento.

PMI-ACP e percorsi ibridi

Il PMI Agile Certified Practitioner (PMI-ACP) è una certificazione del Project Management Institute che copre un set di framework molto più ampio rispetto al solo Scrum: Kanban, XP (Extreme Programming), Lean e Scrum sono tutti inclusi nel corpo di conoscenza richiesto. Questo la rende diversa, per posizionamento e per pubblico.

Il PMI-ACP non è la certificazione giusta per chi vuole fare il Scrum Master su un singolo team. È invece la credenziale giusta per chi lavora in contesti ibridi, dove convivono più metodologie, o per chi ha già esperienza come project manager tradizionale e vuole aggiungere una dimensione Agile solida alla propria carriera. I prerequisiti riflettono questo: servono ore di esperienza documentata su progetti Agile, non solo la conoscenza teorica.

I percorsi ibridi, quindi PMI-ACP unito a una base Scrum già acquisita, sono quelli che aprono i ruoli più ampi: Agile Program Manager, Transformation Lead, Head of Delivery. Non è un caso che molte job description senior richiedano “conoscenza di più framework Agile” come requisito. Il PMI-ACP risponde esattamente a quella richiesta.

Quindi, in soldoni: PSM I per chi vuole entrare o consolidarsi nel ruolo di Scrum Master con una credenziale rigorosa e senza scadenza; CSM per chi preferisce un percorso strutturato con un trainer e una community di riferimento; PMI-ACP per chi punta a ruoli di coordinamento su programmi complessi o ambienti multi-framework. Tre strade diverse, tre profili diversi. La scelta dipende da dove sei adesso e dove vuoi arrivare, non da quale certificazione suona meglio sul curriculum.

Domande frequenti su Agile

Le domande più frequenti che riceviamo da Project Manager e Product Manager che si avvicinano per la prima volta al mondo Agile. Raccogliamo qui le risposte essenziali, quelle che tagliano la testa al toro senza perdersi in definizioni astratte.

Agile è una metodologia o un framework?

Agile è una mentalità. Non un framework, non uno strumento: una mentalità informata da valori e principi. Lo dice esplicitamente Agile Alliance: Agile è prima di tutto un modo di vedere il lavoro, costruito sui 4 valori e 12 principi del Manifesto firmato nel 2001 da 17 esperti. Framework come Scrum o Kanban sono strumenti concreti per mettere in pratica quella mentalità. Ma la mentalità viene prima.

Quanto tempo serve per imparare Agile?

Dipende da cosa intendi per “imparare”.

I concetti fondamentali del Manifesto Agile si leggono in meno di un’ora. Capire come funziona Scrum nella pratica, con sprint, retrospettive e incrementi consegnabili, richiede qualche settimana di studio strutturato. Ma applicarlo bene in un team reale è un’altra cosa: lì si impara soprattutto sbagliando, iterando, e riflettendo su cosa non ha funzionato. A mio avviso, i primi tre mesi in un team Scrum valgono più di qualsiasi libro letto in isolamento.

Agile funziona solo nello sviluppo software?

No. Il Manifesto Agile è nato nel 2001 nel contesto dello sviluppo software, ed è vero che Scrum è stato introdotto per la prima volta da Jeff Sutherland in un contesto tecnico, alla Easel Corporation nel 1993. Ma i principi sottostanti, consegna continua di valore, risposta al cambiamento, collaborazione con il cliente, si applicano con efficacia anche al marketing, alla gestione prodotto, alle operations, alla formazione. Oggi intere organizzazioni non-tech adottano approcci Agile con risultati documentati.

Però attenzione: trasferire un framework senza adattarlo al contesto produce quasi sempre frustrazione. Lo strumento va scelto in funzione del problema, non il contrario.

Qual è la differenza tra Scrum Master e Project Manager Agile?

Una differenza chiave è nell’orientamento del ruolo. Il Project Manager Agile ha responsabilità sul piano, sul budget, sugli stakeholder, sul rispetto degli obiettivi di progetto. Lo Scrum Master, invece, è un servant leader: il suo lavoro è rimuovere gli impedimenti del team, proteggere il processo Scrum e fare in modo che gli sprint producano valore reale. Non gestisce il team, lo serve.

E qui sta il punto che genera più confusione. Nei progetti tradizionali il PM concentra autorità e visione. In Scrum quella responsabilità è distribuita: al Product Owner per il “cosa”, al team di sviluppo per il “come”, allo Scrum Master per il “processo”. Tre ruoli distinti, tre set di competenze diversi.

Quale certificazione Agile scegliere per iniziare?

Scrum è il framework Agile più adottato al mondo, secondo i dati di agilesherpas.com. Per questo, a conti fatti, partire da una certificazione Scrum è la scelta più logica per chi vuole spendibilità immediata nel mercato del lavoro.

Tra i percorsi disponibili, quelli riconosciuti da PMI (come il PMI-ACP) o da Scrum Alliance (come il CSM, introdotto proprio dalla stessa organizzazione fondata da Ken Schwaber nel 2002) offrono una base solida. La scelta dipende dal tuo ruolo attuale: chi viene dal project management tradizionale spesso trova più naturale iniziare dal PMI-ACP, che integra Agile con una visione più ampia del project management. Chi parte da zero senza background PM tende a trovare più accessibile un percorso Scrum puro.

Ma la certificazione da sola non basta. Serve pratica. Serve un contesto in cui applicarla. E serve capire che Scrum, come ricordano i trainer Todd Miller e Ryan Ripley su Scrum.org, si misura sul valore consegnato, non sulla velocità del team. Un dato che cambia radicalmente il modo in cui si studia e ci si prepara.