Il team Scrum e i ruoli

Le responsabilità all'interno di uno Scrum Team sono tre: il Product Owner, lo Scrum Master e i Developer (traducibile in italiano con sviluppatori); tutti insieme formano lo Scrum Team.

Come già sottolineato in un precedente articolo il team Scrum è auto organizzato, o meglio ancora autogestito, e ha al suo interno tutte le competenze utili allo svolgimento dei propri compiti, senza dipendenze da gruppi di lavoro esterni. Per questo motivo si dice che è anche cross-funzionale.

Le competenze richieste all'interno di un team Scrum variano a seconda del tipo di prodotto attorno al quale il team opera, e includono per esempio: sviluppatori (frontend e backend), architetti, UX designer, amministratori di sistema, eccetera. In Scrum non esiste il ruolo di "tester" e la gestione di questo aspetto fondamentale è responsabilità dei Developer.

Team autogestito

Si dice che il gruppo è autogestito in quanto ha la facoltà di decidere autonomamente quali strategie mettere in atto per completare il lavoro, piuttosto che essere diretto e organizzato da altri attori al di fuori del team.

Questo modello è stato concepito per massimizzare la produttività, la flessibilità e la creatività, e insieme ai rilasci continui e incrementali assicurano, potenzialmente, che una versione funzionante del prodotto sia sempre disponibile.

Il Product Owner

Il Product Owner ha la responsabilità di massimizzare il valore del prodotto risultante dal lavoro dello Scrum Team. Il ROI può contribuire a definire quel valore, ma Scrum non attribuisce necessariamente al Product Owner la responsabilità diretta dei profitti o delle perdite. Il Product Backlog è una lista ordinata di ciò che serve per migliorare il prodotto.

Il Product Owner decide quali attività mettere in cima al Product Backlog in base al valore di business, ma in pratica il termine "valore" può essere talmente soggettivo da essere influenzato dai desideri e le aspettative dei committenti, da strategie e obiettivi, da rischi, benefici e miglioramenti che si intendono apportare al prodotto. In alcuni casi il committente e il Product Owner sono la stessa persona, ciò è valido per esempio in progetti interni. In altri casi il committente può essere un cliente per cui si gestisce lo sviluppo di un prodotto.

Oltre all'ordinamento del Product Backlog, il Product Owner ha anche la responsabilità di definire e comunicare un Product Goal, ovvero un obiettivo a lungo termine per il prodotto.

Il Product Owner è diverso dal tradizionale Product Manager in quanto interagisce attivamente con il team, ne gestisce le priorità e ne esamina il lavoro, piuttosto che delegare tutte le decisioni relative allo sviluppo ad un Project Manager. In ogni Scrum Team c'è una sola persona con la responsabilità di Product Owner, che rimane accountable per la massimizzazione del valore del prodotto.

Affinché Il Product Owner abbia successo, l'intera organizzazione deve rispettare le sue decisioni relative al prodotto. Decisioni che sono rese trasparenti e visibili attraverso l'ordinamento del Product Backlog.

I Developer

I Developer (o in italiano sviluppatori), chiamati in versioni precedenti di Scrum "Development Team", si impegnano a creare ogni aspetto di un Increment utilizzabile e non si limitano a realizzare funzionalità indicate dal Product Owner. Questo gruppo di Developer include al suo interno tutto un insieme di skill che sono necessarie per creare valore, senza dover dipendere da team esterni. Come già detto in precedenza il team è anche autogestito e gode di un alto livello di autonomia e di responsabilità.

All'inizio di ciascuno Sprint il Product Owner presenta le priorità e propone come aumentare il valore del prodotto; i Developer selezionano gli elementi del Product Backlog e preparano il piano per raggiungere lo Sprint Goal con le modalità di lavoro che ritengono adeguate.

Il numero ideale per un team Scrum è indicato come meno di 10 persone. Gruppi più piccoli hanno infatti una migliore comunicazione e sono più produttivi.

Come accennato in precedenza, in uno Scrum Team gli sviluppatori hanno capacità su un ampio numero di materie come: analisi, design, test, database, frontend, backend, e così via. In progetti per cui è richiesto un numero più alto di sviluppatori, è possibile organizzare diversi gruppi di lavoro, ciascuno focalizzato su diverse parti del prodotto, ma con continua e stretta collaborazione reciproca.

I Developer non si limitano a realizzare quanto descritto nel Product Backlog, ma danno anche indicazioni e suggerimenti al Product Owner al fine di migliorare il prodotto. In Scrum si ottengono i risultati migliori quando il team è dedicato al 100% sul prodotto. Sarebbe meglio evitare, nel limite del possibile, il multitasking e persone allocate su diversi progetti. Team stabili sono spesso sinonimo di produttività alta.

Lo Scrum Master

Che cosa fa lo Scrum Master, invece? Lo Scrum Master ha il compito di aiutare il team ad essere efficace e a raggiungere gli obiettivi attraverso la pratica di Scrum. Non è un Project Manager o il manager dei Developer, ma una figura chiave nel facilitare il gruppo e nel fare in modo che gli impedimenti al progresso vengano rimossi. Spesso viene definito un "servant leader", un leader a servizio del proprio team. Ma di fatto è un vero leader a servizio non solo del team ma anche dell'organizzazione.

Un buon Scrum Master educa e guida l'intero gruppo di lavoro all'uso di Scrum e fa in modo che chiunque, inclusi il Product Owner e il management dell'azienda, ne comprendano e ne seguano i principi e le pratiche. Lavora affinché gli impedimenti che possono compromettere la riuscita di uno Sprint o di un intero progetto vengano rimossi, senza doverli necessariamente risolvere in prima persona.

Scrum non prescrive che lo Scrum Master lavori a tempo pieno su un solo team. Nei team più piccoli la responsabilità può essere assunta da uno dei membri del gruppo che magari dedica parte del suo tempo nell'attività. Anche se non è proibito dalla guida di Scrum, è preferibile che Product Owner e Scrum Master non siano la stessa persona, dato che a volte capita che lo Scrum Master debba tenere a bada un Product Owner troppo proattivo e insistente.

A differenza di un Project Manager, lo Scrum Master non assegna task ai membri del team e non dice loro che cosa devono fare, ma facilita il processo aiutando il team ad auto gestirsi e organizzarsi.

Leggi anche: Le sei istanze di uno Scrum Master di successo

Perché parliamo di responsabilità e non di ruoli?

Avrai notato che in questo articolo parlo di "responsabilità" piuttosto che di "ruoli". Questa scelta non è casuale. La Scrum Guide infatti utilizza il termine "accountability" (responsabilità) e non "role" (ruolo), e c'è una differenza importante tra i due concetti.

Un ruolo tende a definire una posizione fissa con compiti prestabiliti, spesso associata a un titolo professionale. Una responsabilità, invece, rappresenta un impegno verso un risultato specifico, indipendentemente dal titolo che una persona ha all'interno dell'organizzazione. In Scrum, Product Owner, Scrum Master e Developer sono responsabilità che qualcuno nel team deve assumersi, ma ciò non significa necessariamente che questi siano i titoli di lavoro delle persone coinvolte.

Questa distinzione sottolinea la natura flessibile e collaborativa di Scrum: ciò che conta non è il titolo sulla porta, ma chi è "accountable" per un determinato risultato e come il team lavora insieme per raggiungerlo.