Il tuo team ha appena trascorso sei mesi a realizzare esattamente ciò che il client aveva richiesto. La demo va alla perfezione. Poi arriva la frase: «Non è più quello di cui abbiamo bisogno. Il mercato è cambiato».
Ho visto questa situazione mandare all’aria progetti, budget e il morale del team più volte di quante ne possa contare.
Il problema non è che i requisiti cambino. Cambiano sempre. Il problema è creare processi che fingono che non cambino.
A un certo punto, i team di sviluppo software hanno compreso una cosa importante: e se smettessimo di opporci al cambiamento e iniziassimo invece ad aspettarcelo?
Ecco come diventare un PM “IA-native” →
Nel manuale di gestione dei progetti basato sull’IA troverai:
- 5 sistemi IA pronti all’uso per il tuo lavoro settimanale sui progetti
- 30 agenti mappati dall’inizio alla conclusione del progetto
- Flussi di lavoro multi-agente reali per aiutarti a progettare i tuoi.
Quel cambiamento di mentalità ha dato vita al project management agile.
Punti chiave
- La gestione agile crea valore attraverso cicli di sviluppo iterativi e brevi.
- I progetti agili superano di gran lunga gli approcci tradizionali di project management a cascata.
- Scrum, Kanban ed XP sono i principali framework per la gestione agile dei progetti.
- Un esito positivo dell’adozione dei metodi agili richiede autentici cambiamenti nella cultura organizzativa.
Che cos’è il project management agile?
La gestione agile dei progetti è un approccio iterativo che genera valore attraverso brevi cicli di lavoro chiamati sprint, della durata tipica compresa tra le due e le quattro settimane, in cui i team pianificano, eseguono, valutano e si adattano continuamente, anziché seguire un piano sequenziale rigido.
Invece di dedicare mesi alla realizzazione completa del prodotto prima di ricevere un feedback, i team rilasciano software funzionante ogni poche settimane e lo adattano in base a quanto appreso.
Questo risolve direttamente il problema che la maggior parte dei team deve affrontare a causa dei lunghi cicli di sviluppo che prevedono la consegna di Tutto in una volta sola, solo per scoprire che i requisiti sono cambiati mesi fa.
Il project management tradizionale con il modello a cascata definisce i requisiti all’inizio e procede attraverso fasi lineari, in cui ogni fase deve essere completata prima che possa iniziare quella successiva.
Il coinvolgimento del cliente avviene principalmente durante la fase iniziale di raccolta dei requisiti e quella finale di consegna, senza alcun risultato tangibile nel mezzo.
L’approccio agile ribalta completamente questa situazione. I clienti sono coinvolti durante l’intero ciclo di vita del progetto e vedono il software funzionante ad ogni sprint.
Teams accolgono con favore le modifiche ai requisiti anche nelle fasi avanzate dello sviluppo, considerandoli vantaggi competitivi anziché problemi costosi.
Questa metodologia mantiene l’attenzione sul valore per il cliente entro i vincoli di tempo e di costo stabiliti, facendo del cambiamento la norma piuttosto che l’eccezione.
Perché il project management agile è importante
Le organizzazioni che hanno ottenuto un esito positivo nella trasformazione agile registrano un aumento di circa il 30% in termini di efficienza, soddisfazione dei clienti e coinvolgimento dei dipendenti.
Quando sono passati a sprint di due settimane, hanno lanciato la loro prima funzionalità funzionante in quattro settimane e hanno modificato la direzione sulla base del feedback reale dei clienti. Quel cambiamento di rotta ha salvato la linea di prodotti.
Ho visto un cliente della Fortune 500 alle prese per nove mesi con la pianificazione a cascata prima di rendersi conto che il suo mercato era cambiato completamente.
Quando sono passati a sprint di due settimane, hanno lanciato la loro prima funzionalità funzionante in quattro settimane e hanno modificato la direzione sulla base del feedback reale dei clienti. Quel cambiamento di rotta ha salvato la linea di prodotti.
La ricerca dello Standish Group rivela che i progetti agili ottengono un esito positivo nel 42% dei casi, rispetto al solo 13% dei progetti waterfall. Nel contempo, i progetti waterfall falliscono nel 59% dei casi, contro solo l’11% dei progetti agili.
Non si tratta di differenze di poco conto. Rappresentano miglioramenti fondamentali nel modo in cui i team gestiscono l’incertezza e generano valore quando i requisiti cambiano.
Cerchi un modo semplice per gestire il tuo team Agile da un'unica piattaforma? Scarica qui gratis il modello di gestione Agile di ClickUp!
I principi fondamentali del project management agile per i progetti
Il Manifesto Agile ha definito nel 2001 quattro valori che ancora oggi guidano i team moderni. Non si tratta di una filosofia astratta, ma di priorità concrete che influenzano le decisioni quotidiane.
- Le persone e le interazioni contano più dei processi e degli strumenti: i teams danno priorità alla comunicazione diretta e alla collaborazione piuttosto che al rigido rispetto dei processi o all’uso di strumenti complessi
- Software funzionante piuttosto che documentazione esaustiva: l’attenzione si sposta sulla consegna di incrementi funzionali che gli utenti possano effettivamente testare, anziché su una documentazione perfetta che potrebbe non rispecchiare mai la realtà
- La collaborazione con il cliente è più importante della negoziazione contrattuale: il coinvolgimento continuo delle parti interessate durante tutto il processo di sviluppo è più importante del rigoroso rispetto dei contratti iniziali, redatti prima che qualcuno comprendesse le reali esigenze
- Rispondere al cambiamento anziché seguire un piano: i team accolgono e si adattano ai requisiti in evoluzione man mano che emergono nuove informazioni, anziché considerare ogni cambiamento come un problema costoso da evitare
Questi valori non implicano l’abbandono totale di processi, documentazione, contratti o piani. Semplicemente, quando si è costretti a scegliere, danno priorità a ciò che offre il massimo valore.
Come funziona l’Agile [Passo dopo passo]
I team mettono in pratica l’agilità attraverso cicli di sprint ripetuti che trasformano le idee in software funzionante.
Ogni sprint segue lo stesso ritmo, dura in genere due settimane e garantisce prevedibilità pur mantenendo la flessibilità all’interno di tale struttura.
1. Pianificazione dello sprint
Il ciclo ha inizio con la pianificazione dello sprint, durante la quale il team seleziona gli elementi del product backlog che ritiene di poter completare nel corso dello sprint.
Ma non si tratta semplicemente di scegliere le attività in modo casuale. Il product owner spiega cosa è più importante in questo momento, mentre gli sviluppatori valutano cosa è fattibile in base alla loro capacità attuale e alla velocità registrata in passato.
Insieme, definiscono un obiettivo dello sprint che conferisce al lavoro un significato che va oltre il semplice completamento di una lista di controllo.
Il team suddivide inoltre gli elementi selezionati in attività più piccole e definisce un piano per lo svolgimento del lavoro.
2. Riunioni quotidiane (StandUp)
Ogni giorno, durante lo sprint, il team tiene una riunione di verifica di quindici minuti per rimanere allineato.
Non si tratta di rapporti sullo stato di avanzamento da presentare a un responsabile. Si tratta invece di sessioni di lavoro in cui gli sviluppatori verificano i progressi compiuti verso l’obiettivo dello sprint e individuano gli ostacoli che impediscono il proseguimento del lavoro.
Ogni persona effettua la condivisione di ciò che ha realizzato ieri, di ciò su cui sta lavorando oggi e di qualsiasi ostacolo che impedisca di andare avanti.
Il limite di tempo rigoroso aiuta a mantenere la concentrazione, mentre eventuali discussioni approfondite vengono affrontate in seguito solo con le persone interessate.
3. Esecuzione dello sprint
Tra una cerimonia e l’altra, gli sviluppatori realizzano incrementi funzionanti che soddisfano la definizione di “terminato” del team, gestendo autonomamente il proprio lavoro e adattando i piani quotidianamente sulla base di ciò che apprendono.
L’obiettivo dello sprint rimane fisso, ma il modo in cui il team lo raggiunge può cambiare man mano che si incontrano sfide tecniche o si scoprono approcci migliori.
Non vengono apportate modifiche che potrebbero compromettere l’obiettivo dello sprint, sebbene l’ambito possa essere chiarito e rinegoziato con il Product Owner man mano che il team acquisisce ulteriori informazioni.
4. Revisione dello sprint
Al termine dello sprint, il team presenta il lavoro completato alle parti interessate nel corso di una sessione operativa anziché di una presentazione formale, consentendo al feedback di influenzare immediatamente le priorità successive.
Gli stakeholder vedono un software funzionante che possono effettivamente testare e fornire feedback basati sull’esperienza reale piuttosto che su requisiti teorici.
Spesso il product backlog viene modificato sul momento in base a ciò che tutti imparano osservando l’incremento.
5. Retrospettiva dello sprint
La cerimonia finale conclude ogni sprint analizzando cosa ha funzionato bene, quali problemi sono emersi e quali miglioramenti sono più importanti per lo sprint successivo.
Il team valuta l’andamento dello sprint in termini di individui, interazioni, processi e strumenti.
Identificano i cambiamenti più incisivi per migliorare l’efficacia e li implementano immediatamente oppure li aggiungono al backlog dello sprint successivo.
Questo meccanismo di miglioramento integrato impedisce ai team di ripetere gli stessi errori sprint dopo sprint.
Questo ritmo crea trasparenza, in cui tutti possono vedere il lavoro svolto; un’attività di verifica, in cui lo stato dei progressi viene esaminato frequentemente; e un processo di adattamento, in cui il processo viene modificato quando la verifica rivela eventuali problemi.
Gli approcci agili più diffusi
L’Agile non è una singola metodologia, ma una famiglia di framework. Tre di essi dominano l’implementazione moderna e la scelta tra loro dipende dal tipo di lavoro che il tuo team gestisce e dalla prevedibilità con cui questo viene assegnato.
Scrum
Scrum è il framework più diffuso, con un tasso di adozione del 63%, e a ragione.
Questi metodi prevedono ruoli ben definiti, tra cui il Product Owner, lo Scrum Master e gli sviluppatori, oltre a rituali prestabiliti e artefatti chiari che offrono ai team un punto di partenza concreto.
La struttura degli sprint a durata prestabilita crea ritmo e prevedibilità, consentendo al contempo di adattarsi all’interno di ciascun ciclo.
Questo approccio è particolarmente indicato per lo sviluppo di prodotti complessi con team composti da un massimo di 10 persone, in cui i requisiti in continua evoluzione traggono vantaggio da una pianificazione adattiva.
Se stai sviluppando qualcosa di nuovo in cui le esigenze dei clienti cambiano man mano che acquisisci ulteriori informazioni, l’approccio iterativo di Scrum ti consente di adeguare la direzione ogni poche settimane, anziché committere a un piano rigido a lungo termine.
Kanban
Kanban adotta un approccio diverso, ponendo l’accento sul flusso continuo piuttosto che su iterazioni fisse.
I team visualizzano il proprio lavoro su bacheche e stabiliscono limiti al lavoro in corso (WIP) per evitare sovraccarichi e cambi di contesto.
Il lavoro viene gestito dal sistema man mano che si libera capacità, creando un flusso regolare e prevedibile.
Questo approccio è particolarmente indicato per il supporto alla produzione, i team di manutenzione con un carico di lavoro continuo e imprevedibile e i team operativi che forniscono servizi in modo continuativo, con un flusso di lavoro costante.
Se il tuo team gestisce ticket di supporto, correzioni di bug o richieste relative all’infrastruttura che non possono attendere la prossima sessione di pianificazione dello sprint, il modello continuo di Kanban si adatta perfettamente.
Extreme Programming (XP)
XP punta fortemente sull’eccellenza tecnica attraverso pratiche ingegneristiche rigorose. La programmazione in coppia riunisce due sviluppatori alla stessa postazione di lavoro per una revisione continua del codice.
Lo sviluppo guidato dai test prevede la scrittura dei test (che falliscono) prima del codice. L’integrazione continua verifica immediatamente il codice non appena viene aggiunto, per individuare rapidamente eventuali problemi.
Questo approccio è particolarmente indicato quando la qualità del codice è fondamentale, i team sono piccoli e possono lavorare nella stessa sede per un pairing efficace, e i requisiti cambiano frequentemente.
XP offre le pratiche tecniche che garantiscono la manutenibilità del codice anche quando i requisiti cambiano, rendendolo particolarmente prezioso per i prodotti di lunga durata in cui il debito tecnico diventa oneroso.
Combinazione dei framework
Spesso i teams combinano diversi framework per trarre il meglio da ciascun approccio.
Scrum più XP rappresenta l’ibrido più diffuso: Scrum viene utilizzato per la struttura di project management del progetto, mentre XP garantisce la qualità tecnica attraverso pratiche ingegneristiche rigorose.
Questa combinazione ti offre la pianificazione basata sugli sprint e il coinvolgimento delle parti interessate tipici di Scrum, insieme alle pratiche di qualità del codice di XP che impediscono l’accumulo di debito tecnico.
Quando l’Agile è la scelta più sensata
L'approccio agile dà il meglio di sé quando sussistono determinate condizioni:
- Progetti con requisiti in continua evoluzione o poco chiari, in cui le esigenze dei clienti cambiano rapidamente
- Lavori complessi che richiedono flessibilità e capacità di adattamento man mano che i team acquisiscono esperienza
- Sviluppo software personalizzato che richiede un feedback frequente da parte dei clienti
- Situazioni in cui i team possono consegnare incrementi funzionanti ogni due o quattro settimane
- Organizzazioni disposte a conferire ai team l’autorità decisionale
Questi scenari hanno un elemento in comune: l’incertezza, che può essere gestita meglio attraverso un approccio iterativo piuttosto che con un piano iniziale.
Ma anche il rovescio della medaglia è altrettanto importante. Requisiti fissi senza modifiche previste vanificano la flessibilità dell’approccio agile, poiché si sostengono i costi di adattamento senza che ce ne sia bisogno.
Allo stesso modo, i settori fortemente regolamentati, come quello farmaceutico, pongono un problema diverso, poiché richiedono una documentazione esaustiva che l’approccio snello dell’agilità non è in grado di fornire di per sé.
Alcuni progetti devono inoltre fare i conti con vincoli che rendono impraticabile l’iterazione. I progetti di costruzione fisica presentano dipendenze rigide per cui gli approcci sequenziali risultano semplicemente più sensati.
Inoltre, quando i contratti prevedono strutture a prezzo fisso con risultati predeterminati e sanzioni rigide, entrano in conflitto fondamentale con l’approccio agile, che accoglie di buon grado l’evoluzione dell’ambito di progetto.
Prima di commit, tre prerequisiti determinano la fattibilità:
- Riesci a rilasciare nuove funzionalità/funzioni ogni mese senza un carico di lavoro eccessivo legato ai test?
- C’è qualcuno disponibile e autorizzato a prendere decisioni quotidiane relative alle spese in qualità di titolare del prodotto?
- Non sai ancora quale sarà la soluzione?
Se rispondi “no” a una qualsiasi di queste domande, gli approcci ibridi che combinano le pratiche agili con la struttura tradizionale dei progetti spesso risultano più sensati rispetto all’imposizione di una metodologia che non si adatta ai tuoi vincoli.
Come iniziare con il project management agile per i progetti
L'adozione dell'agilità richiede un percorso graduale, piuttosto che tentare una trasformazione immediata. Ecco come passare dal piano alla tua prima sprint di esito positivo.
Prima di addentrarci nei dettagli, questo video offre una solida base su come si presenta effettivamente l’agilità nella pratica:
- Fase 1: Valuta il tuo grado di preparazione Prima di annunciare una trasformazione agile, valuta se il tuo ambiente sia effettivamente in grado di supportarla. Esamina innanzitutto il tipo di progetto e verifica che presenti requisiti in continua evoluzione e che richieda un feedback frequente. Successivamente, valuta se i membri del team siano disposti a cambiare il proprio modo di lavorare o se dovrai fare i conti con una resistenza radicata. Infine, assicurati che gli stakeholder e la leadership comprendano che dovranno partecipare attivamente durante tutto il processo, anziché limitarsi a ricevere rapporti sullo stato di avanzamento solo alla fine. Se uno qualsiasi di questi elementi manca, colma tali lacune prima di procedere. Le trasformazioni agili falliscono molto più spesso a causa della mancanza di supporto organizzativo che a causa di problemi di esecuzione tecnica.
- Passaggio 2: Scegli il tuo framework Una volta verificata la prontezza, scegli un framework e commit a utilizzarlo per almeno tre mesi. Scrum offre una struttura che funziona bene per i team di sviluppo prodotto, mentre Kanban si adatta a flussi di lavoro continui come l’assistenza e la manutenzione. Se la qualità tecnica è la tua priorità, XP si concentra su pratiche ingegneristiche come la programmazione in coppia e lo sviluppo guidato dai test. La chiave è padroneggiare completamente un approccio prima di combinare diversi framework, perché devi capire perché ogni elemento esiste prima di iniziare a personalizzarlo in base alla tua situazione.
- Passaggio 3: Avvia un progetto pilota Una volta scelto il framework, seleziona un progetto importante per l’azienda ma che non ne comprometta la sopravvivenza qualora dovessero sorgere problemi. Questo ti darà modo di imparare senza conseguenze catastrofiche. Prevedi da due a tre sprint (da quattro a dodici settimane) come periodo di valutazione, mantenendo il team piccolo, composto da quattro o cinque persone, in modo che i costi di coordinamento non oscurino l’efficacia del metodo agile stesso. Assicurati che i membri del team possano dedicarsi a tempo pieno al progetto pilota, anziché dividere la loro attenzione tra più progetti.
- Passaggio 4: Definisci ruoli chiari Il tuo progetto pilota necessita di tre ruoli chiave che funzionino correttamente sin dal primo giorno. Il Product Owner deve avere l’autorità di prendere decisioni quotidiane relative alle spese senza dover chiedere l’approvazione ai livelli superiori, e deve rimanere a disposizione del team anziché sparire per giorni interi. Il tuo Scrum Master dovrebbe facilitare il processo e rimuovere gli ostacoli, piuttosto che gestire le persone nel senso tradizionale del termine. Infine, crea un team di sviluppo interfunzionale che disponga di tutte le competenze necessarie per completare il lavoro senza che dipendenze esterne ne rallentino l’avanzamento. Questi ruoli non sono elementi opzionali che puoi tralasciare. Sono requisiti strutturali affinché l’approccio agile funzioni come previsto.
- Fase 5: Avvia il tuo primo sprint Inizia la pianificazione dello sprint chiedendo al product owner di illustrare le priorità attuali, mentre il team effettua la selezione delle attività che ritiene di poter completare. Lavorate insieme per definire cosa significhi effettivamente “terminato” per il vostro team, in modo che tutti condividano lo stesso standard; poi programmate tutte le cerimonie ricorrenti, come lo StandUp quotidiano, la revisione dello sprint e la retrospettiva, e proteggete quel tempo da altre riunioni. Quindi iniziate a sviluppare e aspettatevi che il primo sprint risulti un po’ goffo, perché è sempre così. I team in genere hanno bisogno da tre a cinque sprint per trovare il proprio ritmo e stabilire una velocità affidabile.
Prima di annunciare una trasformazione agile, valuta se il tuo contesto sia effettivamente in grado di sostenerla. Esamina innanzitutto il tipo di progetto e verifica che presenti requisiti in continua evoluzione e che richieda un feedback frequente. Valuta poi se i membri del team siano disposti a cambiare il proprio modo di lavorare o se dovrai fare i conti con una resistenza radicata. Infine, assicurati che gli stakeholder e la leadership comprendano che dovranno partecipare attivamente durante tutto il processo, anziché limitarsi a ricevere report sulla reportistica sullo stato di avanzamento solo alla fine. Se uno qualsiasi di questi elementi manca, colma tali lacune prima di procedere. Le trasformazioni agili falliscono molto più spesso per mancanza di supporto organizzativo che per problemi di esecuzione tecnica.
Una volta verificata la tua preparazione, scegli un framework e impegnati a seguirlo per almeno tre mesi. Scrum offre una struttura che funziona bene per i team di sviluppo prodotto, mentre Kanban è adatto a flussi di lavoro continui come l’assistenza e la manutenzione. Se la qualità tecnica è la tua priorità, XP si concentra su pratiche ingegneristiche come la programmazione in coppia e lo sviluppo guidato dai test. La chiave è padroneggiare completamente un approccio prima di combinare diversi framework, perché devi capire perché ogni elemento esiste prima di iniziare a personalizzarlo in base alla tua situazione.
Una volta scelto il framework, seleziona un progetto importante per l’azienda ma che non ne comprometta la sopravvivenza in caso di problemi. Questo ti darà spazio per imparare senza conseguenze catastrofiche. Prevedi da due a tre sprint (da quattro a dodici settimane) come periodo di valutazione, mantenendo il team piccolo, composto da quattro o cinque persone, in modo che i costi di coordinamento non oscurino l’efficacia del metodo agile stesso. Assicurati che i membri del team possano dedicarsi a tempo pieno al progetto pilota, anziché dividere la loro attenzione tra più progetti.
Il tuo progetto pilota ha bisogno che tre ruoli chiave funzionino correttamente fin dal primo giorno. Il Product Owner deve avere l’autorità di prendere decisioni quotidiane relative alle spese senza dover chiedere l’approvazione ai livelli superiori, e deve rimanere a disposizione del team invece di sparire per giorni interi. Il tuo Scrum Master dovrebbe facilitare il processo e rimuovere gli ostacoli, piuttosto che gestire le persone nel senso tradizionale del termine. Infine, crea un team di sviluppo interfunzionale che disponga di tutte le competenze necessarie per completare il lavoro senza che dipendenze esterne ne rallentino l’avanzamento. Questi ruoli non sono elementi opzionali che puoi tralasciare. Sono requisiti strutturali affinché l’approccio agile funzioni come previsto.
Inizia la pianificazione dello sprint chiedendo al product owner di illustrare le priorità attuali, mentre il team effettua la selezione del lavoro che ritiene di poter completare. Lavorate insieme per definire cosa significhi effettivamente “terminato” per il vostro team, in modo che tutti condividano lo stesso standard; poi programmate tutte le cerimonie ricorrenti, come lo StandUp quotidiano, la revisione dello sprint e la retrospettiva, e proteggete quel tempo da altre riunioni. Quindi iniziate a sviluppare e aspettatevi che il primo sprint risulti un po’ goffo, perché è sempre così. I team in genere hanno bisogno di tre-cinque sprint per trovare il proprio ritmo e stabilire una velocità affidabile.
Domande frequenti
Quanto tempo ci vorrà prima di vedere i risultati dell’approccio agile?
Già nel primo sprint si registrano miglioramenti immediati nella comunicazione all’interno del team. La trasformazione di John Deere ha portato a una riduzione del 79% della durata ciclo in sei mesi. I benefici a medio termine raggiungono un aumento della produttività del 165%. La maturità a lungo termine, raggiunta tra i dodici e i ventiquattro mesi, crea una cultura autosufficiente con il massimo ritorno sull’investimento (ROI).
Qual è la differenza tra "agile" e Scrum?
L’Agile è una filosofia derivata dal Manifesto Agile, caratterizzata da valori e principi. Scrum è un framework che implementa l’Agile attraverso ruoli, eventi e artefatti ben definiti. Immagina l’Agile come una filosofia di vita sana, mentre Scrum è un piano specifico di alimentazione ed esercizio fisico.
I piccoli team composti da due o tre persone possono utilizzare efficacemente i metodi agili?
Sì, spesso in modo più efficace. La Guida allo Scrum raccomanda tre team come numero minimo, ma anche i team più piccoli si adattano bene. Comunicano costantemente, eliminando le riunioni formali StandUp. I team più grandi costano da tre a quattro volte di più e presentano un numero maggiore di difetti. Mantieni le retrospettive e prendi in considerazione le pratiche Kanban o XP.
Conclusione
Non è certo un segreto che la gestione agile dei progetti sia una delle metodologie di project management più diffuse al mondo.
È semplice e veloce aiutare il tuo team a portare a termine le attività e i progetti in un batter d’occhio!
Inoltre, poiché questi metodi puntano sul cambiamento in risposta al feedback dei clienti, puoi stare certo che realizzerai un prodotto che i tuoi clienti apprezzeranno.
Se stai pensando di adottare metodi di project management Agile, perché non provare un software come ClickUp?
Ha tutto ciò che ti serve per gestire i tuoi progetti e i sprint senza alcuno sforzo! Iscriviti oggi stesso alla versione gratis a vita di ClickUp