Le Basi di Scrum - Eventi Scrum: Sprint Retrospective

8 – Eventi Scrum: Sprint Retrospective

La Sprint Retrospective è un’opportunità per lo Scrum Team d’ispezionare l’andamento dello Sprint e creare un piano di miglioramento per il prossimo Sprint.

Questo event ha una timebox di 3 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve.

Immagina di far parte di una squadra di rugby, non avendo mai giocato a questo gioco. L’efficienza del team nelle prime partite non sarà ottimale. Dopo ogni partita, il team discuterà le azioni di miglioramento da attuare per il prossimo gioco, come ad esempio:

Sprint Retrospective Scrum: facilitazione e miglioramento continuo del team agile
Clicca l’immagine per ascoltare l’episodio del Podcast
  • Il livello di comprensione dei valori e delle regole del gioco da parte dei giocatori;
  • L’efficacia del processo messo in atto per soddisfare lo scopo del gioco;
  • Verificare se gli strumenti utilizzati quotidianamente sono efficaci per raggiungere l’obiettivo: semplificano le nostre vite o la complicano?
  • Relazioni tra giocatori e stakeholder del team

Lo Scrum Master farà in modo che l’intero Scrum Team partecipi all’evento e che l’obiettivo sia chiaro a tutti.

Può facilitare la sessione, su richiesta del team, o parteciparvi contribuendo all’emergere di nuove idee di miglioramento.

Le Basi di Scrum - Eventi Scrum: Sprint Retrospective
Le Basi di Scrum – Eventi Scrum: Sprint Retrospective

TRE ORE SONO TROPPO PER UNA RIUNIONE!

Scrum aiuta a creare un processo empirico per fornire un prodotto o un servizio complesso. Il tempo dedicato alla ricerca del miglioramento non è tempo sprecato, è tempo investito per il futuro.

Spesso la frase citata nel titolo viene pronunciata in ambienti di lavoro dove:

  • Si è affetti da “riunionite”: è una malattia che è nota in molte aziende e che consiste nell’organizzare incontri che non hanno uno scopo specifico, in cui ci si annoia. In questi contesti, comprensibilmente, le persone fanno molta attenzione prima di accettare una riunione;
  • Tutti sono sempre sopraffatti: manca l’attenzione per potersi dedicare pienamente ad un argomento;
  • L’Individualismo: un processo empirico richiede trasparenza. Non partecipare agli eventi Scrum è come guardare attraverso un vetro opaco. Come possiamo migliorare insieme se non prendiamo il tempo di stare insieme?

Inoltre le tre ore di Sprint Retrospective sono un timebox, ciò vuol dire que se l’obiettivo dell’evento è raggiunto rapidamente, si potrà tornare al lavoro ben prima delle tre ore di lavoro previste in generale per uno Sprint di un mese.

IL PRODUCT OWNER DEVE PARTECIPARE ALLa SPRINT Retrospective?

Naturalmente! È membro del Team Scrum e in quanto tale la sua partecipazione è fondamentale. Se non partecipa, come potranno migliorarsi le interazioni fra Product Owner, Scrum Master e Developers?

Uno dei punti di forza di Scrum è abbattere i compartimenti stagni… quindi se il Product Owner è una persona del business (come sales, marketing, dirigente, ecc.), deve capire che far parte di uno Scrum Team richiede coinvolgimento e collaborazione!

SIAMO IN RITARDO, RISPARMIEREMO TEMPO CANCELLANDO La SPRINT Retrospective!

Quante volte ho sentito questa frase… Anche tu?

Immagina una squadra di Rugby che decide di non andare negli spogliatoi alla fine del primo tempo perché è meglio rimanere sul campo a fare autografi, è possibile?

La cancellazione della Sprint Retrospective è spesso motivata da:

  • Pressione esterna allo Scrum Team, spinto a “fare sempre più cose”, sempre più velocemente… senza prestare attenzione al valore creato, o alla qualità.
  • Un Product Owner che spinge il team di sviluppo a fare sempre di più, anche se significa utilizzare le ore della Sprint Retrospective per sviluppare più funzionalità.
  • Un Scrum Master che non è in grado di mediare e proteggere il team dalle incitazioni degli altri dipartimenti (o peggio non previsto nel budget) e che non può rivelare i malfunzionamenti nell’applicazione Scrum. (nota che uno Scrum Team senza Scrum Master non gioca a Scrum, è come giocare a Rugby in 14). Guarda questo video per approfondire l’argomento.

Scrum non è rigido, è una struttura molto semplice, con regole del gioco chiare e descritte nello Scrum Guide.  Se si desidera creare un prodotto o un servizio complesso empiricamente con Scrum, bisogna giocare secondo le regole di Scrum!

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Review

7 – Eventi Scrum: Sprint Review

La Sprint Review è l’evento in cui lo Scrum Team e gli stakeholder (usualmente invitati dal Product Owner) si incontrano per ispezionare l’Incremento e adattare il  Product Backlog.  Questa frequenza di ispezione e adattamento del lavoro svolto è molto importante per capire se la direzione intrapresa è corretta e insieme decidere cosa fare in seguito.

Si tratta di un evento informale, che non ha bisogno di preparazione, perché verrà ispezionato un Incremento Done e quindi, per definizione, corretto e senza anomalie, pronto per essere messo in produzione se il Product Owner lo decide.

Evento Sprint Review in Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un possibile risultato di questo evento potrebbe essere (vedi la Guida Scrum): 

  • Presentazione dello Sprint Goal (definito in Sprint Planning) dal Product Owner
  • Descrizione degli elementi del Product Backlog implementati dalla definizione di Done e non Done, relativo allo Sprint Goal, dal Product Owner
  • I Developers condividono i contenuti dell’Incremento con le scelte tecniche effettuate per le soluzioni implementate
  • Rendere l’Incremento disponibile agli Stakeholders per ottenere feedback
  • Adattare il Product Backlog con nuove idee, un ordine diverso, l’eliminazione di alcuni elementi, ecc.
  • Revisione del Product Backlog e condivisione delle date estimate di consegna in funzione dei progressi compiuti fino ad oggi (dati empirici).
Le Basi di Scrum - Eventi Scrum: Sprint Review
Le Basi di Scrum – Eventi Scrum: Sprint Review

LA SPRINT REVIEW NON È

  • Una demo: ad esempio solo un video, con le nuove funzionalità, mostrato agli Stakeholders.
  • La lettura di un Power Point: teorico, possibilmente con screenshot, che spiega cosa è stato fatto.
  • Una presentazione del lavoro svolto dai Developers al Product Owner, allo Scrum Master o ad un manager.

nella SPRINT REVIEW Non abbiamo nulla da mostrare

C’è sempre qualcosa da ispezionare in Sprint Review, se la Scrum Team si trova in una situazione in cui non c’è nulla da mostrare agli Stakeholders, si deve avere il coraggio di mantenere l’evento e spiegare in modo trasparente gli ostacoli (impediments) che hanno impedito la creazione dell’Incremento Done alla fine dello Sprint.

Le disfunzioni riscontrate sul terreno, che portano a questo tipo di situazione, possono essere:

  • Elementi del Product Backlog troppo grandi da sviluppare durante lo Sprint;
  • Lo Scrum Team non ha tutte le abilità per creare un Incremento Done;
  • Lo Scrum Team, che lavora su diversi progetti/prodotti in multitasking, senza potersi concentrare sulla creazione dell’Incremento
  • Un prodotto esistente che viene tagliato in strati tecnici
  • L’assenza di uno Sprint Goal

Qualunque cosa accada, lo Scrum Team si auto-organizzarsi per poter, in Sprint Review, portare del valore agli stakeholders. L’interesse deriva dall’essere riusciti a creare una variazione del valore del prodotto rispetto all’ultima volta. Questo può essere difficile all’inizio, in alcune situazioni. L’annullamento della Sprint Review non aiuterà a migliorare, al contrario, avrà un effetto negativo sulla trasparenza del lavoro e impedirà allo Scrum Team di ricevere feedback preziosi.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Daily Scrum

6 – Eventi Scrum: Daily Scrum

Il Daily Scrum è un evento quotidiano che mira a ispezionare i progressi verso lo Sprint Goal e ad adattare lo Sprint Backlog, se necessario. Ha una time-box di 15 minuti.

Il Daily Scrum si svolge sempre nello stesso luogo alla stessa ora, per ridurre la complessità. Sono i Developers che decidono le modalità d’organizzazione.

Il Daily Scrum consente agli sviluppatori di capire se lo Sprint Goal verrà raggiunto o meno entro la fine dello Sprint. Se il Product Owner o lo Scrum Master stanno lavorando attivamente su elementi dello Sprint Backlog, partecipano come Developers.

I Developers, per capire se lo Sprint Goal è raggiungibile, utilizzeranno un modo per rendere trasparente il lavoro svolto e quello ancora da fare. Molto spesso sentiremo parlare di “Burndown Chart” (vedi il glossario di Scrum), in formato cartaceo o elettronico. L’importante è la trasparenza delle informazioni.

Daily Scrum in Scrum Framework
Clicca l’immagine per ascoltare l’episodio del Podcast

IL DAILY SCRUM NON È…

… un incontro per risolvere i problemi, il suo scopo è quello di rivelarli per affrontarli al momento giusto e a seconda della loro gravità.

… una riunione di follow-up e lo stato di avanzamento del lavoro dei Developers da parte dello Scrum Master, del Product Owner o di un manager.

… un evento settimanale, il suo nome “Daily” significa ogni giorno… troviamo dunque la risposta alla domanda: “Abbiamo deciso di fare il Daily ogni due giorni, perché vederci ogni giorno non aveva senso”. In questo caso, bisogna pensare alla mancanza di trasparenza nello Scrum Team e all’occasione mancata per sapere se si è ancora in grado di raggiungere lo Sprint Goal.

Non bisogna dimenticare che la base di un approccio empirico è la trasparenza… in quale altro modo potreste ispezionare correttamente il lavoro e adattarlo?

Le Basi di Scrum - Eventi Scrum: Daily Scrum
Le Basi di Scrum – Eventi Scrum: Daily Scrum

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Planning

5 – Eventi Scrum: Sprint Planning

Eventi Scrum: Sprint Planning. Lo Sprint Planning è il primo evento dello Sprint. Il suo obiettivo è quello di collaborare alla pianificazione del lavoro da fare durante lo Sprint. Ha un timebox di 8 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve. L’intero Scrum Team partecipa per tutta la durata.

Sprint Planning Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

I tre argomenti seguenti vengono discussi durante lo Sprint Planning.

1 – PERCHÉ QUESTO SPRINT È IMPORTANTE?

Il Product Owner propone come il prodotto potrebbe aumentare il valore e l’utilità durante l’attuale Sprint.

La parte superiore del Product Backlog sarà costituita da elementi abbastanza piccoli, conosciuti e compresi dall’intero Scrum Team e coerenti con la visione del Product Owner.

Lo Scrum Team lavora insieme per definire uno Sprint Goal realistico e realizzabile per la fine dello Sprint.

2 – COSA POSSIAMO FARE in questo SPRINT?

I Developers selezionano gli elementi del Product Backlog realizzabili in uno Sprint, collaborando con Product Owner. 

Alcuni fattori hanno un impatto sulle stime dei Developers, come: 

  • Definizione di Done 
  • Prestazioni passate
  • Azioni di miglioramento da implementare
  • La capacità dello Scrum Team (ferie, assenze varie, assegnazioni parziali).

3 – COME VERRÀ SVOLTO IL LAVORO SCELTO?

Per ogni elemento del Product Backlog (non necessariamente tutti), gli sviluppatori pianificano il lavoro necessario per creare un incremento che soddisfi la definizione di Done, con più o meno dettagli a seconda dell’esperienza.

Lo Sprint Goal, gli elementi del Product Backlog per lo Sprint, così come il piano per consegnarli costituiscono lo Sprint Backlog. Accetteremo che lo Sprint Backlog cambi in base alle informazioni che emergono durante lo Sprint.

OSSERVAZIONI IMPORTANTI

  • In un contesto complesso, come lo sviluppo software, le interazioni non sono mai lineari. Aspettatevi che tutti e tre gli argomenti siano ridiscussi più volte durante lo Sprint Planning.
  • L’unico commitment preso dallo Scrum Team è il raggiungimento dello Sprint Goal. Non è la quantità di lavoro, o gli elementi del Product Backlog sviluppato alla fine dello Sprint che conta, è il fatto che lo Scrum Team sia riuscito a raggiungere lo Sprint Goal e a creare un incremento Done potenzialmente rilasciabile in produzione. Anche il più piccolo.
  • Da “Push” a “Pull”: solo i Developers possono fare previsioni su quanti elementi del Product Backlog verranno realizzati durante lo Sprint. Si dice che i Developers “tirano” il lavoro da fare in base ai suggerimenti del Product Owner. Nessuno può imporre loro o “spingere” una quantità di lavoro da fare. Rinunciare ad accettare questo modo di lavorare significa depotenziare i Developers e spesso porta ad effetti collaterali come: mancanza di commitment, mancanza di qualità, debito tecnico, turnover, ecc.
  • I Developers selezioneranno gli elementi del Product Backlog nell’ordine definito dal Product Owner.  Non si sceglie l’elemento più facile da raggiungere, per comodità.
  • Il Product Owner partecipa e collabora alle discussioni sull’argomento “3 – Come verrà svolto il lavoro scelto?”.  Sì! Rimane per il motivo indicato nel primo punto di questa lista. Ci si deve sempre aspettare interazioni non lineari all’interno dello Scrum Team durante lo Sprint Planning.
  • Lo Sprint Backlog non necessità dettagli in tutti i suoi contenuti. L’importante sarà avere abbastanza dettagli per poter avviare lo Sprint. Si accetterà l’emergere del lavoro durante lo Sprint (e le modifiche conseguenti allo Sprint Backlog).

Al termine dello Sprint Planning, lo Sprint Goal, le previsioni degli elementi del Product Backlog  da sviluppare (realizzati dai Developers) e il piano per raggiungerli saranno tutti elementi visibili nello Sprint Backlog.

Le Basi di Scrum - Eventi Scrum: Sprint Planning
Le Basi di Scrum – Eventi Scrum: Sprint Planning

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint

4 – Eventi Scrum: Sprint

COS’È UNO SPRINT?

Scrum prescrive cinque eventi, lo Sprint è il cuore e il contenitore di tutti gli altri. Ha una durata di massimo un mese, durante il quale viene creato e potenzialmente rilasciato un incremento di prodotto finito (“Done”) in produzione, (cfr. Guida scrum).

Lo Sprint consente una frequenza regolare di ispezione e adattamento del prodotto e della maniera di lavorare insieme nello Scrum Team e al di fuori. Il miglioramento continuo è alla base di Scrum.

Uno Sprint può essere considerato un mini-progetto con: 

  • Un obiettivo chiaro e immutabile (lo Sprint Goal)
  • Una durata fissa (massimo un mese)
  •  Una qualità impeccabile (resa trasparente nella definizione di Done)

…  e il contenuto?

Eventi Scrum e Sprint
Clicca l’immagine per ascoltare l’episodio del Podcast

Delle previsioni in merito al contenuto dello Sprint vengono fatte durante lo Sprint Planning dai Developers, perché per un prodotto complesso si accetterà l’adattamento del contenuto in relazione all’emergere di nuove informazioni (positive o negative).

Al termine dello Sprint, lo Scrum Team raggiunge lo Sprint Goal, materializzato da un Incremento di prodotto che aderisce alla definizione di Done.

L’unica eccezione sarebbe l’obsolescenza dello Sprint Goal nel corso dello Sprint, ad esempio un cambiamento delle condizioni di mercato. In questo caso, solo il Product Owner può decidere di annullare lo Sprint, che termina prematuramente con gli eventi rimanenti.

Tutto il lavoro degli sviluppatori viene eseguito all’interno dello Sprint e ha come origine il Product Backlog. Ciò implica che le tradizionali attività di ingegneria del software (analisi, progettazione, sviluppo, test, integrazione, ecc.) si svolgono in uno Sprint, in modo non lineare e attraverso la collaborazione di tutti. 

Formalizzeremo meno e collaboreremo di più.

Fabio Panzavolta

Pertanto, uno Sprint non ha aggettivi: lo Sprint 0, lo Sprint di Stabilizzazione, il Test Sprint, lo Sprint di concezione, ecc. non esistono in Scrum.

Le Basi di Scrum - Eventi Scrum: Sprint
Le Basi di Scrum – Eventi Scrum: Sprint

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!