Le regole del gioco: i Ruoli Scrum

Chi gioca a questo gioco?

Nel gioco del Rugby lo Scrum (abbreviazione di Scrummage) o mischia è un metodo per riavviare il gioco che coinvolge i giocatori che si stringono l’uno accanto all’altro a testa bassa tentando di ottenere il possesso della palla dopo un fallo o un’uscita accidentale della palla dal campo. Una metafora del team in cui le persone devono lavorare insieme, muovendosi tutti nella stessa direzione, come un’unica entità coordinata spinta da un obiettivo comune.

Ogni gioco che si rispetti inizia dai suoi giocatori. Proviamo a conoscere un pò meglio i nostri eroi che insieme costituiscono il nucleo fondante di Scrum: lo Scrum Team.

Buona lettura!

Ruoli Scrum: lo Scrum Team

Se hai avuto modo di leggere il mio precedente articolo su Scrum ti ricorderai che l’intelligenza collettiva del framework risiede nel suo nucleo fondamentale, lo Scrum Team, un piccolo gruppo di persone, con 3 specifiche responsabilità (o, se preferisci, 3 super-poteri! 😊) che nelle versioni della Scrum Guide precedenti all’ultima (Novembre 2020) corrispondevano ai Ruoli Scrum:

1. i Developer
2. un Product Owner
3. uno Scrum Master.

Lo Scrum Team:

• non ammette sottogruppi o gerarchie al suo interno: è un gruppo coeso di persone che lavora per raggiungere un solo obiettivo alla volta (no multi-tasking, please! ), rappresentato dal Product Goal.
• E’ Cross-Funzionale: nel suo complesso possiede tutte le competenze necessarie per completare il lavoro di uno Sprint e quindi, tendenzialmente, non dipende da nessun altro. Uno degli obiettivi di Scrum è la velocità: più aumentano i vincoli esterni di dipendenza meno veloci riusciremo ad essere
• E’ Auto-Gestito: un team fatto di professionisti strutturato per decidere in autonomia chi lavorerà su cosa, quando e come lo farà. Ma non basta. La struttura del team è condizione necessaria ma non sufficiente: qui gioca un ruolo chiave l’organizzazione in cui il team opera che deve legittimare l’autonomia del team concedendogli le opportune leve decisionali. Un management che predica agile e razzola waterfall non può sperare che Scrum abbia successo!
• È abbastanza piccolo da mantenersi agile e abbastanza grande da riuscire a completare il lavoro di uno Sprint (l’Iterazione agile). Di solito non più di 10 persone in tutto.
  Un team piccolo è generalmente più produttivo e comunica in modo più efficace. Il concetto è abbastanza intuitivo e chi ha lavorato in team piccoli lo sa bene ma, se proprio vuoi delle prove, eccone alcune:

• l’Effetto Ringelmann dimostra come i membri individuali di un gruppo tendano a diventare sempre meno produttivi a mano a mano che la dimensione del loro gruppo aumenta
• Il Numero di Dunbar ci permette di quantificare il limite cognitivo teorico relativo al numero di persone con cui un individuo è in grado di mantenere relazioni sociali stabili (relazioni nelle quali un individuo conosce l’identità di ciascuna persona e sa come queste persone si relazionano con ognuna delle altre). Gli esseri umani sono in grado di mantenere in media 150 relazioni sociali stabili contemporanee
• il Numero di Canali di Comunicazione in un gruppo si calcola con la formula C = (N x (N – 1)) / 2. Se, ad esempio, il nostro team è composto da 3 persone i canali di comunicazione da mantenere saranno solo 3 ma se nel nostro team ci sono 9 persone ecco che i canali di comunicazione diventano ben 36! La faccenda si va ovviamente un tantino più complicata.

• E’ collettivamente responsabile di tutte le attività necessarie alla creazione di un prodotto/servizio che dia valore al cliente (e per tutto intendo proprio tutto: dalla gestione degli stakeholders, alle attività di analisi, progettazione, realizzazione, quality-control e quality-assurance, rilascio in produzione, maintenance e così via).
  top

Vediamo ora come, nello Scrum Team, si declinano le 3 responsabilità.

Ruoli Scrum: i Developers

Chiariamo subito: è un DEVELOPER chiunque, nello Scrum Team, sia assuma l’impegno di completare, entro la fine dello Sprint, ogni aspetto necessario a rilasciare un incremento di prodotto (o servizio) che sia utilizzabile e rappresenti valore per il cliente, aderendo alle regole di qualità concordate (Definition Of Done).

Le competenze richieste ad un Developer sono ovviamente legate al contesto specifico in cui viene adottato Scrum (Sviluppo Software, Marketing, HR, Procurement, Vendite, etc.) ma, in generale, un buon Developer è (o, se non lo è, si impegna a diventarlo) uno specialista-generalista che possiede delle T-Shaped Skill: almeno una competenza specialistica (come il ramo verticale della lettera T) e un set ampio di competenze trasversali (il ramo orizzontale della lettera T).

Ritengo che una persona che affianchi alla propria specializzazione delle competenze trasversali ampie sia uno specialista migliore, in grado di valutare olisticamente il ventaglio di soluzioni tecniche possibili e di proporre le migliori con una visione più ampia e completa.

La connotazione T-Shaped protegge inoltre un team Scrum da una sua caratteristica che è uno dei suoi punti di forza e nello stesso tempo di debolezza: la sua dimensione.

Un team piccolo può entrare più facilmente in crisi per la mancanza di uno dei membri del team perché rispetto ad un team più grande ci saranno meno persone che possiedono le stesse skill e possono far fronte alla, più o meno temporanea, assenza di un proprio collega.

Il “Bus Factor”, concetto popolare nella comunità agile, ci aiuta a rispondere alla domanda (un po’ splatter alla Quentin Tarantino): “Quanti membri del tuo team possono essere investiti da un autobus e uccisi prima che il tuo team vada in crisi?”. Se la risposta è 1 (Bus Factor = 1) meglio accendere un cero a Sant’Antonio perché l’autobus assassino avrà probabilmente ucciso l’unico sviluppatore Java del nostro team.

Se, al contrario, i membri del nostro team si contaminano e imparano ad acquisire tante competenze diverse potranno far fronte più “agilmente” all’assenza di uno dei propri colleghi e supportarsi a vicenda nei momenti di difficoltà.

Le responsabilità dei Developer includono:

• La creazione di almeno un Increment entro la fine dello Sprint
• il soddisfacimento delle regole di qualità concordate nella Definition of Done
• la creazione e la gestione dello Sprint Backlog: il piano operativo dello Sprint
• la verifica (Inspect) giornaliera dell’avanzamento rispetto al raggiungimento dello Sprint Goal e il relativo adattamento del loro piano operativo (contenuto nello Sprint Backlog)
• Ritenersi reciprocamente responsabili come professionisti che contribuiscono alla creazione di valore.

Ruoli Scrum: il Product Owner

Il PRODUCT OWNER (PO per gli amici) è una persona (con un nome, un cognome e una faccia), non un gruppo, un ufficio o un team di persone: lo Scrum Team deve riconoscerlo come l’unica voce autorizzata (The Voice of the Customer) a rappresentare le esigenze (che confluiranno poi nel Product Backlog) dei diversi stakeholders.

Un buon Product Owner:

• contribuisce a creare la Product Vision (la ragione ultima per cui il prodotto viene creato coerente con la strategia aziendale) e lavora con questa in mente
• è un abile comunicatore che preferisce una comunicazione diretta e face-to-face
• è un esperto di dominio: conosce bene la propria organizzazione, i suoi obiettivi strategici, i modelli di business, i processi e i prodotti/servizi. Non è necessariamente un tecnico ma di tecnico comprende quel tanto che basta per avere un quadro completo. I dettagli li lascia ai Developers
• è outcome-oriented e non output-oriented: il suo focus è cogliere l’obiettivo degli stakeholder e dell’organizzazione e per farlo è disposto a rivedere e rinegoziare lo scope
• agisce su più livelli:

• Strategico: sa descrivere la strategia del prodotto al board aziendale
• Tattico: supporta adeguatamente il middle management
• Operativo: comunica e chiarisce vision, obiettivi e requisiti ai Developers e li supporta costantemente

• si comporta come un imprenditore per il suo prodotto. E’ pronto a cogliere le sfide, si concentra sul valore aziendale e sul ritorno d’investimento e governa proattivamente i rischi (minacce e opportunità).
• come proprietario del Prodotto ha la responsabilità di massimizzarne il valore realizzato attraverso il lavoro dello Scrum Team.
  Il Product Owner persegue questo obiettivo ordinando gli item del Product Backlog in modo coerente rispetto alle priorità di business: tanto più strategico e importante è un item, tanto più in alto si troverà nel Product Backlog in termini di ordinamento, tanto prima il PO lo proporrà ai Developers per uno Sprint.

Il Product Owner è, di conseguenza, responsabile anche del Product Backlog:

• della sua trasparenza, visibilità e comprensione
• della creazione e comunicazione del suo obiettivo: il Product Goal
• della creazione, comunicazione e ordinamento del suo contenuto: gli item del Product Backlog (o PBIs, Product Backlog Items).
  Naturalmente anche il Product Owner può aver bisogno di aiuto: delegare ad altri le attività connesse alla gestione pratica del Product Backlog è una facoltà che può esercitare ma rimane sempre lui il solo e unico responsabile del suo contenuto e del valore che esprime (se utilizzassimo una Matrice RACI diremmo che il PO è Accountable anche quando qualcun altro è Responsible).

• Le decisioni che prende sono visibili e trasparenti dal contenuto e ordinamento del Product Backlog e dalle attività di verifica dell’incremento durante la Sprint Review.
• E’ empowered.
  Perché Scrum abbia successo, l’organizzazione deve riconoscere l’autorità del Product Owner e rispettarne le decisioni: chiunque voglia alterare il contenuto del Product Backlog dovrà vedersela con lui! 😊
  A scanso di equivoci cerco di esprimere meglio questo concetto. Il Product Owner collabora e si confronta continuamente con gli stakeholders e i Developer, si fida di loro e ne rispetta il ruolo e la competenza. Tuttavia è sua la responsabilità del Product Backlog: sarà quindi compito degli stakeholders e dei Developers persuaderlo dell’importanza di aggiungere o alterare dei PBIs soprattutto quando questi hanno una connotazione tecnica (solitamente il PO non è un tecnico), come può avvenire, ad esempio, in caso di requisiti non funzionali (performance, sicurezza, compliance, etc.). Un buon PO sa anche dire di “NO”.

Cosa il concetto di valore possa rappresentare, come misurarlo e massimizzarlo dipende dal contesto specifico in cui si opera.

Spesso il concetto di valore è misurabile in termini economici ma non è sempre così: per un’organizzazione no-profit può rappresentare un valore sociale, per un ente pubblico i servizi forniti ai cittadini, un’istituzione scolastica mira a ridurre il tasso di abbandono scolastico aumentando la qualità dell’insegnamento, l’adesione a normative imposte ci aiuta a non generare un dis-valore derivante da eventuali sanzionamenti e così via.

Ruoli Scrum: lo Scrum Master

Dulcis in fundo lo SCRUM MASTER, il ruolo in assoluto più controverso, discusso e frainteso di Scrum, probabilmente perché non ha una controparte negli approcci di gestione tradizionali.

Una delle sue responsabilità chiave è evocata dal suo nome: è il maestro di Scrum, lo Scrum “Sensei”, responsabile di promuovere Scrum, così come definito nella Scrum Guide, aiutando chiunque (sia il Team che l’organizzazione) a comprenderne la teoria e padroneggiarne la pratica.

E’ una responsabilità del nostro eroe  anche l’efficacia dello Scrum Team che supporta aiutandolo a migliorare le pratiche adottate con Scrum.

Non aspettarti che lo Scrum Master prenda qualsiasi tipo di decisione tecnica, che orienti le scelte realizzative, che coordini il Team o ne batta i tempi, che faccia da trait d’union tra i Developer e il Product Owner o gli Stakeholders, che faccia stime, piani o qualsiasi altra cosa che violi uno dei principi sacrosanti di Scrum, quello dell’auto-gestione e auto-organizzazione dello Scrum Team.

Dai un pesce a un uomo e lo nutrirai per un giorno; insegnagli a pescare e lo nutrirai per tutta la vita. – ConfucioLo Scrum Master non compie scelte che competono al team ma ne allena il muscolo dell’autonomia e del pensiero divergente perché il team sia in grado di decidere da se.

Lo Scrum Master è un leader “vero” (true leader) che, strategicamente, fa un passo indietro, esce di scena, rinuncia alla ribalta per mettere se stesso al servizio degli altri: lavora per mettere gli altri in condizione di lavorare al meglio.

La vecchia definizione di Servant-Leader è stata sostituita nell’ultima edizione della Scrum Guide con “true leaders who serve”, forse per accentuare il tratto di leadership dello Scrum Master o, più semplicemente, perché, per gli autori, un vero leader non può che avere questa connotazione.

Lo Scrum Master è un “true leader who serves”:

lo SCRUM TEAM	Il PRODUCT OWNER	L’intera ORGANIZZAZIONE
Allenando il muscolo dell’auto-gestione e della cross-funzionalità dei membri del team	Aiutandolo a trovare tecniche per la gestione efficace del Product Backlog e la definizione del Product Goal	Nel guidare, formare e allenare le persone nell’adozione di Scrum
Aiutando le persone a comprendere che l’obiettivo è creare incrementi di valore, potenzialmente rilasciabili e quindi completi (“Done”) in tutti i loro aspetti	Aiutandolo (e con lui tutto il team) a comprendere l’importanza di avere dei PBIs chiari (perché siano lavorabili) e concisi (perché lascino spazio alla futura negoziazione in modo emergente)	Nel pianificare e supportare la transizione a Scrum
Aiutando a rimuovere gli impedimenti che bloccano o rallentano il lavoro del team	Aiutandolo a comprendere la necessità di un approccio empirico alla pianificazione quando si lavora su problemi complessi	Nell’aiutare le persone e gli stakeholder a comprendere ed ad agire con un approccio empirico per risolvere problemi complessi
In quanto garante di Scrum, assicurandosi che tutti gli Eventi vengano svolti, nel timebox previsto e in modo positivo e produttivo	Aiutandolo a comunicare e collaborare efficacemente con gli stakeholders	Nel superare le barriere tra i team Scrum e gli stakeholders

Prendere decisioni al posto del team ne mina la capacità di auto determinazione e ne compromette inesorabilmente la crescita: non cadere in questa trappola è quello che segna la differenza tra un “capo” e un servant-leader.

Provo a riassumere i tratti caratteristici che il poliedrico Scrum Master DEVE e NON DEVE possedere per essere davvero considerato tale e, soprattutto, per far si che Scrum abbia davvero successo:

UNO SCRUM MASTER E’ UN…	UNO SCRUM MASTER NON E’ UN…
Servant Leader: che mette se stesso al servizio del team e dell’organizzazione per aiutarli a raggiungere risultati coerenti con i valori, i principi e gli obiettivi aziendali	Scriba: che prende appunti durante gli eventi Scrum o redige i verbali
Maestro, Mentor, Coach: che aiuta lo Scrum Team e l’intera organizzazione a conoscere, comprendere e rispettare le regole del gioco di Scrum e, soprattutto, ad agirle in modo coerente	Segretario: che ha il compito di gestire l’agenda del team, del Product Owner o degli stakeholders per fissare gli eventi Scrum o di raccogliere i timesheet
Facilitatore: che crea le condizioni e il clima migliore per lo svolgimento degli eventi Scrum, fornisce confini chiari in cui il team può collaborare ed il perimetro per la sua auto gestione	Poliziotto: che impone in modo coercitivo e dogmatico le regole di Scrum anziché aiutare empaticamente  le persone a comprenderne lo spirito
Manager: che gestisce Scrum e le sue regole Dunque il processo non le persone! E’ il garante della corretta applicazione di Scrum per il Team e tutta l’organizzazione	Capo: che decide chi è nel team e chi no, che distribuisce premi, punizioni o aumenti di stipendio
Impediment Remover: che rimuove qualsiasi “disturbo” (Impediment) che mini l’efficacia dello Scrum Team, rallentandone o bloccandone l’avanzamento, laddove la sola capacità di auto-gestione del team non sia sufficiente a risolverlo	Amministratore dei Tool: a cui spetta il compito di aggiornare il Burndown Chart, la Scrum Board o di configurare Jira
Change Agent: che crea e promuove un mindset e una cultura agile in linea con il sistema valoriale di Scrum	Presidente: che utilizza il Daily Scrum per aggiornare il capo sullo stato di avanzamento
	Super Eroe: il personaggio inquietante che risolve i tuoi problemi prima ancora che tu sappia di averli e si assicura che tutto il mondo lo sappia. E’ davvero poco interessato a te e al tuo team e molto di più al suo ego ipertrofico
	Cameriere: che ti accoglie con caffè e cornetti al Daily Scrum (ovviamente non c’è nulla di male nel farlo ma scuramente non è questo l’obiettivo del ruolo). P.S.: da evitare anche la variante “fare le fotocopie” o “recuperare la cancelleria”.

Per concludere

Project Manager? Anche NO!

Dunque tra i ruoli di Scrum non è presente il Project Manager: il responsabile unico dei risultati del progetto secondo i tradizionali approcci waterfall.

Non dobbiamo farci trarre in inganno:

• Scompare la figura del PM non l’attività di Project Management. Il fatto che Scrum non preveda questo ruolo non vuol dire che non si gestisca o governi il progetto ma che si passa da un Modello Centralizzato di Project Management ad un Modello Decentralizzato: le responsabilità che negli approcci tradizionali ricadono interamente sulla figura del PM vengono redistribuite in Scrum tra i suoi tre ruoli. La responsabilità del progetto ricade quindi sull’intero Scrum Team.
• NON rientra nella sfera di auto gestione dello Scrum Team decidere se il PM è presente o meno. Il PM non è uno dei ruoli previsti da Scrum, senza se e senza ma. Lo ringraziamo per tutto ciò che ha fatto per noi fino ad ora e gli diciamo addio con riconoscenza ma per sempre.

Agile Coach? Si, No, Forse?

SI! Ma prima leggiamo bene la Scrum Guide!

Lo Scrum Master:

• è già un Agile Coach per costruzione
• non è un Agile Coach junior
• non è qualcosa di altro rispetto all’Agile Coach

So che può sembrare strano, che questa affermazione si scontra con il sentire comune, con quello che pensiamo sia Scrum ma la verità vera (e non lo dico io: è scritto nella Scrum Guide) è che non esistono in Scrum altri ruoli al di fuori di quelli che ti ho appena descritto: uno Scrum Team costituito da un Product Owner, uno Scrum Master e dei Developer.

E tra i diversi abiti vestiti dallo Scrum Master c’è anche quello del Coach: prima di ingaggiare un Agile Coach (o comunque vogliamo chiamarlo) forse varrebbe la pena lasciare che lo Scrum Master faccia il suo mestiere!

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.[…]Scrum Masters are true leaders who serve the Scrum Team and the larger organization[…]

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams

– Scrum Guide, Nov 2020

Le nostre fonti

• Scrum.Org
• The Scrum Guide 2020
• Effetto Ringelmann
• Numero di Dunbar
• Numero di Canali di Comunicazione
• Bus Factor
• The 18 Characteristics of a Great Product Owner
• Mastering Professional Scrum, Stephanie Ockerman e Simon Reindl (Addison-Wesley Professional, 2019)
• The 8 Stances of a Scrum Master

Lasciaci un commento

• Cosa ne pensi dei ruoli di Scrum?
• Cosa ti piace e cosa non ti convince?
• Quale tra i ruoli di Scrum è quello che ti fa sorgere più dubbi e perchè?
• Quali sono e come sono interpretati i ruoli di Scrum nella tua organizzazione o nel tuo progetto?

Mi piacerebbe davvero parlarne con te: che ne dici? Perchè non mi invii i tuoi commenti?

E, se hai voglia di approfondire, dai un’occhiata ai nostri corsi online o in aula/virtual-room.

Ti aspettiamo!

Stay agile! 🏄‍♀️