Categoria: Retrospective

Di Riccardo Ciocci 

 

Nei precedenti articoli abbiamo sviscerato tutte le cause che hanno portato alla nascita delle retrospective a tema.

 

Tutto questo è nato dall’esigenza a primo impatto infantile, ma in realtà primordiale di divertirsi lavorando. Costruire le attività avendo quest’obiettivo comporta allo Scrum Master un effort maggiore. Infatti si tratta di un processo molto più complesso in quanto:

 

– astrarre le attività con una metafora può rendere meno chiare le consegne. Per questo bisogna avere l’accortezza di essere didascalici nello spiegare le attività durante la Retrospective;

 

– richiede conoscenza dei membri del team. Il tema deve essere comprensibile agli occhi dei partecipanti alla retro. Lo Scrum Master può essere autoreferenziale nella scelta degli argomenti, ma allo stesso tempo deve essere sicuro di rendere la metafora accessibile;

 

– rende l’attività difficilmente replicabile. Se un obiettivo è quello di avere delle attività pronte per essere riproposte in base agli eventi avvenuti in uno Sprint, le retro a tema complica sicuramente la vita.

 

Accogliendo questi effetti collaterali, le retro a tema sono delle opere uniche, sono il frutto di uno Scrum Master artigiano che dedica molto tempo alla cura del suo operato, piuttosto che alla sua riproducibilità in serie.

 

Di Sprint in Sprint le Retrospective a tema si stanno evolvendo, attraverso la sempre maggior conoscenza del team e all’utilizzo di nuovi strumenti.

Tutto questo per rendere l’evento stimolante e ludico senza perdere di vista il focus sull’obiettivo: incentivare il confronto.

Un confronto che oltre a essere efficace viene reso ricreativo e divertente.

 

Detto questo non mi rimane altro che concludere con un augurio, piuttosto che con un consiglio:

Buon lavoro e divertitevi!

 

Leggi gli articoli precedenti: 

 

Sprint Retrospective: le mie prime domande e risposte da Scrum Master

Sprint Retrospective: giocare per lavorare, la nascita delle board a tema

 

 

Di Riccardo Ciocci

 

La Sprint Retrospective, così come ogni evento Scrum, ha come fine ultimo il creare valore per chi vi partecipa.

Dopo aver capito l’importanza del why rispetto al what nel precedente articolo, i miei sforzi si sono concentrati al capire quale valore portare alla retrospective.

È facile leggere la guida Scrum per apprendere che le attività devono stimolare i membri dello Scrum Team al confronto, portare tutti a condividere quella opinione in più che fuori dalla retro non avrebbero espresso.

Come già anticipato nello scorso articolo, il tool principale che utilizzo per le attività di retrospective, su consiglio della mia mentore Anna Di Girolamo, è Mural.

Questo tool aiuta moltissimo l’apertura del team in quanto molto interattivo e di facile comprensione.

Ma come strutturare le attività da portare in fase di Retrospective?

In mio soccorso è arrivato una richiesta, quasi uno scherzo, che i Developers hanno chiesto ad Anna prima del mio arrivo:

“Anna, ma il nuovo Scrum Master ci fa giocare?”

Lì ho capito in che ambiente mi stavo inserendo e quale fosse il primo valore che dovevo dargli: la Retrospective non doveva essere una rottura.

La Retrospective non doveva essere una riunione ripetitiva dove forzatamente il team è obbligato a farsi le stesse tre domande nella stessa forma: Cosa è andato bene nello scorso Sprint? Cosa è andato male? Cosa facciamo per migliorare?

Fermo restando che queste sono le domande principali che ci si pone nella Retrospective, la principale innovazione che ho portato è stato il tone of voice di queste attività.

Dalla prima board per la Retrospective ho creato delle metafore per le attività strutturandole su un unico tema.

Quali temi? Ovviamente i più leggeri e divertenti. Dalle ricorrenze (Restrospective di Halloween, Natale, Capodanno, …), ai temi più disparati (Black Friday, Sanremo, banda di rapinatori, …) cercando sempre di trovare qualcosa di coerente a discorsi/eventi che accadono durante lo Sprint in corso.

Sulle attività si costruiscono metafore che siano coerenti con il tema proposto, seguendo preferibilmente uno storytelling.

Tutto questo per rendere le ore di Retrospective divertenti, creando un clima distensivo all’interno del team dopo la Sprint Review attraverso il gioco.

Cosa ha portato tutto questo? Lo vedremo nel prossimo articolo, dove vedremo esempi di attività e alcune reazioni dello Scrum Team.

Di Riccardo Ciocci

 

Trasparenza, ispezione e adattamento, questi sono i tre pilastri su cui si basa l’intero framework Scrum.

Gli Scrum Masters li studiano fin dalla prima certificazione, agli albori del loro percorso, ma assimilare questi concetti per riuscire a muovere i primi passi come parte di uno Scrum Team è un processo tutt’altro che banale.

Nel mio caso il passaggio dalla certificazione SMAC a Scrum Master di un team che lavora da remoto è stato breve ed improvviso. Ero affascinato dal framework ma ero pieno di domande che non trovavano risposta sulla Scrum Guide.

Naturale dunque che al mio primo task, la progettazione di una Sprint Retrospective, tante sono state le riflessioni che ho riportato alla mia mentore, nonché collega, Anna Di Girolamo:

– Cosa faccio per stimolare il confronto tra i membri del team senza chiederlo direttamente?

– Cosa propongo come attività per creare condivisione?

– Cosa devo ottenere dalla retrospective?

– Questa cosa va bene? Avrà questo effetto o quest’altro?

Queste le domande che mi ponevo. Cercavo indicazioni da Anna (Scrum Master del team ad interim prima del mio arrivo), in modo da poter ottenere soluzioni pronte da attuare.

A queste domande (come a tutte le domande che faccio tuttora) lei mi ha sempre detto:

“Risponditi prima tu.”

Se a primo impatto pensavo fosse un esercizio per verificare le mie conoscenze, dopo poco tempo ho capito il perché di questo feedback.

La Retrospective è in mia opinione l’evento di massima espressione dello Scrum Master, in quanto unico evento progettato e condotto da questo ruolo per il team. Questo è stato il momento in cui ho davvero compreso cosa vogliono dire i tre pilastri di Scrum. 

Non esistono regole del gioco al di fuori della (volutamente) scarna Scrum Guide. Tutto è basato su: cerco cosa hanno fatto gli altri, faccio qualcosa, verifico i risultati, adatto la prossima attività in base ai risultati. In una parola: empirismo.

Il secondo step è stato capire che non dovevo riuscire a trovare le risposte alle mie domande (a,b,c,d) ma riformulare le mie riflessioni, cambiare il focus.

Le mie domande hanno una parola in comune: cosa. 

Ero alla ricerca del cosa, volevo costruire materialmente la board delle attività, ma mi mancava una riflessione fondamentale a monte: il perchè.

Proponevo cose senza capire il perché volessi farle, senza avere chiaro quale valore volevo generare, quale valore stavo perseguendo io e quale invece volevo dare al team.

Ragionare sul why di ciò che si fa è alla base non solo delle attività dello Scrum Master o del Product Owner, ma è il primo motore che deve muovere tutte le pratiche fatte in Agile.

In conclusione, alle mie domande ci sono indicazioni utili per rendere più interattive le retrospective: io ad esempio consiglio Mural come piattaforma per organizzare le attività, o FunRetrospectives per avere spunti sulle best activities, ma a nulla servono se ciò non genera valore.

E allora come hai generato valore al team con la retrospective?

Questo lo vedremo nel prossimo articolo.