Vita da Scrum Master

III parte: Tra tradizione e innovazione. Meccaniche di base, sperimentazione e metrichedi

Introduzione

Se è vero che in Scrum il Product Owner è “proprietario” del backlog, nel senso che ha responsabilità del contenuto del Product Backlog, analogamente lo Scrum Master è owner del processo Scrum, nel senso che supporta il team nell’implementazione di Scrum. Spetta allo Scrum Master, infatti, spiegare l’infrastruttura metodologica (ruoli, eventi, “manufatti”) al resto del team, cercando al contempo di diffondere i valori e i principi dell’Agile Manifesto e la mentalità Agile. E facendo capire anche quando abbia effettivamente senso applicare un processo di produzione ispirato a tali principi.

Sebbene non sia un “legistlatore” che detta le regole o un “giudice” che valuta l’applicazione dello Scrum, lo Scrum Master dovrebbe comunque sempre essere in grado di raccontare cosa dice la Scrum Guide [1], ossia quali sono le raccomandazioni ufficiali del framework, stimolando al contempo il pensiero critico nel team senza influenzarne le decisioni. Un tipico approccio potrebbe essere:

Scrum raccomanda di fare questa cosa in questo modo. Stiamo invece dicendo che vorremmo provare a farla in modo differente. Cosa ci aspettiamo che succeda? Perché vogliamo farla in modo differente? Ma soprattutto, perché non ci piace quello che raccomanda la guida ufficiale?

Lo Scrum Master deve quindi sforzarsi ad aiutare il team nel bilanciare tradizione e innovazione: da un lato il team è totalmente autonomo nel prendere decisioni, variare qualcosa, fare esperimenti; dall’altro, occorre ricordare ogni volta che le regole di Scrum sono più che altro raccomandazioni basate su anni di esperienza dal campo e conseguenti affinamenti: ogni variazione o modifica dovrebbe prima di tutto considerare “Cosa non ci piace della metodologia ufficiale? E perché?”.

Lo Scrum Master deve quindi aiutare il team a implementare le meccaniche di base di Scrum ma, al contempo, supportare gli esperimenti (dovrà aiutare a progettare esperimenti, si veda oltre).

Lo Scrum Master e le meccaniche di base

In gergo, le meccaniche di base di Scrum sono gli eventi ufficiali — ma anche le pratiche non contemplate nella guida ma comunemente diffuse —, i ruoli e le relative responsabilità, gli strumenti.

Per questo lo Scrum Master dovrebbe prima di tutto facilitare gli eventi Scrum.

Sprint Planning

Allo Scrum Master spertta supportare l’esecuzione dello Sprint Planning, facilitare la discussione, ad esempio per inserire gli elementi nello Sprint Backlog, aiutare a considerare numeri e statistiche degli altri sprint per agevolare la discussione comparativa (si veda più avanti).

Sprint Review

Lo Scrum Master deve inoltre organizzare le attività di preparazione e conduzione della Sprint Review o di presentazione dei risultati, coinvolgendo i corretti stakeholder; ha il compito di facilitare la discussione durante l’analisi del lavoro fatto, cercando, ove necessario di ricondurre sempre la discussione sul focus del meeting e dello sprint.

Sprint Retrospective

Lo Scrum Master deve saper progettare e facilitare una retrospettiva scegliendo il formato più adatto in base alle necessità del team. Deve quindi conoscere diversi formati, saperli scegliere ed eventualmente anche provare a mescolarli per crearne di nuovi. Deve conoscere bene le fasi di una retrospettiva e saper leggere l’umore della stanza per capire in ogni momento quale stile relazionale attivare per agevolare la discussione del gruppo.

Setup del processo

Oltre alla cura delle meccaniche di base, è di fondamentale importanza che lo Scrum Master sappia supportare il team per iniziare il lavoro con Scrum, per esempio aiutando a definire i calendari e le cadenze degli eventi, l’installazione e la spiegazione circa l’uso degli strumenti operativi, dai più semplici come Trello ai più sofisticati come Jira, Azure, Scrum Desk o Kanbanize; egli deve poi seguire la progettazione e la realizzazione delle board fisiche, direttamente o supportando l’azione.

Figura 1 – Uno Scrum Master nelle prime fasi di setup del processo: la progettazione di una kanban board fisica.

Figura 1 – Uno Scrum Master nelle prime fasi di setup del processo: la progettazione di una kanban board fisica.

In questa fase di setup, il team dovrebbe definire una prima bozza del processo di lavoro: per esempio nel progettare la board (fisica o digitale) dovranno essere definite il numero e i nomi delle fasi di lavorazione e delle colonne della board, le regole di passaggio, le policy di gestione e altro ancora.

Un ampio spettro di competenze

Anche se lo Scrum Master è un ruolo strettamente legato al framework metodologico Scrum, è piuttosto frequente che un team Scrum utilizzi nel proprio lavoro quotidiano anche elementi provenienti da altre metodologie, prima fra tutte Kanban molto adatta per esempio nella gestione degli imprevisti o delle emergenze.

Per questo motivo lo Scrum Master dovrebbe avere anche delle conoscenze di Kanban e dovrebbe aiutare il team a svolgere il setup di tale strumento: quindi aiuta nella progettazione della board, e poi nella definizione del flusso di lavoro, delle classi di servizio dei ticket e nella creazione delle policy di servizio.

La sperimentazione di nuovi modi di lavorare

Uno dei pilastri basilari della filosofia agile è il concetto di miglioramento continuo; per questo lo Scrum Master, più che spingere il team ad applicare pedissequamente una serie di istruzioni su come “fare Scrum”, qualsiasi cosa questo significhi, dovrebbe stimolare la creazione di una mentalità sperimentale, fatta di osservazione della realtà, di valutazione dei punti di miglioramento e di sperimentazione di strategie di miglioramento.

Per questo lo Scrum Master dovrebbe abilitare la progettazione e l’implementazione di “esperimenti” volti a trovare nuovi modi di lavorare. Uso la parola “progettazione” di esperimenti perché sperimentare qualcosa non significa affatto “tentare a caso” qualcosa di nuovo.

Un esperimento infatti dovrebbe possedere queste caratteristiche:

  • avere un nome;
  • avere un scopo e un beneficio atteso (definizione del successo);
  • definire una metrica che permetta di capire quando ha successo;
  • in caso di successo, ipotizzare come dovrebbe apparire il sistema se ha successo;
  • in caso di successo, ipotizzare come amplificare o ripetere l’esperimento facendolo diventare una pratica ripetibile;
  • in caso di fallimento, ipotizzare come dovrebbe apparire il sistema;
  • in caso di fallimento ipotizzare come evitare che il fallimento si propaghi;
  • dare la possibilità di capire se è coerente con lo scopo dell’organizzazione o del progetto;
  • essere naif, per esempio coinvolgere persone con competenze innovative, fuori contesto, essere illogico.

Come si vede da questo elenco, la definizione di un esperimento ruota intorno al concetto di scopo/misurazione del beneficio, vale a dire come mi accorgo che l’esperimento ha avuto successo). Diventa quindi indispensabile trovare un insieme di metriche che ci permettano di misurare il sistema prima e dopo l’attuazione dell’esperimento.

Le metriche: operatività e strategia

Nella pratica, oltre ad aiutare il team a creare azioni di miglioramento, per esempio tramite la Sprint Retrospective, lo Scrum Master dovrebbe anche stimolare la definizione di metriche, osservare numeri, indicatori che permettano di verificare l’utilità e l’efficacia — oppure l’inutilità — delle varie azioni.

Accanto a questo lavoro di gruppo (scegliere gli indicatori), lo Scrum Master si adopera poi in prima persona per facilitare la raccolta dei numeri, la razionalizzazione dei risultati, l’impaginazione in un formato di facile comprensione.

Nello svolgimento di questo importante mestiere, due sono gli ambiti di azione: metriche che possano aiutare il gruppo nella operatività quotidiana, e metriche che invece diano informazioni strategiche sulla realizzazione del prodotto.

Le metriche operative

Si tratta di indicatori che permettono al team di capire come intervenire nel portare avanti il proprio progetto; si tratta di strumenti piuttosto noti come la Velocity o il Lead Time o il Cumulative Flow Diagram (CFD), anche se questo più propriamente è un diagramma, che serve per riportare in forma grafica alcune grandezze.

Velocity

La Velocity permette al team di sviluppo di prendere una delle decisioni più importanti, ossia valutare, durante lo Sprint Planning, quante cose si possono realisticamente mettere in lavorazione nello Sprint. La Velocity è quindi un indicatore che, pur in forma grezza e forse superficiale, può fornire alcune indicazioni sul trend delle performance del team stesso.

Affinché la Velocity sia realmente utile, il team dovrebbe cercare di ridurre al minimo la variazione fra punti stimati al plan (a volte detto Capacity) e i punti dati dalla somma dei punti delle storie terminate con successo (Velocity).

Figura 2 – Velocity e capacity.

Figura 2 – Velocity e capacity.

Minore sarà questa differenza, maggiore sarà l’autocoscienza del team che quindi sarà in grado di fare previsioni più precise e avrà una maggior consapevolezza dei propri mezzi e delle conseguenze delle proprie scelte (= esperimenti).

Il gap diventa quindi un’altra metrica interessante che lo Scrum Master dovrebbe raccogliere per metterlo a disposizione del team. Avere una Velocity stabile è una cosa molto utile anche per il Product Owner, poiché lo aiuta a prevedere, in una certa misura, l’andamento del progetto.

Figura 3 – Un burndown chart.

Figura 3 – Un burndown chart.

Da un lato, la velocity permette di creare un burndown chart efficace, dall’altro è utile al Product Owner per fare una roadmap di prodotto.

Figura 4 – Sapere quanti km riusciremo a fare ogni giorno (velocity) ci consente di pianificare il viaggio.

Figura 4 – Sapere quanti km riusciremo a fare ogni giorno (velocity) ci consente di pianificare il viaggio.

Come esempio di paragone, immaginiamo di fare un viaggio in bicicletta da Firenze a Parigi (distanza di circa 1000 km): sapere indicativamente quanti km riusciremo a percorrere ogni giorno con le nostre bici cariche di bagagli ci permetterebbe di pianificare il viaggio (progetto), la data di arrivo (fine progetto) e le varie tappe (rilasci intermedi).

Cumulative Flow Diagram

Uno strumento più sofisticato rispetto alla Velocity è il Cumulative Flow Diagram, anche se il suo uso è più proprio di un modo di lavorare in una logica a flusso (Kanban). Il CFD, per esempio, è un ottimo strumento per valutare l’efficacia di soluzioni tecniche apportate nel processo di lavoro. Un caso di studio che mi è capitato diverse volte è relativo al tempo di risoluzione dei bug , fatta in modalità Kanban all’interno di un team Scrum, in funzione della complessità del progetto.

In un digramma di questo tipo, il vettore verticale che unisce prima e ultima fase rappresenta il tempo puntuale che intercorre fra l’inserimento nel backlog di un task e la relativa conclusione. La forma dell’area che si forma fra la curva di apertura e di chiusura è un chiaro indicatore di quello che accade.

Figura 5 – CFD, effetto schiacciamento.

Figura 5 – CFD, effetto schiacciamento.

Se la forma dell’area rimane “assottigliata” significa che il team, tutto sommato, riesce a star dietro alle richieste.

Figura 6 – CFD, effetto “spanciamento”.

Figura 6 – CFD, effetto “spanciamento”.

Se tale forma si allarga (“spanciamento”) è invece indice di un aumento del numero di cose da mettere a posto, con aumento del tempo di chiusura.

Un sistema di monitoraggio del genere aiuta a fare esperimenti e a vederne gli effetti: per esempio, si potrebbe inserire un sistema di test automatico, migliorare la qualità del codice e vedere cosa succede alle curve.

Lead Time

Un’altra metrica molto importante è il Lead Time, che ci permette di capire quanto tempo ci mettiamo a evadere delle richieste di lavorazione (ticket in emergenza, bug in produzione o semplicemente service requests).

Con il Lead Time o con il tempo di fase possiamo avere indicazioni sul tempo necessario per evadere una richiesta o più puntualmente per valutare le performance di una specifica sottofase nella lavorazione.

Il senso delle metriche operative

Si ricordi sempre che questi indicatori forniscono solo una indicazione sulle performance interne del team non sulla utilità in senso strategico del lavoro del team: esse non misurano il valore prodotto per l’utente, che in Agile è una valutazione molto più importante. In sintesi: non stiamo misurando il valore prodotto, ma solo la prestazione del team. Di tale tema ci siamo già occupati su queste pagine con una serie dedicata alla Product Ownership e alla misurazione del valore di un prodotto [3].

Possono invece fornire risposte a domande del tipo:

  • Stiamo facendo più cose?
  • Riusciamo a evadere più velocemente una richiesta di lavorazione?
  • Abbiamo meno punti morti (ossia attese per risposte che non arrivano)?
  • Siamo meno legati al contributo di un singolo team member (= maggior crossfunzionalità)?

Metriche strategiche

Accanto alle metriche operative, ci sono altri indicatori che lo Scrum Master dovrebbe tenere sotto controllo e che sono utili per fare ragionamenti di tipo strategico, vale a dire per il Product Owner o per il resto dell’organizzazione.

Un esempio di metrica di tale tipo che ricordo sempre quando parlo di questo argomento è rappresentato dall’ottimo lavoro fatto da uno Scrum Master che ho incrociato qualche hanno fa da un cliente. In quel caso il team raccoglieva i dati di Capacity (punti stimati al plan) e Velocity effettiva (calcolata a fine sprint dalla somma dei punti delle storie completate con successo) dando vita a un diagramma tipo quello presentato in figura 7.

Figura 7 – Un diagramma che valuta il rapporto tra capacity e velocity nel corso delle varie iterazioni, tenendo presente anche eventi avvenuti nel progetto.

Figura 7 – Un diagramma che valuta il rapporto tra capacity e velocity nel corso delle varie iterazioni, tenendo presente anche eventi avvenuti nel progetto.

Lo Scrum Master poi teneva traccia anche di altre informazioni, come gli eventi accaduti durante lo sprint e le ore uomo spese fuori dal progetto. Nella figura 7 si nota come l’insorgere di eventi particolari “esterni al team” possano impattare le performance (differenza fra punti previsti e punti fatti). Il terzo evento, l’arrivo di nuovi membri nel team, inizialmente porta un rallentamento, come normale che sia quando devi spiegare e aiutare i nuovi colleghi a lavorare al progetto.

Osservando tutte queste grandezze si poteva per esempio osservare gli impatti di eventi imprevisti o del turnover delle persone sulle performance di avanzamento del progetto. Per esempio, in quel caso c’era una correlazione stretta fra le ore spese fuori dal progetto da parte del team e il rallentamento nella lavorazione degli item dello sprint backlog.

In casi come questi c’è sempre il rischio di interpretare i dati in modo del tutto immotivato e una correlazione spuria fra serie storiche è sempre possibile; è comunque vero che disporre di questo genere di informazioni è comunque un buon punto di partenza per iniziare a fare qualche tipo di ragionamento.

Usare questi grafici in ottica strategica

Nel caso di esempio, lo Scrum Master potrebbe portare il grafico in questione a un responsabile dell’organizzazione offrendo la seguente considerazione: “Sulla base dei dati che stiamo raccogliendo, sembrerebbe che tutte le volte che il team viene coinvolto in altre iniziative, il progetto rallenti e l’obiettivo di consegnare entro la data prevista si allontani. Ecco cosa stiamo vedendo”.

Ovviamente è anche probabile che le attività extra-progettuali siano di tale importanza che sia impossibile non coinvolgere i membri del team. Si tratta quindi di una decisione di strategia: accettare di rallentare il progetto per impedire che altre cose si blocchino del tutto, oppure dare massima priorità al progetto stesso.

Il management (o chi per lui) dovrebbe avere tutte le informazioni (dati) per poter decidere al meglio. Lo Scrum Master è quindi un uomo di management — come recitava una delle domande dell’esame di certificazione — nel senso che deve avere autorevolezza e credibilità per andare a raccontare al management gli impatti dei vari accadimenti. In questo caso presentarsi con dei numeri, per quanto interpretabili, è un modo per rafforzare la propria credibilità.

Conclusioni

Tra fedele applicazione delle meccaniche di base e sensate sperimentazioni innovative, tra uso di metriche riconosciute e visione strategica, il ruolo dello Scrum Master è sempre dinamico e richiede, a chi lo interpreta, di sapersi muovere oculatamente tra tadizione e innovazione.

Riferimenti

[1] La guida a Scrum

https://www.scrum.org/resources/scrum-guide

 

[2] Guida Galattica per Agilisti, Parte 4: Kanban

https://www.guidagalatticaperagilisti.com

 

[3] Ilaria Mauric – Giovanni Puliti, Product Ownership e misurazione del valore di un prodotto – I parte: le misurazioni interne/indirette. MokaByte 247, febbraio 2019

http://www.mokabyte.it/2019/02/productvalueownership-1/

 

Condividi

Pubblicato nel numero
265 ottobre 2020
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nello stesso numero
Articoli nella stessa serie
Ti potrebbe interessare anche