O sei Re Mida o sei un proxy !
Aprile 2, 2023AgileTalks
Aprile 2, 2023
La Sprint Review
di Andrea Feraco
Versione PDF “Pretty”
https://agileitalia.agileforitaly.com/index.html#1_2019
La Sprint Review, secondo la guida Scrum, si tiene alla fine dello sprint per ispezionare l’incremento del prodotto appena sviluppato nello sprint e, se necessario, adattare il backlog.
La guida Scrum introduce e sintetizza l’evento della review con questa semplice ma potente descrizione.
Subito dopo la guida continua sottolineando che si tratta di un momento di collaborazione fra i partecipanti, collaborazione finalizzata a decidere l’ordine delle prossime cose da fare per ottimizzare il valore da rilasciare.
Per un team molto esperto nell’adozione di Scrum, il paragrafo sulla Sprint Review potrebbe anche finire qui, c’è tutto il senso della review e ogni team può essere libero di implementare lo svolgimento della review come meglio crede. In realtà mi chiedo quanti siano i team in giro per il mondo che comprendano il significato della review secondo queste prime frasi riportate nella guida Scrum.
Diciamoci la verità!
Quanti di voi che state leggendo pensano che la review sia solo una demo, una dimostrazione a stakeholder, utenti, del lavoro fatto nello sprint, una sorta di stato avanzamento lavori magari un po’ più trasparente rispetto ai SAL di una volta?
Schwaber e Sutherland, gli autori della guida Scrum, proprio per aiutare i team a implementare i principi fondamentali della review, hanno pensato bene di aggiungere altro contenuto al paragrafo sulla Sprint Review fornendo una lista di punti che possono aiutare un team a organizzarne lo svolgimento. Molti di questi punti (potete andare a leggerli online https://www.scrumguides.org/scrum-guide.html#events-review) effettivamente li riscontro, nella mia esperienza, partecipando alle review di diversi team.
Voglio però focalizzarmi sugli ultimi due punti riportati al paragrafo sulla Sprint Review:
Rivedere come il mercato o il potenziale utilizzo del prodotto potrebbero spingere a cambiare quale sarà la prossima attività di maggior valore da fare
Rivedere la pianificazione, il budget, le capacità potenziali e il mercato per decidere l’obiettivo del prossimo rilascio di funzionalità o capacità del prodotto
Raramente, molto raramente, ho visto discutere questi aspetti in una review nei termini descritti nella guida, anzi immagino che in molti trovino “strani” questi due punti, eppure forse sono quei due punti che qualificano maggiormente un team come realmente agile, specialmente quei team che sviluppano prodotti per il mercato e non possono accedere al feedback diretto del cliente/utilizzatore finale.
Leggendo l’ultimo libro di Jurgen Appelo, “Startup, Scaleup, Screwup” l’autore ci dice che ogni attività fatta da un team (chiamiamola storia, feature, elemento, come preferiamo) dovrebbe essere collegata a una o più metriche che ci consentano di avere una misura se l’obiettivo che si voleva raggiungere con quell’attività sia stato più o meno centrato. Normalmente la metrica potrebbe essere legata a un parametro di mercato, come l’aumento delle vendite, l’aumento dell’utilizzo di certe funzionalità del prodotto, l’aumento del cross-selling (sto elencando giusto degli esempi, in ogni singolo contesto si dovrebbe cercare la metrica più adatta).
Chi la stabilisce questa metrica?
La mia opinione è che debba essere lo Scrum Team a decidere, certamente con un forte input da parte del Product Owner ma in collaborazione con tutto il resto del team.
Ribadisco la centralità dello Scrum Team: persone esterne al team, ad esempio gli stakeholder, i clienti, potrebbero far emergere indicazioni sulle metriche più importanti, ma è il Product Owner insieme al resto del team che deve scegliere metriche e obiettivi. Una volta stabilite le metriche, le misurazioni vengono discusse in review con gli stakeholder per capire se le scelte fatte si stanno rivelando corrette oppure no, efficaci oppure no, e di conseguenza cambiare le priorità in funzione dei feedback misurati dal mercato.
È il cardine fondamentale dell’agile quello di avere cicli di feedback corti.
In alternativa quello che succede è che si seguono le pratiche suggerite da Scrum, magari nella maniera più bella possibile, ma concretamente non si farà altro che seguire un piano che non viene mai modificato, il feedback non lo si cerca, il cambiamento non lo si attua e quindi vincerà l’anti-valore “seguire un piano più che rispondere al cambiamento”.
Attenzione che questo accade senza accorgersene, pienamente convinti di essere agili!
Le roadmap, il budget, sono cose importanti da tenere in considerazione. Ma dobbiamo sempre ricondurle al vero valore del manifesto, ossia “rispondere al cambiamento più che seguire un piano”. Penso che accada in molte realtà aziendali che la negoziazione sulle roadmap e sul budget avvenga spesso nel chiuso di alcune riunioni, mentre la guida ci suggerisce, in accordo al pilastro della trasparenza, di far emergere durante la stessa review la discussione su questi temi. Quante volte le persone di un team sentono lo stress di sfuggire al cambiamento perché temono che possa avere un impatto sulla roadmap? Quante volte un team si sente dire che sta terminando il budget, di cui sapevano poco o nulla, e viene chiesto loro di trovare soluzioni magari stravaganti per chiudere lo scope tenendo fermi costi e tempi? Se invece tutto questo venisse discusso davanti a tutti in pieno spirito collaborativo, ad esempio durante la review, potremmo veramente dire che l’agilità si vede e si tocca con mano.
In conclusione
Vorrei proporre una modifica alla guida Scrum, scriverò agli stessi Schawber e Sutherland, chiedendo di modificare l’ordine dei punti da affrontare durante la Sprint Review portando in alto i due punti visti prima, nella speranza che chi prova a utilizzare Scrum nel senso di volere abbracciare un approccio che aiuti nello sviluppo dell’agilità di un’organizzazione, focalizzi la propria attenzione sul senso vero dell’agile e non sulla semplice, formale, ma alcune volte sterile, implementazione di una Sprint Review, e in generale dell’intero framework Scrum.
La scrum guide non è solo una guida di un framework ma è la chiave di lettura di un mindset” (cit.)
Agile Manager
