Molti sostengono che la retrospettiva sia la cerimonia più importante nella cassetta degli attrezzi di Agile. Woody Zuill la mette in questi termini: 

Se introduci una sola pratica #agile, questa dovrebbe essere la retrospettiva. Tutto il resto seguirà.

Woody Zuill

Allora perché è possibile che un team di sviluppo consideri superflua la retrospettiva di sprint? Secondo la mia esperienza di Scrum Master e psicologo, di solito questo ha a che fare con il livello di maturità del team.

Quindi, cosa puoi fare per migliorare la maturità del tuo team – in questo contesto e in generale? Ecco 7 riflessioni e 7 consigli che ti aiuteranno in questa sfida.

Il team ritiene che la retrospettiva sia superflua: cosa fare?

A proposito, la risposta ufficiale secondo l'esame di certificazione Scrum è questa: Lo Scrum Master dovrebbe lavorare sul team per renderlo più efficiente. Questo non mi aiuta molto. Cosa potrebbe significare?

Lo Scrum Master deve lavorare sul team per renderlo più efficiente.

Il ruolo ufficiale di uno Scrum Master è il seguente, se si guarda al Guida Scrum guarda: "Lo Scrum Master incoraggia lo Scrum Team a migliorare il proprio processo di sviluppo e le pratiche all'interno del processo Scrum per renderlo più efficace e piacevole per lo Sprint successivo".

In teoria, questo significa che la retrospettiva dovrebbe essere un evento centrale per lo Scrum Master, poiché lo scopo principale della retrospettiva è quello di aiutare il team a migliorare continuamente. Tuttavia, nella pratica, il team potrebbe non avere il livello di maturità necessario per utilizzare davvero una retrospettiva e quindi potrebbe non vederne il valore. Per questo motivo, personalmente interpreto l'affermazione "rendere il team più efficiente" a livello astratto come "aumentare il livello di maturità del team". Come si può fare in questo contesto? Prima di iniziare con i suggerimenti in merito, un'ulteriore spiegazione

Il retropensiero è considerato prezioso quando si migliora davvero in modo continuo. Allora il senso di autonomia, auto-organizzazione e auto-efficacia è alto. Il che porta all'ipotesi: La qualità percepita delle retrospettive è uno dei migliori indicatori del livello di maturità (agile) di un team. 

Se si vuole misurare il livello di maturità agile –, si dovrebbe utilizzare la qualità delle retrospettive come indicatore. Questa è la tipica correlazione temporale tra "qualità percepita della retrospettiva" e "maturità agile" di un team.

Questa progressione si ottiene come segue: 

1. Vengono eseguite le prime retros, vengono scritte le misure. La sensazione è che finalmente stia succedendo qualcosa! 
2. Le misure non vengono realmente attuate. Si parla molto, ma si agisce poco. 
3. Dopo un po' di tempo, si manifesta la frustrazione o semplicemente la cosiddetta "retro-fatica". Ora si presenta il fenomeno di questo articolo: La retrospettiva viene vista come superflua. Il team stesso si percepisce come relativamente maturo e non vede problemi.
4. Questo punto viene raggiunto solo da alcuni team. Ovvero, quando la qualità della retros aumenta di nuovo e alla fine porta a miglioramenti evidenti e quindi il sentimento di autoefficacia matura lentamente. 

Spero che i consigli di questo testo ti aiutino a fare qualche passo in questa direzione. Tuttavia, ti raccomando anche il nostro testo su "7 consigli per una buona azione", che svolgono un altro ruolo in questo problema.

1. capire perché il team pensa che una retrospettiva non sia necessaria

In qualità di Scrum Master potresti avere un'ipotesi sul perché il team ritiene che la retrospettiva di sprint non sia necessaria. Ma verifica questa ipotesi. Chiedi esplicitamente al team quali sono i retroscena.

Spesso nel team c'è un "opinion leader" che ha una grande influenza sul gruppo. Cerca di individuare questa persona, di capire il suo punto di vista e, nel migliore dei casi, di progettare insieme a lei delle contromisure (vedi sotto).

Quanto meglio conosci il team, tanto meglio potrai sviluppare un piano per aumentarne la maturità e scegliere il più appropriato tra i seguenti suggerimenti.

2. effettuare la retrospettiva

In pratica dovresti fare la retrospettiva. Supponiamo che il team abbia bisogno di più tempo per raggiungere l'obiettivo di sprint – e che un'ora di codifica al posto della retrospettiva possa essere fondamentale. In questo caso, va bene rimandare la retrospettiva di qualche giorno.

Puoi anche cambiare la natura della retrospettiva, renderla più breve e così via. Ma il modo migliore per dimostrare al team il valore di una retrospettiva è quello di avere una retrospettiva davvero buona. Quindi il mio appello è: assicurati di riservare uno spazio nel calendario del team per la retrospettiva.

3. misurare il valore ROTI

Non puoi cambiare ciò che non misuri. Un'abitudine semplice e veloce che ti aiuta a valutare costantemente come il team percepisce le retrospettive è quella di misurare il punteggio ROTI: il valore del "ritorno sul tempo investito". Basta porre la seguente domanda dopo ogni retrospettiva, magari come check-out: "Su una scala da 0 a 10, come è stato investito il tempo per questa retrospettiva?". Misura la media nel tempo – e speriamo che presto vedrai una tendenza positiva!

Il punteggio medio del "ritorno sul tempo investito" su una scala da 0 a 10 al mese nello strumento Echometer – Le retros valgono la pena? Sembra di sì!

4. mantenere la retrospettiva dello sprint molto breve

Quindi il team di sviluppo pensa che la retrospettiva dello sprint sia superflua – cosa dovresti fare ora come Scrum Master?

Come ho detto all'inizio, il team probabilmente ritiene che una retrospettiva di sprint non sia necessaria perché pensa che sia una perdita di tempo.

In altre parole: Nelle ultime retrospettive, a quanto pare, hanno "imparato" che il ROTI di una retrospettiva –, ovvero la qualità del tempo investito, vedi sopra –, è piuttosto scarsa. Esiste un approccio piuttosto semplice per cambiare questa situazione: basta investire meno tempo per ottenere lo stesso risultato.

Questo è forse il consiglio migliore se il team pensa che la retrospettiva di sprint non sia necessaria. Dì al tuo team: OK, la faremo il più breve possibile (per saperne di più leggi il nostro post "Breve retrospettiva – Meglio veloce che niente"). 

Importante: non devi segnalare che le cose rimarranno così per sempre. Il tuo messaggio rimane lo stesso: Le retrospettive sono davvero importanti. Prima o poi le retrospettive non saranno più così brevi.

Ma accorcia la retrospettiva (ad esempio da 60 minuti a 30 minuti) perché in questo modo il team impara quanto può essere importante investire il tempo. E lascia che la durata della retrospettiva cresca "organicamente", per così dire, grazie a una "spinta" o a un "desiderio" del team, perché a un certo punto vorrà più tempo per la retrospettiva. Come si fa? 

Non fai altro che porre la domanda più importante:

"Perché non siamo riusciti a completare tutte le user story previste per l'ultima iterazione?".

Questo porterà a discussioni intense e probabilmente a idee di azione in breve tempo. Potrebbe anche portare a discussioni più lunghe. Il team ha già segnalato di aver bisogno di più tempo per una retrospettiva (ovviamente il tuo compito è quello di mantenere la discussione costruttiva).

Dovresti sempre porre la domanda che pensi possa innescare buone riflessioni o discussioni nel team. E devi sempre avere l'obiettivo di registrare un esperimento che proverai nel prossimo sprint (noto anche come punto d'azione).

5. suggerisce di omettere anche altre routine

Quindi il team pensa che una retrospettiva sia una perdita di tempo. Ok. Come Scrum Master, il tuo obiettivo principale non dovrebbe mai essere quello di essere la persona che implementa Scrum. No, non si tratta di "Scrum". 

L'obiettivo è che il team abbia successo e fornisca valore al cliente e agli stakeholder. Scrum dovrebbe aiutare il team a farlo. Ma è solo un quadro di riferimento, una cassetta degli attrezzi (piuttosto buona) di molti approcci possibili per fornire valore in modo rapido, sostenibile e di alta qualità.

Quindi, se il team non è soddisfatto della retrospettiva, puoi sottolineare che vedi Scrum dalla prospettiva appena descritta. E poi aggiungi che pensi che alcune delle altre routine che avete siano meno importanti della retrospettiva. 

La retrospettiva è il motore del miglioramento continuo. È progettata per aiutare i membri del team a scoprire cosa ha funzionato bene e cosa no. Se tralasci questa parte del ciclo continuo, rischi di bloccare il ciclo di miglioramento continuo.

 

Cosa succederebbe, ad esempio, se si lasciassero fuori alcuni giornalieri? Sai cosa succederebbe? Forse non avrebbe alcun impatto – perfetto, allora puoi mantenerlo invariato e risparmiare tempo. 

D'altra parte, questo potrebbe anche portare a una scarsa comunicazione all'interno del team. Il team commette quindi degli errori. Alla fine, ci sarà una necessità organica di maggiore comunicazione, che noterai in retrospettiva. Questa volta, però, una cerimonia agile non viene introdotta su tua insistenza, ma a causa del "dolore" del team. Di conseguenza, il team accetterà molto di più questa cerimonia.

6. guardare alle retrospettive passate e dimostrarne il valore

Un approccio che può integrare gli altri è quello di esaminare la "storia retrospettiva" del team in un periodo di tempo più lungo. Il prerequisito è che alcune delle ultime retrospettive abbiano avuto successo.

Ad esempio, guardi la retrospettiva di un anno fa e ti rendi conto di quanto fossero difficili quelle sfide l'anno scorso. E poi ti rendi conto che sarebbe molto più facile risolvere le stesse sfide oggi se avessi tutte le conoscenze e l'esperienza che hai acquisito.

In altre parole: Ti rendi conto di quanto sei migliorato nel frattempo. Forse questo approccio di "miglioramento continuo" potrebbe funzionare, dopotutto! E le retrospettive possono davvero aver giocato un ruolo importante in questo senso. Se usate correttamente, possono certamente portare a un momento "aha" nel team.

Inoltre, puoi anche esaminare il valore del ROTI (ritorno sull'investimento di tempo) della tua ultima retrospettiva (vedi sopra): Se puoi dimostrare che la retrospettiva ha un ROTI compreso tra 8 e 10, il tempo è stato ovviamente ben investito. Il nostro strumento di retrospettiva Echometer, ad esempio, esegue una ricerca sul ROTI dopo ogni retrospettiva e ti fornisce così un indicatore regolare delle prestazioni. Prestazioni di te come Scrum Master.