5 livelli di feedback in Scrum

5 livelli di feedback in Scrum aiuta a capire uno dei problemi principali che osservo nei team che praticano Scrum, cioè la qualità del feedback ricevuto sul lavoro fatto durante lo Sprint. In questo articolo ti invito ad esplorare 5 livelli di feedback in Scrum, dal meno efficace al più efficace per uno sviluppo empirico di prodotto.

Nel seguito dell’articolo parlo spesso di Sprint Review, segui il link se non sai cos’è o vuoi rinfrescarti la memoria!

L’articolo è disponibile anche in versione audio sul nostro podcast

1 – Persone disinformate

Al livello meno efficace di feedback posiziono i team che invitano in Sprint Review delle persone interne all’azienda. Queste persone, quando si presentano all’evento, non sanno cos’è Scrum e perché partecipano (sigh). Ma visto che in azienda non è visto di buon occhio rifiutare una riunione, vengono con il computer e lavorano invece di partecipare.

lo Scrum Team, in generale, non riesce a coinvolgere i presenti e non capisce perché la magnifica presentazione power point non sta avendo successo.

La conclusione è tanta frustrazione per il team che non ottiene feedback di qualità e per i partecipanti, che continuano a non capire perché sono stati invitati ed hanno la sensazione di aver perso del tempo.

Rimaniamo su una nota positiva: spesso questo capita ai team che sono agli inizi con Scrum. Quindi anche il livello 1 di feedback è un buon inizio, da migliorare rapidamente!

2 – Stakeholders Feedback

Il team ha capito che i partecipanti alla Sprint Review devono sapere quale contributo possono dare. I partecipanti rimangono esclusivamente dipendenti dell’azienda, in generale manager ai quali il team deve rendere dei conti.

Un miglioramento che puoi sperimentare, è quello di introdurre la Sprint Review spiegando ai partecipanti perché sono stati invitati. Idealmente iniziando dall’invito calendario, fino ad occupare i primi dieci minuti dell’evento, l’aspetto pedagogico è importante.

Le aspettative ed i vincoli per partecipare devono essere chiari. Le persone presenti sono invitate a prestare massima attenzione, oppure autorizzate a non partecipare. Se il computer non è indispensabile, specifico che non è necessario portarlo con sé 😙… se l’evento si svolge a distanza, telecamera accesa per tutti e facilitazione inclusiva dell’evento.

Se hai bisogno di migliorare la tua capacità a facilitare gli eventi Scrum (in presenza o a distanza), puoi dare un’occhiata a questo corso.

Lo Scrum Team, invece di preparare una presentazione Power Point, fornisce a tutti i partecipanti l’ultima versione del prodotto, che sarà utilizzata dai partecipanti per fornire feedback.

Fra lo step 1 e 2 possono passare diversi Sprint, è importante fare questo miglioramento il più rapidamente possibile.

3 – User Feedback

Per Scrum uno Stakeholder è qualsiasi persona esterna alla Scrum Team. L’utilizzatore del prodotto è un tipo di Stakeholder particolare. La persona che ci interessa di più dal punto di vista del feedback. Dobbiamo capire rapidamente se il lavoro fatto ha creato valore come l’avevamo ipotizzato.

Questo è uno step importante e molto spesso mancante in uno Scrum Team. Non avere utilizzatori in Sprint Review limita in maniera considerevole lo sviluppo empirico del prodotto e, di conseguenza, l’efficacia di Scrum.

Sento una vocina alzarsi e dire: “si ma, Fabio, per noi è impossibile avere degli utilizzatori in Sprint Review”… ok allora lo Scrum Team deve chiedersi come poter ottenere un feedback di qualità in modo asincrono.

Di conseguenza, dovete trovare il modo di arrivare in Sprint Review con gli utilizzatori del vostro prodotto, oppure con i dati generati durante lo Sprint che parlano per i vostri utilizzatori.

Il feedback utilizzatore è alla base dello sviluppo empirico dei prodotti e quindi di Scrum. Lo ripeto, perché è importante.

4 – Osservazione dell’utilizzatore

Ma si può fare meglio… osservare l’utilizzatore, capire come usa il prodotto. O come vorrebbe utilizzarlo.

Non c’è niente di peggio per un utilizzatore di doversi adattare ad un prodotto mal pensato, che non tiene conto delle necessità dell’utilizzatore.

Un’altra esperienza: nello sviluppo di uno smartphone per agenti pubblici (polizia, pompieri, ecc.), abbiamo fatto tutti i test dell’altoparlante in laboratorio. Il volume dell’altoparlante era alto, il team e gli stakeholders in Sprint Review erano soddisfatti.

Alla prima utilizzazione in un incrocio pieno di traffico, con il volume al massimo, si faceva fatica a capire cosa dicesse il nostro interlocutore!

Dall’esperienza raccontata in precedenza, con il team, abbiamo capito quanto importante fosse avere feedback, ma non solo, essere anche in condizioni reali ed osservare l’utilizzatore per poter confermare la creazione di valore!

5 – La prova del mercato

Il livello più avanzato di feedback, lo si ottiene grazie ai dati relativi all’utilizzo del prodotto ed alle sue funzionalità, alle vendite e relativi guadagni generati.

La prova del mercato è assolutamente indispensabile nello sviluppo empirico di un prodotto. Purtroppo, in certe aziende nelle quali c’è la cultura del prodotto finito (!!!), ho spesso assistito a battaglie interne per impedire la vendita di prodotti considerati non finiti. Senza che nessuno sapesse darmi la definizione di prodotto finito (sigh).

In questo caso l’azienda si espone agli stessi rischi di uno sviluppo waterfall: si usa Scrum per sviluppare tante ipotesi, mai confermate dal mercato e si rilascia in produzione dopo un anno o due di sviluppo. È chiaro che questo modo di fare elimina i benefici di Scrum e dello sviluppo empirico di un prodotto.

Per esempio, nemmeno noi da Collective Genius, nelle Sprint Review del podcast Scrum Italia, abbiamo gli ascoltatori presenti. Però abbiamo i dati degli ascolti passati, facciamo esperimenti per capire in quali episodi abbiamo più ascolti. Abbiamo più ascolti sulle interviste? Oppure quando leggo gli articoli del blog? Quale durata è migliore? Ecc.

Non aspettiamo di aver registrato 1000 episodi per poi cominciare a pubblicarli, ne abbiamo 2/3 in stock (quando va bene) e per il resto ci affidiamo agli ascolti per decidere cosa fare.

5 livelli di feedback in Scrum – Empirismo e Scrum

Quindi, per ricollegarmi al punto precedente, anche questo è un caso di osservazione che può avvenire attraverso dati generati dal prodotto, non necessariamente da interviste dell’utilizzatore o una sua partecipazione in Sprint Review.

Ma bisogna pensarci, capirlo ed implementare le sonde corrette nel prodotto.