Cos'è uno Scrum Master?

Lo Scrum Master è una delle responsabilità definite all'interno di Scrum e il suo ruolo è principalmente quello di aiutare lo Scrum Team e l'organizzazione a comprendere e applicare il framework in modo efficace.

Non dovrebbe essere il capo del team, non dovrebbe distribuire attività come un manager tradizionale e nemmeno trasformarsi in una specie di poliziotto della Daily Scrum. Il suo lavoro è molto più legato alla facilitazione di Scrum, al supporto dell'autogestione del team, alla rimozione degli impedimenti e al miglioramento continuo dell'efficacia dello Scrum Team.

La distinzione è importante perché esiste una situazione che ho visto ripetersi più volte: un'azienda adotta Scrum, elimina il Project Manager dalla struttura e, qualche settimana dopo, inizia a chiedere allo Scrum Master informazioni su budget, timeline, rischi, dipendenze, fornitori, stakeholder, capacità, previsioni di delivery e reportistica executive.

In altre parole: abbiamo eliminato il Project Manager, ma apparentemente ci siamo dimenticati di eliminare tutti i problemi che gestiva.

Cosa fa uno Scrum Master?

Quando qualcuno chiede cosa fa uno Scrum Master, la risposta sembra semplice finché non osserviamo ciò che accade realmente nelle aziende.

All'interno di Scrum, il ruolo consiste nell'aiutare il team a lavorare meglio con il framework. Questo include supportare l'autogestione, migliorare l'efficacia dello Scrum Team, aiutare a rimuovere gli impedimenti, contribuire affinché gli eventi abbiano uno scopo reale e collaborare con Product Owner, Developers e organizzazione per migliorare il modo in cui Scrum viene utilizzato.

Il problema comincia quando l'espressione “rimuovere gli impedimenti” diventa una categoria universale nella quale inseriamo qualsiasi problema che nessuno sa esattamente a chi assegnare.

Se un fornitore è in ritardo, qualcuno chiama lo Scrum Master. Se esiste una dipendenza con un altro team, lo Scrum Master inizia a inseguirla. Se uno stakeholder fa pressione, ci si aspetta che aiuti a risolvere la situazione. Se lo Sprint è compromesso, gli viene chiesto cosa intende fare. Se un executive vuole sapere quando terminerà l'iniziativa, non sarebbe affatto sorprendente vedere lo Scrum Master contribuire alla preparazione della risposta.

Poco a poco, “aiutare il team a utilizzare Scrum ed essere più efficace” inizia silenziosamente a trasformarsi in “occupati di tutto ciò che sta ostacolando la delivery”.

E questo comincia ad assomigliare parecchio a un'altra professione che conosciamo da decenni.

Quali sono le responsabilità dello Scrum Master?

Le responsabilità dello Scrum Master sono principalmente legate a Scrum e all'efficacia dello Scrum Team. Nella pratica, possiamo riassumere buona parte del ruolo in attività come:

• Aiutare il team a comprendere e applicare Scrum.
• Supportare l'autogestione e la multidisciplinarità del team.
• Aiutare a rimuovere gli impedimenti che ostacolano il progresso.
• Supportare Product Owner e Developers nell'utilizzo corretto del framework.
• Contribuire affinché gli eventi Scrum abbiano uno scopo e siano produttivi.
• Lavorare con l'organizzazione per migliorare l'adozione di Scrum.
• Aiutare lo Scrum Team a migliorare continuamente la propria efficacia.

Ora osserva ciò che non compare naturalmente in questa definizione: gestire il budget complessivo del progetto, controllare contratti, coordinare fornitori, consolidare rischi aziendali, mantenere una timeline generale, rispondere della marginalità finanziaria o preparare reporting executive per il board.

Questo non significa che queste attività abbiano smesso di esistere. Significa semplicemente che Scrum non le ha assegnate formalmente allo Scrum Master.

E questa piccola differenza genera una quantità sorprendente di problemi all'interno di alcune organizzazioni.

Lo Scrum Master è un Project Manager?

No. Almeno non secondo Scrum.

Questa distinzione deve essere chiara, perché affermare semplicemente che Scrum Master e Project Manager siano la stessa cosa sarebbe tecnicamente scorretto. Lo Scrum Master lavora sull'applicazione di Scrum e sull'efficacia del team. Un Project Manager, a seconda dell'organizzazione e del modello utilizzato, può invece avere responsabilità molto più ampie legate a budget, timeline, rischi, comunicazione, fornitori, scope, stakeholder, governance, dipendenze e risultato complessivo del progetto.

Ma qui arriva la parte che considero molto più interessante: il fatto che i due ruoli siano diversi nella teoria non significa necessariamente che rimangano diversi una volta entrati in azienda.

Ho visto Scrum Master gestire rischi, preparare report executive, negoziare dipendenze tra team, coordinare fornitori, seguire delivery, monitorare costi, rispondere alle domande degli stakeholder e cercare di prevedere quando un'iniziativa sarebbe terminata.

In altre parole, svolgere una quantità piuttosto significativa di attività che qualche anno prima sarebbero probabilmente state assegnate a un Project Manager.

Scrum Master vs Project Manager: qual è davvero la differenza?

La differenza tra Scrum Master e Project Manager diventa molto più chiara quando smettiamo di guardare soltanto alle cerimonie e iniziamo a osservare chi ha davvero responsabilità sul risultato.

Tradizionalmente, il Project Manager esiste perché qualcuno deve guardare al progetto come a un sistema completo. Esistono budget, scadenze, scope, rischi, persone, fornitori, dipendenze, qualità, aspettative e diverse aree dell'organizzazione che cercano di spingere l'iniziativa in direzioni differenti.

Lo Scrum Master, invece, non viene definito da Scrum come la persona responsabile di gestire l'intero sistema. Il suo focus è aiutare lo Scrum Team e l'organizzazione a lavorare meglio utilizzando il framework.

E questo ci porta a una domanda che, secondo me, molte implementazioni Agile non hanno mai risposto davvero: se eliminiamo il Project Manager, chi gestisce tutto ciò che non è scomparso insieme a lui?

In alcune organizzazioni la risposta può essere un Program Manager. In altre un Delivery Manager, un Engineering Manager, un Product Manager, un PMO o una combinazione di queste funzioni. Non vedo alcun problema in questo.

Il problema nasce quando l'azienda non assegna formalmente queste responsabilità a nessuno e si aspetta che vengano assorbite informalmente dallo Scrum Master.

Scrum può eliminare il ruolo, ma non elimina la gestione

Questa è probabilmente la parte più provocatoria della mia opinione sull'argomento. Da anni vedo organizzazioni discutere se abbiano ancora bisogno o meno dei Project Manager in ambienti Agile, quasi come se rimuovere un ruolo dall'organigramma avesse qualche potere magico sui problemi reali di un'azienda.

Puoi eliminare il Project Manager, ma il costo del progetto continuerà a esistere. Lo stakeholder continuerà a chiedere quando sarà pronta la delivery. Il fornitore continuerà ad accumulare ritardi. I rischi continueranno a materializzarsi. Le dipendenze tra team continueranno a bloccare il lavoro. E qualcuno in Finance continuerà a voler sapere perché abbiamo consumato gran parte del budget senza aver consegnato una parte equivalente del risultato previsto.

Quello che è scomparso è il ruolo.

La necessità di gestione è rimasta esattamente dove si trovava prima.

Ed è così che lo Scrum Master inizia a diventare un Project Manager

È qui che la provocazione che aveva dato origine alla prima versione di questo articolo comincia ad avere senso. Non sto dicendo che lo Scrum Master sia un Project Manager. Sto dicendo che alcune aziende eliminano una funzione e, poco alla volta, iniziano a trasferirne parti a un'altra persona.

All'inizio lo Scrum Master aiuta con un impedimento. Poi comincia a seguire una dipendenza esterna. Poco dopo qualcuno gli chiede di aggiornare uno status. Successivamente inizia a parlare con gli stakeholder, compare un registro dei rischi, qualcuno chiede una previsione sulla delivery e, quando ce ne accorgiamo, quella persona che avrebbe dovuto aiutare il team a utilizzare Scrum sta facendo coordinamento della delivery, gestione dei rischi, comunicazione executive, monitoraggio della timeline e una parte della gestione degli stakeholder.

E potrebbe fare tutto questo senza aver necessariamente ricevuto la formazione adeguata, l'autorità necessaria o il riconoscimento formale corrispondente.

A quel punto, dire “siamo Agile e non abbiamo più bisogno di Project Manager” comincia ad assomigliare meno a una trasformazione organizzativa e molto di più a una redistribuzione silenziosa del lavoro.

Il problema non è chiedere di più allo Scrum Master

Voglio chiarire un punto: non vedo alcun problema nel fatto che uno Scrum Master sviluppi competenze di project management, delivery, gestione dei rischi, comunicazione o stakeholder management. Al contrario, credo che molte di queste competenze possano renderlo molto più efficace all'interno di un'organizzazione complessa.

Il problema è assumere una persona per una funzione, spiegarle che la sua responsabilità sarà una e poi iniziare silenziosamente a pretenderne una completamente diversa.

Se l'azienda ha bisogno che quella persona gestisca timeline, budget, rischi, fornitori, dipendenze e reporting executive, forse è arrivato il momento di riconoscere che quella funzione non è più soltanto quella di Scrum Master.

Può chiamarsi Delivery Manager, Project Manager, Program Manager o qualsiasi altro nome abbia senso all'interno della struttura. Il nome, probabilmente, è la parte meno importante.

Ciò che conta davvero è chiarire chi possiede la responsabilità, l'autorità e le competenze necessarie per svolgere il lavoro.

Meno autorità, ma le stesse aspettative

C'è un altro effetto che considero ancora più pericoloso: rendere una persona responsabile di un risultato senza darle abbastanza autorità per influenzarlo realmente.

Immagina uno Scrum Master a cui viene chiesto di spiegare il ritardo di un'iniziativa che dipende da quattro team esterni, due fornitori, un budget controllato da un'altra area e priorità definite da executive con i quali quella persona non ha nemmeno accesso diretto.

Può facilitare tutte le Daily Scrum del mondo. Il problema continuerà a esistere.

Quando responsabilità e autorità non avanzano insieme, creiamo un ruolo costretto a negoziare praticamente tutto e autorizzato a decidere quasi nulla. Poi chiamiamo questa situazione accountability, quando in realtà è soltanto un trasferimento della pressione verso il basso.

Chi gestisce costi, rischi, timeline e stakeholder?

Per me questa domanda è molto più importante che discutere all'infinito se lo Scrum Master sostituisca o meno un Project Manager. Il nome del ruolo mi interessa molto meno che sapere chi sta guardando il denaro, chi segue i rischi, chi comprende le dipendenze tra team, chi riesce a vedere che una sequenza di piccoli ritardi probabilmente comprometterà una delivery tra tre mesi e chi parla con gli stakeholder quando le aspettative iniziano ad allontanarsi dalla realtà.

Se la risposta è “nessuno, perché il team è autogestito”, abbiamo un problema.

L'autogestione è estremamente importante per definire come il team organizza ed esegue il proprio lavoro. Ma non fa sparire contratti, vincoli finanziari, dipendenze organizzative, impegni commerciali, rischi o aspettative executive.

Un burndown non gestisce un'azienda

Uno dei miei problemi con alcune implementazioni Agile è la riduzione eccessiva della gestione a poche metriche di Sprint. La Velocity può essere utile. Un burndown può essere utile. Lo Sprint Goal è importante. Le Retrospective sono importanti.

Ma nessuna di queste cose, da sola, risponde a domande come: quanto è già costato questo progetto? Quale area sta consumando più budget? Quali attività stanno generando più rework? Quali rischi stanno aumentando? Stiamo consegnando risultati proporzionati al denaro consumato? Quale dipendenza potrebbe compromettere la timeline? La produttività del team sta migliorando o peggiorando?

Gli executive continuano ad avere bisogno di queste risposte indipendentemente dal fatto che il team utilizzi Scrum, Kanban, SAFe, Waterfall o qualsiasi combinazione tra questi modelli.

Un framework di lavoro non sostituisce l'intelligence di gestione.

È qui che entra Saint Jude

Questa mancanza di visibilità è una delle ragioni per cui abbiamo creato Saint Jude Project Intelligence .

Quando un'azienda utilizza Jira, Azure DevOps, Asana, monday.com o ClickUp, genera ogni giorno un'enorme quantità di informazioni sull'esecuzione dei propri progetti. Il problema è che questi dati rimangono normalmente dispersi tra board, dashboard, fogli di calcolo, presentazioni e interpretazioni differenti da parte di ogni manager.

Saint Jude utilizza questi dati per creare un livello di intelligence sui progetti, permettendo di analizzare timeline, costi, produttività, performance, rischi, stime, qualità delle attività, comportamento degli Sprint e altri segnali che aiutano PMO e leadership a capire cosa sta realmente accadendo.

L'idea non è trasformare nuovamente lo Scrum Master in un Project Manager. Anzi, è esattamente il contrario. Più informazioni di gestione possono essere strutturate automaticamente a partire dai dati che già esistono, minore sarà la necessità che qualcuno trascorra parte della settimana raccogliendo manualmente informazioni per produrre report che probabilmente saranno già obsoleti il giorno successivo.

Quindi, qual è davvero il ruolo dello Scrum Master?

Il ruolo dello Scrum Master ha senso quando gli permettiamo di essere ciò che dovrebbe essere: qualcuno che aiuta lo Scrum Team e l'organizzazione a lavorare meglio utilizzando Scrum.

Il problema comincia quando decidiamo che il Project Manager è diventato obsoleto, eliminiamo la funzione e presumiamo che tutte le responsabilità legate alla gestione siano scomparse insieme al ruolo.

Non sono scomparse. Qualcuno continuerà a occuparsene. Potrebbe essere un PMO, un Delivery Manager, un Program Manager, un Engineering Manager oppure una combinazione di persone, processi, dati e automazione.

Oppure, senza che nessuno lo dica chiaramente, l'azienda finirà per mettere una parte importante di tutto quel lavoro sulle spalle dello Scrum Master.

Ed è proprio in quest'ultimo scenario che la mia provocazione continua a essere valida: in molte aziende, lo Scrum Master non è diventato ufficialmente un Project Manager. Ha semplicemente ricevuto sempre più responsabilità di gestione senza che nessuno volesse ammettere che il project management continuava a essere necessario.

Il problema non è mai stato lo Scrum Master. Il problema è credere che cambiare il nome dei ruoli faccia sparire costi, rischi, scadenze, dipendenze, stakeholder e problemi di comunicazione.

Non li fa sparire.

E tu, cosa ne pensi? Nella tua azienda, lo Scrum Master svolge principalmente le responsabilità previste da Scrum oppure ha finito per assorbire una parte del lavoro che prima apparteneva al project management?

A presto!

Erik Scaranello