Il tuo team ha appena trascorso sei mesi a realizzare esattamente ciò che il client aveva richiesto. La demo va alla perfezione. Poi arrivano a dirti: “Non è più quello di cui abbiamo bisogno. Il mercato è cambiato.”
Ho visto questo scenario 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.
Ad un certo punto, i team di sviluppo software hanno capito una cosa importante: e se smettessimo di opporci al cambiamento e iniziassimo invece ad aspettarcelo?
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 e XP sono i principali framework per progetti agili.
- Un'adozione agile di esito positivo richiede autentici cambiamenti nella cultura organizzativa.
Che cos'è il project management agile?
La gestione agile dei progetti è un approccio iterativo che crea valore attraverso brevi cicli di lavoro chiamati Sprints, che in genere durano da due a quattro settimane, in cui i team pianificano, eseguono, valutano e si adattano continuamente, anziché seguire un piano sequenziale rigido.
Invece di dedicare mesi alla creazione di tutto prima di ricevere un feedback, i team rilasciano software funzionante ogni poche settimane e lo adattano in base a ciò che imparano.
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, solo per scoprire che i requisiti sono cambiati mesi fa.
Il project management tradizionale dei progetti a cascata definisce i requisiti all'inizio e procede attraverso fasi lineari in cui ogni fase deve essere completata prima che inizi quella successiva.
Il coinvolgimento del cliente avviene principalmente durante la raccolta iniziale dei requisiti e la consegna finale, senza nulla di concreto 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 un vantaggio competitivo piuttosto che un problema costoso.
La metodologia mantiene l'attenzione sul valore per il cliente entro i limiti di tempo e di costo stabiliti, rendendo il 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 rilasciato la loro prima funzionalità/funzione funzionante in quattro settimane e hanno modificato la direzione sulla base del feedback reale dei clienti. Quel cambiamento ha salvato la linea di prodotti.
Ho visto un cliente Fortune 500 lottare 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 rilasciato la loro prima funzionalità/funzione funzionante in quattro settimane e hanno modificato la direzione sulla base del feedback reale dei clienti. Quel cambiamento ha salvato la linea di prodotti.
La ricerca dello Standish Group rivela che i progetti agili raggiungono tassi di esito positivo del 42% 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 unico posto? Scarica qui gratis il modello di gestione Agile di ClickUp!
I principi fondamentali del project management agile
Il Manifesto Agile ha stabilito nel 2001 quattro valori che ancora oggi guidano i team moderni. Non si tratta di una filosofia astratta, ma di priorità pratiche che guidano le decisioni quotidiane.
- Le persone e le interazioni prima 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 complicati
- 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 prima della negoziazione del contratto: il coinvolgimento continuo degli stakeholder durante lo sviluppo è più importante del rigoroso rispetto dei contratti iniziali redatti prima che qualcuno comprendesse i requisiti reali
- Rispondere al cambiamento piuttosto che 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 la 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 inizia con la pianificazione dello sprint, durante la quale il team seleziona gli elementi del product backlog che ritiene di poter completare durante lo sprint.
Ma non si tratta semplicemente di scegliere le attività in modo casuale. Il product owner spiega cosa è più importante in questo momento, e 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 crea un piano per lo svolgimento del lavoro.
2. StandUps quotidiani
Ogni giorno, durante lo sprint, il team tiene una riunione di verifica di quindici minuti per rimanere sincronizzato.
Non si tratta di rapporti sullo stato di avanzamento da presentare a un manager. Si tratta invece di sessioni di lavoro in cui gli sviluppatori verificano i progressi verso l'obiettivo dello sprint e individuano gli ostacoli che bloccano il lavoro.
Ognuno effettua la condivisione di ciò che ha realizzato ieri, di ciò che sta affrontando oggi e di qualsiasi ostacolo che impedisca di andare avanti.
Il limite di tempo rigido mantiene l'attenzione sull'essenziale, mentre eventuali discussioni approfondite avvengono in seguito solo con le persone interessate.
3. Esecuzione dello sprint
Tra una cerimonia e l'altra, gli sviluppatori creano incrementi funzionanti che soddisfano la definizione di "terminato" del team, gestendo autonomamente il proprio lavoro e adattando i piani quotidianamente in base a ciò che apprendono.
L'obiettivo dello sprint rimane fisso, ma il modo in cui il team lo raggiunge può cambiare man mano che incontra difficoltà tecniche o scopre 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 agli stakeholder in una sessione di lavoro anziché in 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.
Il product backlog viene spesso modificato sul momento in base a ciò che tutti imparano osservando l'incremento.
5. Retrospettiva dello sprint
La cerimonia finale conclude ogni sprint esaminando cosa è andato bene, quali problemi sono emersi e quali miglioramenti sono più importanti per lo sprint successivo.
Il team esamina 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 vedono il lavoro svolto, ispezione, in cui lo stato viene esaminato frequentemente, e adattamento, in cui il processo viene modificato quando l'ispezione rivela dei problemi.
Gli approcci agili più comuni
L'agilità 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 sua prevedibilità.
Scrum
Scrum è il framework più diffuso, con un tasso di adozione del 63%, e a ragione.
Fornisce ruoli strutturati, tra cui product owner, scrum master e sviluppatori, insieme a cerimonie prestabilite 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 l'adattamento all'interno di ogni ciclo.
Questo framework funziona al meglio per lo sviluppo di prodotti complessi con team composti da 10 persone o meno, 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é impegnarti in 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 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 è ideale 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, dove il lavoro arriva costantemente.
Se il tuo team gestisce ticket di assistenza, correzioni di bug o richieste relative all'infrastruttura che non possono attendere la prossima sessione di pianificazione dello sprint, il modello continuo di Kanban è la soluzione ideale.
Extreme Programming (XP)
XP punta fortemente sull'eccellenza tecnica attraverso pratiche ingegneristiche disciplinate. 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 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 nello stesso luogo per un pairing efficace, e i requisiti cambiano frequentemente.
XP fornisce le pratiche tecniche che mantengono i codici gestibili anche quando i requisiti cambiano, rendendolo particolarmente prezioso per i prodotti di lunga durata in cui il debito tecnico diventa costoso.
Fusione dei framework
Teams spesso combinano diversi framework per ottenere il meglio da ciascun approccio.
Scrum plus XP rappresenta l'ibrido più diffuso: utilizza Scrum per la struttura di project management, mentre XP garantisce la qualità tecnica attraverso pratiche ingegneristiche rigorose.
Questa combinazione ti offre la pianificazione basata sugli sprint e il coinvolgimento degli stakeholder 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'agilità prospera quando sussistono determinate condizioni:
- Progetti con requisiti in evoluzione o poco chiari, in cui le esigenze dei clienti cambiano rapidamente
- Lavori complessi che richiedono flessibilità e 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 il potere decisionale
Questi scenari condividono un elemento: l'incertezza, che trae vantaggio dalla scoperta iterativa piuttosto che dal piano iniziale.
Anche il rovescio della medaglia è importante. Requisiti fissi senza modifiche previste vanificano la flessibilità dell'agilità, poiché si sostengono i costi di adattamento senza che ce ne sia bisogno.
Allo stesso modo, gli ambienti fortemente regolamentati come quello farmaceutico creano un problema diverso, richiedendo una documentazione estesa che l'approccio snello dell'agilità non fornisce naturalmente.
Alcuni progetti devono inoltre fare i conti con vincoli che rendono l'iterazione poco praticabile. I progetti di costruzione fisica presentano rigide dipendenze per cui gli approcci sequenziali risultano semplicemente più sensati.
Inoltre, quando i contratti prevedono strutture a prezzo fisso con risultati predeterminati e sanzioni rigide, essi sono in netto contrasto 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 funzionalità/funzioni ogni mese senza un eccessivo carico di lavoro legato ai test?
- C'è qualcuno disponibile e autorizzato a prendere decisioni quotidiane relative alle spese in qualità di titolare?
- Non sai ancora quale sia 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 hanno più senso rispetto all'imposizione di una metodologia che non si adatta ai tuoi vincoli.
Come iniziare con il project management agile dei progetti
Iniziare con l'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 l'agilità nella pratica:
- Fase 1: Valuta la tua preparazione Prima di annunciare una trasformazione agile, valuta se il tuo ambiente è effettivamente in grado di supportarla. Esamina innanzitutto il tipo di progetto e verifica che abbia requisiti in continua evoluzione e necessiti di feedback frequenti. Quindi valuta se i membri del team sono disposti a cambiare il loro modo di lavorare o se dovrai scontrarti con una resistenza radicata. Infine, assicurati che gli stakeholder e la leadership comprendano che dovranno partecipare attivamente durante tutto il processo, piuttosto che limitarsi a ricevere rapporti sullo stato di avanzamento alla fine. Se uno qualsiasi di questi elementi manca, colma queste lacune prima di andare avanti. Le trasformazioni agili falliscono molto più spesso per mancanza di supporto organizzativo che per problemi di esecuzione tecnica.
- Passaggio 2: Scegli il tuo framework Una volta confermata la tua preparazione, scegli un framework e commit a utilizzarlo per almeno tre mesi. Scrum offre una struttura che funziona bene per i team di sviluppo dei prodotti, mentre Kanban si adatta a flussi di lavoro continui come l'assistenza e la manutenzione. Se la qualità tecnica è la tua preoccupazione principale, 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 i 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 selezionato il framework, scegli un progetto importante per l'azienda ma che non ne causi il fallimento se dovesse incontrare 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, piuttosto che dividere la loro attenzione tra più progetti.
- Fase 4: Definisci ruoli chiari Il tuo progetto pilota ha bisogno di tre ruoli chiave che funzionino correttamente fin dal primo giorno. Il product owner deve avere l'autorità di prendere decisioni quotidiane sulle 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 abbia tutte le competenze necessarie per completare il lavoro senza che dipendenze esterne lo rallentino. Questi ruoli non sono extra opzionali che puoi saltare. Sono requisiti strutturali affinché l'agilità 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 del lavoro che ritiene di poter completare. Collaborate per definire cosa significa effettivamente "terminato" per il vostro team, in modo che tutti condividano lo stesso standard, quindi programmate tutte le cerimonie ricorrenti come il daily standup, la revisione dello sprint e la retrospettiva e proteggete quel tempo da altre riunioni. Quindi iniziate a costruire 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 loro ritmo e stabilire una velocità affidabile.
Prima di annunciare una trasformazione agile, valuta se il tuo ambiente è effettivamente in grado di supportarla. Esamina innanzitutto il tipo di progetto e verifica che abbia requisiti in continua evoluzione e necessiti di feedback frequenti. Quindi valuta se i membri del team sono disposti a cambiare il loro modo di lavorare o se dovrai scontrarti con una resistenza radicata. Infine, assicurati che gli stakeholder e la leadership comprendano che dovranno partecipare attivamente durante tutto il processo, piuttosto che limitarsi a ricevere rapporti sullo stato di avanzamento alla fine. Se uno qualsiasi di questi elementi manca, colma queste lacune prima di andare avanti. Le trasformazioni agili falliscono molto più spesso per mancanza di supporto organizzativo che per problemi di esecuzione tecnica.
Una volta confermata 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 si adatta al lavoro a flusso continuo come l'assistenza e la manutenzione. Se la qualità tecnica è la tua preoccupazione principale, 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 i 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 causi il fallimento se dovesse incontrare difficoltà. Questo ti darà spazio per imparare senza conseguenze catastrofiche. Pianifica 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 possano dedicarsi a tempo pieno al progetto pilota, piuttosto che 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 sulle spese senza dover chiedere l'approvazione ai 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 abbia tutte le competenze necessarie per completare il lavoro senza che dipendenze esterne lo rallentino. Questi ruoli non sono extra opzionali che puoi tralasciare. Sono requisiti strutturali affinché l'agilità 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 significa realmente "terminato" per il vostro team, in modo che tutti condividano lo stesso standard, quindi programmate tutte le cerimonie ricorrenti come il daily standup, la revisione dello sprint e la retrospettiva e proteggete quel tempo da altre riunioni. Quindi iniziate a costruire 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 loro ritmo e stabilire una velocità affidabile.
Domande frequenti
Già dal primo sprint si notano miglioramenti immediati nella comunicazione all'interno del team. La trasformazione di John Deere ha mostrato 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).
L'Agile è una filosofia derivata dal Manifesto Agile, con valori e principi. Scrum è un framework che implementa l'Agile con ruoli, eventi e artefatti definiti. Pensa all'Agile come a una filosofia di vita sana, mentre Scrum è una dieta specifica e un piano di esercizi.
Sì, spesso in modo più efficace. La Guida di Scrum raccomanda tre team come numero minimo, ma anche i team più piccoli si adattano bene. Comunicano costantemente, eliminando le riunioni formali. I team più grandi costano da tre a quattro volte di più e presentano più difetti. Mantieni le retrospettive e prendi in considerazione le pratiche Kanban o XP.
Conclusione
Non è 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 provi un software come ClickUp?
Ha tutto ciò che ti serve per gestire i tuoi progetti e i sprint senza sforzo! Iscriviti oggi stesso alla versione gratis per sempre di ClickUp