Qualche giorno fa stavo osservando una Sprint Retrospective. Lo Scrum Team ha deciso di lavorare sulla definizione di “Done” (DoD), il punto più importante da adattare per il prossimo Sprint. Le discussioni sono state aperte e animate, quando è emerso un’argomento inaspettato durante la sessione.
Due nuovi sviluppatori hanno recentemente integrato il DevTeam, ora composto da cinque persone. La crescita del gruppo ha cambiato le dinamiche, aggiungendo complessità e la necessità di una revisione della Definizione di “Done”.
Lo Scrum Master ha invitato Product Owner e DevTeam a generare idee per il DoD. Molti post-it sono stati generati e condivisi, alcuni molto dettagliati, altri meno. Successivamente, la discussione si è bloccata sul livello di precisione della documentazione, soprattutto a scopo di test.
La domanda era: quanto dovrebbe essere precisa e dettagliata la DoD? Dovremmo essere specifici, ad esempio: “test di non regressione documentati, convalidati da un collega, esecuzione e risultato memorizzato nella cartella XY”. Oppure una frase del tipo: “test di non regressione” potrebbe essere sufficiente?
La risposta a questa domanda è, naturalmente, qualunque sia la decisione collegiale del Product Owner e del DevTeam, purché migliorino continuamente attraverso l’ispezione e l’adattamento.
A questo punto, inizia una conversazione inaspettata tra i membri del DevTeam: uno di loro sosteneva che scrivere semplicemente “test di non regressione” non avrebbe garantito che il collega eseguisse test abbastanza “buoni” e “significativi”. Avrebbe potuto semplicemente fare qualcosa per sbarazzarsi del test e passare a quello successivo.
In quel momento, un’allarme suona nella mia mente e un neon rosso lampeggiante con le lettere “F I D U C I A” inizia a lampeggiare … (sì, a volte accadono cose strane nella mia mente :-))
Partendo dal presupposto che il DevTeam è un gruppo di professionisti che sono auto-organizzati per creare un Incremento “Done” alla fine di ogni Sprint, se non sono in grado di concordare una definizione di “Done” e usano una formulazione del tipo “come posso sapere se hai fatto davvero un buon test” è, a mio parere, la prova che il problema è probabilmente basato sulla fiducia nel lavoro degli altri membri del team.
Ho convalidato la mia ipotesi della situazione con alcune domande aperte. Ora so che devo aiutare il DevTeam a ripristinare la fiducia per diventare di nuovo efficace. Quello che era iniziato come una discussione sulle definizione di “Done”, ha rivelato finalmente un problema più profondo: una mancanza di fiducia tra i membri del DevTeam.
Sono fiducioso che questa squadra supererà queste difficoltà e sarà un DevTeam ad alte prestazioni in fretta!
Da ricordare
- Controllate il livello di fiducia, sempre. Spesso questo è IL problema. Potete controllare il mio articolo “Un workshop per scoprire i Valori di Scrum” per le idee
- I cambiamenti nella composizione del team possono influire sulla sua produttività, leggere le fasi di sviluppo del gruppo di Tuckman per saperne di più.
- Imparate ad identificare dove si trova il vero problema, il comportamento delle persone e il loro linguaggio.
- Attenetevi allo Scrum Guide e alle regole del gioco (specialmente se siete meno esperti) molte volte, questo è il punto di partenza delle mie spiegazioni.
