Introduzione: il ruolo dello Scrum Master
Ispirandoci dal libro di Hermann Hesse, Il pellegrinaggio in Oriente [1], siamo soliti dire che lo Scrum Master è il servant leader di un team. Significa che si tratta di un leader impegnato a “far sì che le cose succedano”, completamente dedito alle necessità del team, concentrato sulla risoluzione di tutti i problemi, pronto a far avere al gruppo di lavoro tutto ciò di cui essi hanno bisogno per lavorare meglio.
Pur servendo tutti, non è uno schiavo che deve obbedire senza chiedere ragione: è piuttosto un elemento complementare del team di sviluppo, sullo stesso piano degli altri componenti.
A superare il concetto di servant leader, si sta progressivamente affermando quello di host leadership. La host leadership può essere considerata una sorta di “leadership situazionale” il che si può tradurre in “Scegliere lo stile di leadership più adatto sulla base delle situazioni e delle persone”. Non approfondiamo ulteriormente il tema, che è già stato trattato più volte su queste pagine; per chi non conoscesse il concetto e fosse interessato a farsi un’idea dei vari stili di leadership, raccomandiamo la lettura dell’articolo di Fabio Ghislandi pubblicato sul numero di febbraio 2017 [2]
Il mestiere di Scrum Master
Ma, in pratica, cosa signfica “Fare il facilitatore” o “Rimuovere gli impedimenti” o “Supportare la crescita del team”? In fin dei conti, che cosa fa uno Scrum Master nelle sue giornate in ufficio, durante la sua vita lavorativa? Ecco, questa serie ha come tema portante proprio il tentativo di spiegare questa figura attraverso le sue attività tipiche (e anche meno evidenti) con un approccio pragmatico fatto di esempi, tecniche, strumenti e consigli.
Cominceremo con l’esaminare un elenco di responsabilità e di compiti che fanno parte del “mestiere” di Scrum Master, rispondendo ad alcune tipiche domande sul modo in cui lo Scrum Master possa essere al tempo stesso servan leader, facilitatore e coach. Per farlo, partiamo dall’immagine in figura 1, già pubblicata in Guida Galattica per Agilisti [3].
Scrum Master come Agile Coach
Per fare il coach agile — attività piuttosto complessa — occorre miscelare opportunamente il lavoro di formatore che spiega teorie, quello di consulente che suggerisce soluzioni e quello di coach che pone domande e consente a nuove idee e soluzioni di emergere direttamente dal campo. Qualche volta, quando il team necessita per un po’ di essere guidato, prende il volante e comincia a condurre “l’automobile del team agile”.
È solo quest’ultimo caso quello in cui ha senso fornire soluzioni “pronte” che derivano dalla sua esperienza con altri team o contesti differenti. Ma quando si capisce che il team è in grado di guidare da solo l’automobile — per restare alla nostra metafora — il coach agile smette di suggerire soluzioni e dare risposte, e passa invece a fare domande e a supportare il gruppo nella definizione dei propri obiettivi e della roadmap per raggiungerli.
Dal momento che non è genericamente un coach ma specificamente un Agile Coach, dovrebbe conoscere i valori e i principi del Manifesto Agile [4] per abilitare lo sviluppo agile di prodotti, i ruoli e gli eventi di Scrum, le tecniche per scalare o per fare envision di prodotto.
A volte ci viene chiesto quale sia la differenza tra uno Scrum Master e un coach. Se diciamo che “uno Scrum Master deve anche essere un coach”, intendiamo che deve essere in grado di svolgere attività di coaching con le persone, facendo riferimento alle classiche definizioni di business coach o life coach.
E però c’è anche il concetto più ampio di Agile Coach, che va oltre questo. Un coach agile è uno Scrum Master con molti anni di esperienza, che ha lavorato in molti progetti e condotto molte “trasformazioni” aziendali. Un Agile Coach è quindi, al tempo stesso, uno Scrum Master, un coach, un consulente, un esperto di Product Ownership, Project Management e svariati altri campi…
Scrum Master come promotore della metodologia
Lo Scrum Master promuove e supporta l’adozione della metodologia agile. Per questo deve conoscere i fondamentali di Scrum — e anche le basi di Kanban — in modo da poterli spiegare al team o da poter mettere in luce qualsiasi differenza che si evidenzi rispetto al metodo ufficiale.
Deve aiutare i membri del team a implementare i ruoli, gli eventi e gli “artifacts”, spiegando come si realizzano e si usano.
E quindi deve conoscere esattamente che cosa fa un Product Owner, o quali sono le responsabilità di uno sviluppatore. Deve conoscere gli strumenti — tool software, lavagne fisiche, irradiatori di informazione come il product burn down chart… — e le modalità per raccogliere dati e avere un quadro generale dei lavori. Sebbene la compilazione e l’aggiornamento di tali strumenti sia un lavoro collettivo per tutto il team, lo Scrum Master si focalizza sul rendere tutte le informazioni raccolte con questi tool disponibili per tutti.
In questo contesto, il suo lavoro è molto utile al Product Owner, dal momento che prepara report e information radiators e che condivide questi dati con gli stakeholder, in modo da condividere conoscenze o rimuovere impedimenti.
Scrum Master come facilitatore
Lo Scrum Master può facilitare la conversazione tra i membri del team durante lo Sprint Planning, oppure lasciarli esprimere liberamente durante una retrospettiva. Fa rispettare i tempi e le fasi delle conversazioni, funge da moderatore, favorisce la negoziazione tra le diverse opinioni.
I meeting devono concludersi con una visione comune sull’argomento, in modo da prendere delle decisioni che possano tramutarsi in comportamenti pratici (actionable decisions) oppure sperimentare nuove idee condivise. L’obiettivo dello Scrum Master sono meeting proficui, in cui tutte le persone possano esprimersi e contribuire, e in cui tutti gli argomenti siano affrontati apertamente in maniera da produrre risultati che possano essere tradotti in azioni pratiche.
Scrum Master come “data owner” (raccolta di informazioni e statistiche)
Durante uno Sprint, il team produce tanti dati che potrebbero risultare utili se raccolti e ordinati in qualche forma più “leggibile”.
La Sprint Velocity come metrica per valutare il team non è una buona idea; ma potrebbe ad esempio risultare più interessante e utile trovare, se c’è, una correlazione tra la velocity e gli impedimenti esterni, oppure tra il numero di elementi che devono essere rilavorati e gli item che risultano senza problemi già al primo tentativo.
Potrebbe essere più interessante osservare l’impatto dei risultati del tempo totale trascorso fuori dal team: per esempio, si potrebbero contarel le ore che ciascun componente del team passa su altri progetti o su compiti diversi rispetto a quelli “canonici” e valutare se poi è in grado di rispettare le scadenze.
Invece che limitarsi a misurare la mera Velocity in quanto tale, potrebbe essere più interessante confrontare la differenza tra le previsioni e i punti sprint effettivamente completati (velocity vs. capacity). Si tratta di quella che chiamiamo “autopercezione del team”: più i componenti del team conoscono loro stessi, più sono capaci di comportarsi in maniera conseguente e di trovare nuove azioni per migliorare ulteriormente.
Raccolta dei dati e statistiche
Quello della raccolta dei dati a scopi “statistici” è un aspetto importante di cui ogni Scrum Master dovrebbe prendersi carico durante il lavoro con il team. L’obiettivo è quello di raccogliere tutte le informazioni e i dati che potrebbero essere necessari al team per prendere decisioni: per esempio, i punti e la velocity sono utili al gruppo di sviluppatori per decidere quanti elementi prendere in carico per lo Sprint; l’impatto delle ore “fuori progetto” diventa un dato importante per decidere cosa fare quando ci sono svariati progetti che “insistono” sul team. Le tendenze nel rilascio o il lead time possono risultare utili al Product Owner per pianificare una roadmap o per stabilire le corrette priorità negli item del backlog.
Di fatto, ci sono tanti “numeri” che possono essere usati per immaginare nuovi esperimenti o nuove modalità per rilasciare valore al cliente. In uno dei prossimi articoli di questa serie, approfondiremo quest’argomento, fornendo alcuni esempi di quali dati raccogliere e di come utilizzarli.
Scrum Master come esperto di retrospettive
Dal momento che agile è miglioramento continuo, lo Scrum Master aiuta il team a migliorare continuamente. Oltre che tramite altre pratiche, ciò viene effettuato principalmente facilitando retrospettive efficaci.
Per quanto questa competenza rimanga sotto l’ombrello della facilitazione, in questa serie riserveremo alle retrospettive uno spazio dedicato, vista la loro importanza. Vedremo che cosa è una retrospettiva (tipologie, fasi, strumenti) e come facilitarla (diversi approcci e quando impiegarli). Si tratta di un tema molto consistente: speriamo di riuscire a fornire un quadro d’insieme e qualche consiglio approfondito.
Scrum Master come “formatore”
Non intendiamo la parola “formatore” in senso classico di insegnante, ma piuttosto come una figura che aiuta le persone a imparare e a migliorare. E, ultima come citazione ma non come importanza, lo Scrum Master si concentra anche nell’aiutare il team, e tutta l’organizzazione, a comprendere meglio la filosofia agile, l’infrastruttura metodologica Scrum, Kanban e tutti gli strumenti.
Potrebbe organizzare sessioni di addestramento su alcuni concetti Scrum tipo “In che modo si fanno le stime?”. Oppure su strumenti di gestione, per capire “come gestire lo Sprint usando Jira”. E oltre a questo, potrebbe raccogliere informazioni sulle cose che ci sono da imparare, per creare dei percorsi di carriera o delle matrici delle competenze che possano aiutare le persone a migliorare in una data attività, o ad apprendere qualche nuova competenza, o a impadronirsi dell’uso di qualche nuovo tool.
Conclusioni
Per queto mese ci fermiamo qui, ma diciamo sunito che tutti i vari punti elencati in quest’articolo saranno trattati più approfonditamente mese dopo mese negli articoli successivi della serie. Per quanto nulla sia scolpito nella pietra — dopotutto siamo agili e nell’agilità il cambiamento è benvenuto — nei prossimi articoli parleremo quindi di Agile Coaching, diffusione dei metodi agili nell’organizzazione, facilitazione, dati e statistiche, retrospettive, apprendimento per il miglioramento continuo.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.