Gestione Agile dei Progetti Sprint

Gli Sprint sono una caratteristica degli approcci agili più diffusi per la gestione dei progetti e la consegna di prodotti. Vengono utilizzati principalmente per suddividere grandi porzioni di lavoro in blocchi più piccoli e gestibili da consegnare da parte dei team agili.

Gli Sprint sono stati descritti per la prima volta come parte di Scrum – uno dei primi e sicuramente il più popolare degli approcci agili utilizzati oggi. Vengono utilizzati anche da Nexus e LeSS (approcci utilizzati per scalare Scrum) e dall'ultima versione di AgilePM. Altri approcci agili come SAFe, DAD e XP utilizzano un concetto quasi identico ma usano il termine Iterazione anziché Sprint.

Nei paragrafi seguenti inizierò descrivendo cosa sono gli Sprint e come sono strutturati prima di passare a consigli e indicazioni pragmatiche per garantire che forniscano i risultati che dovrebbero.

Uno Sprint è un periodo di tempo breve e di durata fissa durante il quale un team lavora per completare un insieme di attività prioritarie. Gli Sprint sono pensati per permettere ai team di delivery di fare progressi significativi e incrementali verso obiettivi a lungo termine in modo prevedibile e graduale.

Limitare gli Sprint a un periodo di tempo di 2-4 settimane, e assicurarsi che ogni Sprint abbia un obiettivo chiaro, favorisce la consegna frequente di risultati di valore e strategicamente allineati.

Il ritmo e la disciplina degli Sprint aiutano i team a costruire slancio, gestire la complessità in modo incrementale e adattarsi rapidamente ai cambiamenti. Soprattutto, consente il miglioramento continuo fornendo frequenti opportunità di feedback, apprendimento e adeguamento.

Lo Sprint, come definito da Scrum, ha una struttura specifica. In questa forma è più adatto per l'uso in un contesto non progettuale dato che Scrum non riconosce il ruolo di un Project Manager. AgilePM suggerisce alcuni miglioramenti pratici e pragmatici a questa struttura predefinita offrendo valore nel contesto di un progetto senza contraddire o sminuire l'intento originale di Scrum.

Il diagramma qui sotto mostra la struttura di uno Sprint come descritto nella Guida Scrum 2020 – la guida definitiva a Scrum scritta dai co-creatori di Scrum Jeff Sutherland e Ken Schwaber.

Descrive quattro Eventi chiave che la maggior parte delle persone riconoscerebbe come riunioni del team che si verificano durante uno Sprint. Il diagramma illustra uno sprint di 2 settimane ma per Sprint di durata diversa, la maggior parte degli Eventi dovrebbe essere ridimensionata di conseguenza.

1. Ogni Sprint inizia con un evento di Sprint Planning durante il quale:

• Viene concordato un Obiettivo di Sprint
  • Si tratta di un processo collaborativo che coinvolge il Product Owner e gli Sviluppatori nel Team Scrum.
  • Il Product Owner è responsabile di garantire che il lavoro pianificato fornisca il massimo valore agli stakeholder.
  • Il Team Scrum deve negoziare un obiettivo verso il quale può impegnarsi.
• Viene negoziato cosa deve essere fatto nello Sprint
  • Anche questo è un processo collaborativo che coinvolge il Product Owner e gli Sviluppatori.
  • Gli elementi necessari per raggiungere l'Obiettivo di Sprint e conseguire un Obiettivo di Prodotto vengono presi dal Product Backlog. Si noti che un Obiettivo di Prodotto può richiedere diversi Sprint per essere raggiunto.
  • Può esserci un certo grado di iterazione tra l'accordo su un preciso Obiettivo di Sprint e il lavoro necessario per raggiungerlo.
• Come verrà svolto il lavoro concordato
  • Si tratta di un processo collaborativo in cui gli Sviluppatori scompongono gli elementi selezionati del Product Backlog in elementi di lavoro attuabili e concordano su come verranno ordinati nello Sprint Backlog.

Lo Sprint Backlog include tutti e tre gli elementi sopra indicati: il lavoro da svolgere. Entro la fine dello Sprint Planning, viene concordato lo Sprint Backlog, che è 'il piano' per lo Sprint di proprietà degli Sviluppatori.

2. Il Daily Scrum

• Si tratta di una riunione giornaliera degli sviluppatori della durata massima di 15 minuti
  • Si tiene tipicamente alla stessa ora ogni giorno lavorativo.
  • Non si ridimensiona in relazione alla durata dello Sprint.
  • Il suo scopo è permettere agli sviluppatori di adattare i loro piani per mantenere la concentrazione e il loro impegno verso l'Obiettivo di Sprint.

Mentre lo Sprint procede, possono essere consegnati degli Incrementi di Prodotto, con ogni Incremento che comprende quelli che lo precedono. La consegna degli Incrementi di Prodotto è la misura del progresso incrementale significativo menzionato in precedenza.

3. Sprint Review

• Questo è il forum utilizzato dal Team Scrum per dimostrare agli stakeholder il valore che ha fornito alla fine dello Sprint.
• L'Incremento di Prodotto finale viene formalmente rivisto nel contesto del suo contributo all'Obiettivo di Prodotto e vengono discussi eventuali miglioramenti potenziali
• Tali miglioramenti vengono aggiunti al Product Backlog, assumendo che non siano già annotati.

4. Sprint Retrospective

• Lo scopo di questo evento è che il Team Scrum rifletta sull'efficacia del proprio modo di lavorare
• Vengono discusse e prioritizzate eventuali idee di miglioramento. Una o due di queste idee vengono adottate come esperimenti per il prossimo Sprint con l'impatto valutato nella successiva Retrospettiva

I seguenti miglioramenti allo Scrum Sprint sono proposti da AgilePM dove aggiungono valore nel contesto della gestione dei progetti. È più probabile che aggiungano valore in progetti multi-team dove i piani tra i team devono sincronizzarsi in un piano progettuale complessivo coerente.

5. Il primo dei miglioramenti consiste nel sostituire il Daily Scrum che si verifica 2 giorni prima della fine dello Sprint con uno speciale Consolidation Scrum.

• Con una durata di 30 minuti, questo evento è leggermente più lungo del Daily Scrum.
• Oltre allo scopo dell'evento che sostituisce, al Scrum Team viene chiesto di prevedere quale parte del lavoro rimanente dello Sprint sarà completata e quale molto probabilmente rimarrà incompleta.

6. Il secondo miglioramento è l'introduzione dell'evento Project Planning.

• A questo evento partecipano i ruoli di leadership del progetto di Business Visionary, Solution Architect e Project Manager, ognuno dei quali ha responsabilità specifiche nella leadership del progetto in AgilePM.

Nota: Da una prospettiva generale di gestione del progetto, le etichette dei ruoli non sono importanti. L'evento dovrebbe essere frequentato dal project manager e da chiunque altro sia responsabile di definire il corso del progetto Sprint dopo Sprint.

• Le previsioni a brevissimo termine del Consolidation Scrum servono come input per l'evento e consentono un contributo di pianificazione sensato per tutti i team per il prossimo Sprint
• L'evento offre anche l'opportunità di pianificare verso un orizzonte oltre lo Sprint imminente e per qualsiasi attività di progetto da svolgere da parte di membri del team di progetto che potrebbero non essere membri di un Scrum Team.

Lavoro con approcci agili alla gestione e consegna di progetti dal 1997. So bene quanto possano funzionare bene e, altrettanto bene, quanto scarse possano essere le prestazioni se le cose non funzionano come dovrebbero.

Se vuoi abbracciare l'agilità nella gestione di progetti, il miglior consiglio che posso offrire è di gestire i tuoi Sprint in conformità alle linee guida Scrum. Questo significa che se sei un project manager devi mantenere un po' di distanza dalla pianificazione e dall'esecuzione degli Sprint. Devi essere abbastanza vicino per assicurarti che funzionino come dovrebbero, permettendo agli aspetti più potenti dell'agilità di accelerare la loro consegna.

Ecco 6 'consigli principali' per l'uso efficace degli Sprint

1. Cerca di lasciare Scrum in pace.

• È provato, testato ed efficace se utilizzato correttamente secondo le linee guida della Scrum Guide. Detto questo, comprendere cosa lo fa funzionare, piuttosto che seguirlo solo in modo procedurale, è essenziale per ottenere il massimo da esso.

2. Usa Sprint di durata fissa in una cadenza regolare

• In teoria puoi variare la durata di ogni Sprint in una sequenza e occasionalmente ha senso avere uno Sprint di durata irregolare di tanto in tanto. Ad esempio, uno Sprint occasionale può essere più lungo o più breve del solito per adattarsi alle festività stagionali o per rispettare una data di consegna che altrimenti cadrebbe a metà Sprint.
• Utilizzare di default uno Sprint di durata fissa rende tuttavia più facile pianificare il coinvolgimento degli stakeholder e monitorare i progressi.

3. NON spostare MAI la data di fine Sprint

• Uno dei principali vantaggi dell'uso degli Sprint è la prevedibilità di consegna che offrono. La consegna puntuale di un prodotto di valore può essere virtualmente garantita:
  • Rispettando la data di fine dello Sprint, e
  • Prioritizzando il lavoro per gestire gli aspetti di maggior valore e/o più rischiosi prima di quelli di minor valore e/o più semplici.

4. Non saltare gli eventi.

• Ogni evento in uno Sprint ha uno scopo collegato alle basi empiriche dell'agilità. Specificamente:
  • Trasparenza di cosa viene fatto e come
  • Ispezione del prodotto in evoluzione e dei modi di lavorare
  • Adattamento di questi per rendere il prodotto sempre più prezioso e per migliorare l'efficienza e l'efficacia delle pratiche lavorative

5. Cerca di 'vivere' il concetto di empowerment del team.

• Comprendi e abbraccia i valori che sostengono il modo di lavorare agile e incoraggia tutti coloro associati al progetto a farlo. Scrum definisce questi valori come Impegno, Concentrazione, Apertura, Rispetto e Coraggio. Citando dalla Scrum Guide del 2020:

"Quando questi valori sono incarnati dal Team Scrum e dalle persone con cui lavorano, i pilastri empirici di Scrum di trasparenza, ispezione e adattamento prendono vita costruendo fiducia."

Tieni presente che non è necessario seguire un approccio Scrum per adottare i suoi valori. Abbracciarli aggiungerà valore in qualsiasi iniziativa basata sul team.

• Non dettare, guida in modo collaborativo.
  • La proprietà e l'impegno del team sono significativamente ridotti in un ambiente dove un singolo individuo, come un project manager, detta cosa dovrebbe essere fatto e quando
  • Un approccio collaborativo alla leadership che abbraccia i valori Scrum descritti sopra porterà a una qualità e produttività migliorate.
• Influenza i piani (sia per la soluzione che per il programma di consegna) tramite i Product Owner. Questo richiede il riconoscimento da parte del Product Owner che i ruoli di leadership del progetto sono stakeholder chiave.

E se i tuoi team non sono nella posizione migliore per performare in modo agile…

6. Guidali verso di esso

• Il modo di lavorare agile si basa molto sull'idea che le persone che svolgono il lavoro sono le più adatte a prendere decisioni dettagliate su cosa deve essere fatto e come. Combinato con una definizione chiara e dettagliata di ciò che è necessario e perché da parte di un Product Owner che lavora in modo collaborativo come parte del team, questo funziona molto bene. Ho personalmente assistito a significativi aumenti di produttività che possono essere attribuiti solo a un passaggio a team empowered da un approccio centralizzato di 'comando e controllo'.
• L'empowerment deve, tuttavia, essere riconosciuto come una strada a doppio senso, con i leader disposti a dare potere ai loro team e i team in grado di abbracciare tale empowerment. In situazioni senza competenza e impegno da parte dei membri del team, ho visto la produttività crollare.
• La teoria della leadership situazionale evoluta da Paul Hersey e Ken Blanchard negli anni '70 descrive come un leader, forse nel nostro contesto un project manager, può transitare verso una dinamica leader/team ottimale per l'agilità.

Gli Sprint sono una pietra angolare di molti approcci agili, fornendo struttura, focus e ritmo alla consegna del valore. Sebbene le loro radici affondino in Scrum, il concetto è stato adattato con successo da una serie di framework e modelli scalati, spesso sotto il termine più ampio di "iterazione." Indipendentemente dalla terminologia, i principi rimangono coerenti: delimitare temporalmente il lavoro, consentire frequenti ispezioni e adattamenti, e permettere ai team di auto-organizzarsi attorno a obiettivi chiari.

Quando usati in modo ponderato, gli Sprint possono migliorare drasticamente la consegna dei progetti — ma solo se vengono rispettati. Trattare gli Sprint come qualcosa di più di un semplice programma, e abbracciare la disciplina, i valori e lo spirito collaborativo che li sostengono, è ciò che sblocca il loro potenziale.

Per i project manager che lavorano in ambienti agili, la sfida è supportare senza controllare — creare spazio per team responsabilizzati assicurando al contempo allineamento e focus. Fatto bene, questo equilibrio porta non solo a Sprint di successo, ma a team costantemente performanti e a un successo duraturo dei progetti.