In Scrum i membri del Team lavorano insieme per raggiungere obiettivi condivisi, in un ambiente di responsabilità collettiva e progresso continuo.
Nel nostro ultimo webinar abbiamo approfondito con l’esperta Antonietta Fiorentino il ruolo di Scrum Master all’interno del Team Scrum. Abbiamo ricevuto tante domande ed abbiamo deciso di creare un post con le risposte di Antonietta, in modo che possa essere ancora più chiaro il ruolo di Scrum Master e di tutti i membri del team Scrum!
1) Quanto è importante la competenza tecnologica dello Scrum master? A volte può sembrare un semplice motivatore con competenze gestionali piuttosto che informatiche, oppure è l’anello di congiunzione tra il product owner ed il team?
Leggendo con attenzione la guida a Scrum di Ken Schwaber e Jeff Sutherland non troviamo nessun riferimento a competenze “Tecnologiche” dello Scrum Master. Ma è possibile che lo Scrum Master faccia parte anche del Development Team.
2) I clienti accettano senza problemi di pagare il team scrum per un periodo determinato senza però la certezza del risultato finale?
Se si è abituati a fare Procurement attraverso contratti a “Scope Fisso” può essere difficoltoso cambiare anche se l’obiettivo è quello di cogliere un’opportunità. Ricordiamo che Agile è una forma mentis. Quindi è necessario da parte di tutti (Cliente/Fornitore) evolvere; da un approccio “closed”, con bassa condivisione esterna, bisogna gradualmente passare a un approccio “open”, basato su un ciclo di learn-share-collaborate-improve, per favorire lo scambio ed il trasferimento di conoscenza secondo modalità non convenzionali.
3) Che responsabilità ha usualmente lo Scrum Master nell’ambito del controllo dei costi e tempi di un progetto?
Lo Scrum Master ha tante responsabilità (hai già letto il post: Scrum Master chi è e cosa fa?), ma tra queste non ci sono item che riguardano nello specifico la gestione dei vincoli di progetto Tempo & Costi. È una responsabilità condivisa di tutto lo Scrum Team. Ricordiamo che Tempo & Costi sono fissi e che lo Scrum Team deve essere “Bravo” a fissare lo Sprint Goal.
4) Se per più sprint, e dopo i primi 3 sprint ancora, non si raggiunge l’obiettivo dello sprint, questo rappresenta un fallimento per lo scrum master? E che approccio dovrebbe tenere lo scrum master in tale circostanza?
La situazione descritta non è un fallimento per lo Scrum Master ma è sicuramente da considerarsi motivo di riflessione per tutto lo Scrum Team; i temi su cui riflettere potrebbero essere:
– cosa non abbiamo capito del progetto/prodotto?
– esiste un Gap tecnico di conoscenza da colmare?
– i cambiamenti interni/esterni al cliente rendono obsoleto il goal dello sprint in maniera sistematica?
Qui puoi conoscere le responsabilità degli altri membri dello Scrum Team: lo Scrum Developer e lo Scrum Product Owner .
5) Ma se durante gli sprint non si raggiungono gli obiettivi, i tempi non si allungano? E quindi anche i costi aumentano?
Quando l’approccio è Predittivo nelle prime fasi del progetto ci si concentra a dettagliare la pianificazione basando le stime sullo Scope definito nei documenti formali (approccio plan-driven). Durante il ciclo di vita del progetto il Piano di progetto sarà la guida di gestione del lavoro e il riferimento per il calcolo dell’avanzamento. I cambiamenti sono gestiti attraverso un sistema formale ed il valore viene generato alla fine del progetto, al momento della consegna del prodotto finale.
Quando, invece, i requisiti sono instabili più che tentare di fissare a priori le caratteristiche del prodotto, determinando di conseguenza tempi e costi di realizzazione (approccio plan-driven), è meglio focalizzarsi sul prendere decisioni che diano priorità, e quindi precedenza temporale, alle attività a maggior valore aggiunto e alle azioni di maggiore riduzione del rischio (approccio value-driven), fissando in anticipo budget e tempi e rendendo lo scope di progetto negoziabile.
Quando l’approccio è adattivo, dunque, la pianificazione viene realizzata in modo iterativo prima di ciascuno Sprint/Iterazione. Questa modalità permette di rispondere in maniera veloce ed efficace al cambiamento, con conseguente riduzione dei costi e, in definitiva, aumento della redditività e del Ritorno sull’Investimento (ROI). In termini più generali, si passa da un modello “inside out”, dove realizzi e vendi il tuo prodotto sul mercato, ad un modello “outside in”, dove costruisci iterativamente il prodotto/servizio assieme al tuo cliente. Si parla di Minimum Viable Product (MVP).
6) In fase di Sprint Retrospective partecipa anche il PO? Se si, che ruolo ha nei confronti nel team di sviluppo?
L’Agile Business Consortium “consiglia vivamente” la presenza del PO durante lo Sprint Retrospective meeting; come tutti i membri dello Scrum Team fa introspezione e partecipa attivamente con l’obiettivo del continuous improvement.
7) Cosa deve dire il PO durante il daily? Non è da ostacolo allo Scrum Master nel facilitare la disinvoltura del team?
Il Product Owner potrebbe essere un membro del Team di sviluppo. Questa è una situazione perfettamente praticabile e in tali circostanze il PO può ovviamente partecipare e partecipare pienamente ai Daily Scrum.
Se invece il PO non fa parte del Team di sviluppo esistono diverse scuole di pensiero. Ad es. Agile Alliance suggerisce di mantenere il PO fuori dal Daily Meeting, Agile Business Consortium invece consiglia la partecipazione del PO e suggerisce al Team di Sviluppo di invitare il PO (è una buona idea per condividere le scelte e il commitment).
Hai già scaricato l’articolo “Scrum: 10 risposte alle vostre domande”? Alcuni degli argomenti trattati nell’articolo: sprint, review meeting, retrospective meeting, user story, ruoli in Scrum, daily scrum meeting.
Leggi anche: Le 5 regole per uno stand-up meeting Agile e impeccabile
Hai altre domande? Scrivici a italy@qrpinternational.com
