Anche se abbiamo fatto cenno a più riprese ai ruoli, fin qui non abbiamo ancora illustrato nei dettagli le caratteristiche, le funzioni e le interazioni delle diverse figure coinvolte nella squadra Scrum. In questo articolo, quindi, dettagliamo i diversi ruoli presenti in un processo basato su Scrum.

La composizione di uno Scrum team

Un team Scrum è formato da tre figure o ruoli: il Product Owner, lo Scrum Master e il Dev Team (o team di sviluppo). In questo articolo parleremo delle varie attività e responsabilità che competono ai diversi ruoli e del modo con cui essi interagiscono fra loro: tutti elementi essenziali per un corretto buon funzionamento di Scrum nel progetto. Vedremo anche i confini che separano i tre ruoli e se e quando sia possibile pensare a una sovrapposizione fra i tre attori.

Il team di sviluppo e l’organizzazione delle competenze (verticali vs orizzontali)

Il team di sviluppo (o Dev Team) ha come compito principale di effettuare le operazioni di sviluppo che sono necessarie per implementare le storie che sono state inserite (o meglio accettate) nello sprint backlog durante la cerimonia dello sprint planning.

In linea coi principi del Lean e i valori dell’Agile, questo modello organizzativo prevede la creazione di un team crossfunzionale, dove  tutti membri del team acquisiscano le conoscenze e le competenze per svolgere tutte le attività necessarie per poter svolgere le tipiche attività di una qualsiasi “fabbrica del software”: si va dal processo di raccolta dei requisiti alla analisi, dalla formalizzazione del design alla implementazione vera e propria, dalla scrittura della documentazione alle fasi di test.

Questa condizione, oltre a consentire che siano prese le decisioni giuste in modo rapido ed efficace, consente al team stesso di crescere e di prendere coscienza di se’, delle tecnologie, del dominio di intervento: con il tempo infatti un team di questo tipo acquisisce tutti gli strumenti e le capacità per risolvere i problemi quotidiani e prendere le decisioni giuste, senza dover ricorrere al parere di un esperto esterno o senza la necessità di dover chiedere un parere a un responsabile (più alto in grado), il quale probabilmente non ha lo stesso grado di conoscenza e di esperienza diretta del problema specifico.

Limiti al team crossfunzionale

Nonostante i grossi benefici derivanti da una organizzazione per team crossfunzionali, non sempre questo tipo di soluzione è possibile all’interno dell’azienda, organizzazione o gruppo di lavoro: possono esserci impedimenti organizzativi, culturali, gerarchie radicate, impedimenti “politici”. Spesso il problema è che i gruppi sono composti da persone con competenze specifiche e verticali: gli analisti fanno l’analisi, i programmatori implementano, altri parlano con il cliente e così via. Quasi sempre si tratta di un problema culturale: raramente una persona nell’organizzazione non è in grado di imparare a svolgere compiti differenti da quelli che svolge abitualmente.

Alle volte i retaggi culturali presenti all’interno dell’organizzazione spingono in modo ancora più forte in questa direzione creando dei veri e propri silos verticali, dando luogo a strutture molto verticali e separate fra loro, le cosiddette “divisioni”: divisione ricerca e sviluppo, divisione commerciale, divisione produzione e così via. Questo modello organizzativo è spesso realizzato perche’ c’è la credenza che figure con una forte competenza specifica e verticale, possano apportare un contributo più prezioso all’intero gruppo.

Come si è avuto modo di vedere negli articoli pubblicati in passato su MokaByte [1], l’esperienza degli ultimi decenni ha messo in evidenza come questo modo di strutturare il lavoro e i gruppi sia lontano da essere efficace ed efficiente. Il  crescere della complessità del dominio dove ci si trova a lavorare necessita sempre più di gruppi di persone (e non di “risorse” umane), che collaborino, che decidano insieme apportando ognuno il proprio contributo fatto di esperienze, conoscenze, punti di vista. Analizzando il significato della parola si capisce come  tutto questo sia poco  realizzabile se si struttura l’organizzazione tramite divisioni.

A peggiorare le cose, spesso l’organizzazione incentiva questo approccio verticale, con incentivi e premi legati alle sorti della divisione e non del progetto a cui l’analista e il programmatore dovrebbero partecipare.

Il processo di trasformazione da sistema verticale a gruppi crossfunzionali  è lungo e faticoso, a volte doloroso. La resistenza al cambiamento può essere talmente forte da causare una reazione contraria ancora più forte: è necessario un corretto approccio, che sia fermo negli obiettivi ma pragmaticamente conscio della situazione ambientale, delle difficoltà, dei mezzi a disposizione.

Verso il team crossfunzionale

Spesso un team orizzontale, ossia contenente tutte le competenze per poter svolgere il proprio lavoro in autonomia, ma composto da persone con competenze verticali è un buon compromesso o comunque un buon punto di partenza: in questo modo infatti si rompono i silos e le divisioni, si creano gruppi di persone che lavorano insieme per il bene del progetto/prodotto e non per quello della divisione di (ex) appartenenza.

Lo step successivo (se ritenuto necessario) potrebbe essere quello di attivare quelle attività e quelle pratiche finalizzate a trasferire le competenze e le conoscenze all’interno del team. In questo modo, a tendere, il know how tecnologico e quello relativo al dominio applicativo si spandono fra le varie persone: si ottengono così benefici evidenti sia dal punto di vista culturale che organizzativo, potendo in questo modo rimuovere le dipendenze fra le persone e determinate problematiche specifiche.

Lo Scrum Master in questo percorso di crescita è sicuramente una figura molto importante in quanto facilitatore, osservatore, guida. Per quanto concerne invece la dimensione del gruppo, in genere si dice che deve rimanere abbastanza piccolo: una buona regola che suggerisce Scrum è quella di tenere il gruppo sui 7 +/- 2 elementi. Sotto i 5 probabilmente non si riesce a fare massa critica e innescare il lavoro in modo efficace. Sopra i 9 si rischia di perdere il controllo e di non riuscire a facilitare la comunicazione all’interno del gruppo, per abilitare le dinamiche di scambio e di auto-organizzazione.

Organizzazione del lavoro

Passando invece alle questioni legate all’organizzazione del lavoro quotidiano, è il team di sviluppo che sceglie, in totale libertà e autonomia, come ripartire il lavoro fra le varie persone, decidendo sia chi si debba occupare della realizzazione delle varie storie, sia chi debba svolgere determinati compiti (chi fa analisi o chi implementa).

Il team di sviluppo lavora per produrre alla fine di ogni sprint un incremento di prodotto potenzialmente rilasciabile. Lo Scrum Master, da questo punto di vista, senza imporre alcuna disciplina o regola organizzativa, monitora che il lavoro sia impostato in modo da seguire sempre un senso logico comune: per esempio per fare in modo che le conoscenze tecniche e di progetto si distribuiscano il più possibile, che non si interrompa il processo di condivisione delle pratiche di condivisione, che siano rispettati alcuni vincoli come la Definition of Done e altro ancora.

Il Dev Team può lavorare effettuando tutte le scelte che ritiene necessarie, conscio del fatto che nessuno potrà interferire relativamente al come le varie funzioni potranno essere realizzate.

Il Product Owner

Il Product Owner (PO) è la persona che all’interno del processo Scrum ha la responsabilità di gestire cosa verrà realizzato, avendo come primaria responsabilità quella di massimizzare il valore del prodotto rilasciato; il suo lavoro è prima di tutto quello di identificare bisogni di business dell’utente e di guidare la realizzazione del prodotto in modo da soddisfare tali bisogni.

Il Product Owner è quindi responsabile del cosa verrà realizzato, ma non ha alcun potere sul come: egli quindi guida la definizione degli elementi che comporranno il backlog, del suo ordinamento e della sua manutenzione. Non ha invece  alcun potere di intervenire sulle scelte tecnologiche o architetturali che invece sono in carico al team di sviluppo, a meno che certi dettagli tecnici o tecnologici facciano già inizialmente parte di un bisogno dell’utente e, per tale motivo, siano stati inclusi nel contratto.

Il Product Owner è il rappresentante sia del cliente (o committente) sia dell’utente: nel primo caso si preoccupa che lo sviluppo del progetto segua una determinata roadmap in linea con la visione  di business del committente. Per questo si interfaccia sia con i vari membri del management interno alla propria organizzazione sia con i rappresentanti presso il cliente. Nel primo caso la sua preoccupazione è quella di impostare il progetto in linea con la strategia aziendale interna. Nel secondo caso invece raccoglie tutte le indicazioni in modo che il team poi realizzi un prodotto finale in linea con i bisogni di business dell’utente.

Una visione ampia e su business e mercati

In questo senso il Product Owner ha una chiara visione del mercato, interagisce quotidianamente con clienti esistenti e soprattutto potenziali. Intervista buyers (interlocutori chiave) e utenti (quelli che nella tecnica di modeling delle personas sono le cosiddette primary user personas) per capire i loro problemi e bisogni. Ne sintetizza i risultati a garanzia di scelte di business basate e supportate da informazioni certe (dal mercato e non da opinioni) e ne cura l’attuabilità. Per tutte queste ragioni il Product Owner può essere considerato la persona più vicina agli aspetti di business  del progetto.

Il suo ruolo è anche quello di supportare l’azienda nel seguire e gestire attività legate al business:

• segue la progettazione della soluzione, guida la sua validazione sul mercato;
• guida e verifica il soddisfacimento dei requisiti di alto livello e quindi dell’iniziativa di business;
• supporta la strategia migliore per il go-to-market di prodotti e iniziative di lancio, supportando il marketing e i responsabili delle communicazioni;
• facilita decisioni (informate) riducendo il dibattito di opinioni (personali) e portando sul tavolo “fatti di mercato”;
• bilancia attività tattiche con quelle strategiche facendo sempre riferimento alla visione e alla strategia dell’azienda;
• conosce a livello qualitativo la concorrenza o può approfondirne la conoscenza se e quando opportuno con strumenti o metodologie appropriate.

Il Product Owner e il backlog

Affinche’ tutti gli stakeholder (interni ed esterni) abbiano chiaro il lavoro da svolgere, il Product Owner (PO) gestisce il product backlog in modo chiaro e trasparente in modo che sia visibile a tutti gli interessati: le sue decisioni sono quindi ricavabili in modo chiaro e diretto analizzando il contenuto e l’ordine del product backlog.

Il lavoro di gestione, manutenzione e raffinamento del backlog potrà essere eseguito dai vari collaboratori, anche se poi è comunque il Product Owner ad esserne responsabile ultimo: ogni variazione deve essere da lui vagliata e autorizzata.

Data l’importanza di questo compito, spesso il Product Owner si avvale di collaboratori (vice Product Owner) in modo da garantire continuità e assorbire eventuali impedimenti; in tal caso è estremamente importante che il Product Owner parli e decida come una persona sola, non come un comitato.

Tranne il Product Owner, nessuno altro all’interno dell’organizzazione ha  potere di interferire sul cosa deve essere fatto: egli è l’unico autorizzato a dire al team di sviluppo cosa fare, che parti realizzare, se aggiungere funzionalità o  lavorare con un diverso ordine di priorità. Per lo stesso motivo, nessuno dei membri del  team di sviluppo è autorizzato ad ascoltare qualcun altro che non sia il Product Owner per quanto concerne le cose da fare e il relativo ordine.

Le responsabilità del PO

Di seguito sono riportate alcune responsabilità tipiche di un Product Owner:

• avere la vision del prodotto;
• massimizzare il ritorno sull’investimento più che realizzare tutte le funzionalità del prodotto;
• gestire il ROI: verificare continuamente (sul mercato) il valore del prodotto mediante il rilascio continuo di funzionalità di valore;
• gestire il market & research;
• essere la voce del cliente;
• definire la roadmap;
• definire gli obiettivi di progetto;
• definire le metriche di successo;
• fare il release planning;
• gestire il product backlog;
• partecipare alle cerimonie (sprint planning, sprint review ed eventualmente, se invitato dal team, alla retrospettiva);
• definire (o accettare) le storie:
• lavorare a stretto contatto con il team di sviluppo;
• gestire le relazioni con gli stakeholder;
• gestire o avere una chiara idea del budget.

In riferimento alla figura del Product Owner, alcune delle responsabilità sono decisamente imprescindibili dal ruolo; altre invece non è detto che ricadano sempre sotto il suo controllo diretto. In aziende di dimensioni medio/grandi o con un’organizzazione funzionale, il Product Owner potrebbe non avere, ad esempio, responsabilità diretta della roadmap o occuparsi in prima persona della gestione di market & research.

Lo Scrum Master

Lo Scrum Master (SM) può essere considerato il coach o il facilitatore che si premura che all’interno del gruppo il lavoro proceda al meglio, nel modo corretto e più spedito possibile. Oltre che a preoccuparsi degli aspetti legati al lavoro di gruppo (quindi aspetti organizzativi) egli è l’owner del processo Scrum: questo vuol dire che egli si preoccupa che il gruppo lavori seguendo le indicazioni e le regole del processo, per esempio che i  ruoli siano rispettati, che le pratiche siano eseguite secondo i principi “canonici”, e che i vari manufatti (storie, sprint e product backlog, burndown chart) siano sempre gestiti in modo corretto. In alcuni casi egli può intervenire in prima persona: per esempio può aggiornare il burndown o altri importanti information radiator come la roadmap di progetto, l’elevator pitch, la skill matrix del team, il working agreement e altro ancora. Il suo obiettivo in questo caso è quello di evidenziare a tutti gli interessati (Product Owner e Dev Team in primis) lo stato di avanzamento del progetto.

Sguardo elevato, ascolto continuo

In qualità di coach lo Scrum Master deve sempre sapere quello che succede: non deve quindi  stare a testa bassa sul progetto, ma osservare con occhi oggettivi e ascoltare con orecchi attenti quello che succede. In questo senso prende nota di comportamenti disfunzionali e non efficienti, tiene traccia di eventuali errori e quindi riporta in fase di retrospettiva il suo punto di vista in modo che sia discusso e valutato da tutto il gruppo.

In quanto owner di processo, lo Scrum Master promuove momenti di approfondimento e spiegazione di Scrum e di quanto possa essere utile per comprendere meglio come si lavora e di come funzione la metodologia. La sua massima preoccupazione è quella che il gruppo lavori sempre in linea coi principi dell’Agile e del Lean.

Nonostante il nome possa trarre in inganno, lo Scrum Master non è un “capo”, ne’ mette in atto politiche in stile “command & control”, che abbiamo visto sono totalmente avulse dallo spirito e dai valori di agile e di scrum.

Facilitazione e protezione

Un altro importante settore di intervento dello Scrum Master è quello legato alla rimozione degli  impedimenti che possano rallentare o bloccare lo sviluppo del progetto. In questo caso potrà per esempio preoccuparsi che l’ambiente di lavoro sia consono (aria condizionata, spazio, lavagne etc.), ma anche che tutti abbiano gli strumenti per lavorare in modo proficuo (strumenti di lavoro installati e funzionanti, che tutti abbiamo le conoscenze per poter fare…).

Un ulteriore compito che sovente viene associato allo Scrum Master è quello di proteggere il team da perturbazioni esterne: per svolgere al meglio questo suo compito si dice spesso che egli deve essere un uomo di management (è una delle domande che si trovano nell’esame di certificazione redatto dalla ScrumAlliance).

Sono entrambe definizioni corrette, anche se spesso danno luogo a fraintendimenti. Se per protezione si intende impedire che al team di sviluppo arrivino “sottobanco”  richieste di lavoro che non seguano il processo canonico (storie create dal Product Owner,  inserite nel product backlog, travasate in fase di planning nello sprint backlog), allora protezione è un termine corretto. Se per protezione si intende evitare che il gruppo sia costantemente interrotto con attività, con richieste, distrazioni del tutto inutili che invece potrebbero essere dirottate su altre persone, anche in questo caso il termine protezione è ben inteso.

Proteggere però può avere anche una valenza negativa: un approccio troppo rigido che punti a impedire ogni forma di contatto fra il team e il resto dell’organizzazione non è probabilmente la strategia migliore sia per i possibili effetti sul gruppo che sull’organizzazione. Da un lato lo Scrum Master si può ritrovare a impersonare il ruolo di “padre protettivo” che tutto filtra e tutto maschera (e rileggendo gli articoli sugli aspetti psicologici del team management [2], ci ricordiamo che seguendo questo approccio oltre a non far crescere le persone, si rischia di mortificarle).

D’altro canto, l’isolamento del team rispetto al resto dell’organizzazione potrebbe risultare controproducente per l’organizzazione stessa: la possibilità di svolgere, di tanto in tanto, attività extra-progetto non solo può essere necessario (si pensi alla manutenzione di altri prodotti in produzione),  ma potrebbe avere importanti ricadute sia per l’organizzazione che per lo stesso team (per esempio coinvolgendo qualche elemento più esperto del team in attività di visioning  per altri prodotti/progetti).

Comunicazione con il management

In casi come questi la cosa migliore che può fare un buon Scrum Master è quella di evidenziare al  management tutte le conseguenze e le ricadute derivanti dalle perturbazioni, in maniera tale che si possano prendere decisioni in modo più oggettivo. In questo senso è vero quindi che lo Scrum Master deve essere un uomo di management: non tanto per decidere le manovre necessarie per rimuovere ogni impedimento, ma piuttosto per potere parlare col management con un linguaggio comune e una visione condivisa così da riportare una fotografia chiara e parlante delle conseguenze delle varie azioni prese a vario livello.

Volendo sintetizzare con una frase la missione dello scum master si potrebbe dire che egli deve fare in modo che le cose accadano: che il progetto proceda in modo controllato, che il team svolga il proprio lavoro nel migliore dei modi, che le informazioni circolino, che la cultura del gruppo cresca e che il tutto rientri all’interno delle poche ma essenziali regole di scrum.

Servant leadership

In questo contesto lo Scrum Master viene spesso descritto con una metafora molto usata e molto popolare: egli è il servant leader del gruppo, ossia una guida, sì, ma al servizio del gruppo. È leader nel senso collaborativo del termine: non è l’eroe che si trascina l’esercito verso la battaglia finale, ma è colui che vive dentro il gruppo, lo motiva e lo stimola; rappresenta il punto di riferimento in caso di dubbi o incertezze; non comanda, ma mostra errori o cose fatte bene; cerca di riportare il lavoro nell’ambito del corretto modo di agire. In questo senso è quindi al servizio del gruppo.

L’uso del termine servant purtroppo potrebbe in alcuni casi dar luogo a interpretazioni errate circa il reale ruolo dello Scrum Master e delle responsabilità del resto del team. Egli infatti è al servizio del team per rimuovere attivamente impedimenti e aggirare ostacoli; questo non significa che il resto del gruppo può starsene con le mani in mano. Il team è una squadra dove la suddivisione di ruoli e delle responsabilità: non deve diventare una scusa per non intervenire direttamente sulla soluzione di un problema. Infine il concetto di servant potrebbe far credere che egli sia al servizio degli altri ma non partecipi poi direttamente al lavoro importante.

In tal senso una nuova e alternativa definizione descrive lo Scrum Master come l’host leader ispirandosi al “padrone di casa” di una ipotetica festa: in questo caso si preoccupa che tutto funzioni, che cibo e musica siano al loro posto, controlla che nessuno esageri disturbando la festa e che tutti si divertano. Probabilmente lui è il punto di riferimento per le persone ma non fa pesare questo suo ruolo, conscio che la festa funziona meglio se tutti si divertono e se tutti sono allo stesso livello. Insieme agli altri partecipa alla festa e si diverte con gli altri.

Il concetto di hosting leadership, per quanto recente, sta avendo molto successo nell’ambito del coaching: si possono infatti già trovare interessanti approfondimenti in rete [3].

Risposte a domande frequenti sullo Scrum Master

Di seguito sono riportate le risposte ad alcune domande che spesso sono poste relativamente alla figura dello Scrum Master.

Qual è la persona adatta a ricoprire questo ruolo?

Spesso ci si domanda, specialmente quando si deve procedere alla costruzione di un nuovo team scrum, quali siano le caratteristiche umane e professionali che caratterizzano un buon Scrum Master, ossia, detto in altre parole, chi può impersonare questo ruolo.

La risposta non è semplice, ma qualche indicazione si può fornire: se si ripensa alla metafora del servant leader o meglio ancora della host leadership, si comprende come lo Scrum Master sia prima di tutto una persona con una spiccata propensione all’ascolto e alla gestione dei rapporti interpersonali. Egli deve prima di tutto capire cosa succede nel gruppo e tenere sotto controllo ogni variazione di equilibri all’interno e all’esterno del team. Deve intercettare i bisogni di tutti e farsi carico o portavoce verso l’esterno delle necessità del gruppo. Non deve imporre la sua posizione, per esempio per risolvere un conflitto interno, ma deve facilitare il dialogo. Deve avere abbastanza autorità verso il management (primo fra tutti verso il PO) in modo da essere ascoltato e  riuscire a evidenziare eventuali problemi che derivino da scelte errate.

Come si nomina, sceglie, incarica lo Scrum Master?

Aspetto pratico molto importante è legato al come si sceglie (nomina, incarica, elegge, etc.) lo Scrum Master all’interno del gruppo. Se infatti per il Product Owner in genere la scelta segue dinamiche più o meno prestabilite, in base a decisioni prese più o meno dall’alto, lo Scrum Master è una persona che il team si sceglie in totale autonomia. Normalmente, in fase di formazione del team, il gruppo seleziona democraticamente la persona che ritiene più indicata, magari selezionando solo fra coloro che sentono di poter o di voler ricoprire questo incarico). Il management, il Product Owner o chiunque altro non dovrebbero interferire con questa scelta.

Una raccomandazione è quella di evitare sovrapposizioni fra il ruolo dello Scrum Master e quello per esempio di Subject Matter Expert (SME) dato che, per tipo di responsabilità e ruolo, si possono verificare spesso conflitti di interesse; un caso tipico è per esempio quello dell’architetto di sistema il quale, vuoi per esperienza vuoi per “anzianità”, spesso finisce per avere un ruolo di responsabilità all’interno dell’organizzazione. In casi come questo non è infrequente trovare una persona che in qualità di architetto di sistema imponga determinate soluzioni tecniche e come Scrum Master avalli tale imposizione.

Si possono provare più Scrum Master a rotazione?

Talvolta lo Scrum Master può trovarsi in difficoltà nello svolgere il  proprio lavoro, tanto che verrebbe spontaneo provare a cambiarlo, magari facendo provare qualcun altro del team. Per quanto possibile è meglio non assecondare questa possibilità, tentando di fare tutto il possibile, e qualcosa di più, per aiutare il nuovo Scrum Master nel crescere e nel migliorare il suo lavoro.

In tal senso il team può aiutare molto lo Scrum Master, sia sostenendolo apertamente, sia aiutandolo a identificare gli errori, le carenze, gli eventuali punti di miglioramento e tutto quanto possa permettergli di crescere. Utile certamente, in questo percorso di crescita, è l’affiancamento di un coach agile esterno all’organizzazione.

Come passa il suo tempo “per davvero”?

Normalmente quando un nuovo team inizia a lavorare con Scrum, in tutti, e in special modo nello Scrum Master, sorgono alcuni dubbi: come  tradurre nella pratica tutto quello che si impara partecipando ai corsi o leggendo dei libri? Detto in altri termini: cosa deve “realmente” fare lo Scrum Master, e quindi quanto tempo dedicare al lavoro di coaching col team?

Un buon modo per iniziare è provare a mettere in pratica alcune delle cose che si sono imparate sui libri; per esempio farsi carico di monitorare lo stato di avanzamento è un ottimo modo per iniziare a prendere la mano con il proprio lavoro. Gestire i vari information radiator, controllare il trend della velocity del gruppo e di conseguenza aggiornare il burndown sono attività che permettono di “partire” con qualcosa e che al contempo permettono di capire cos’altro fare e come intervenire per migliorare le performance del gruppo.

Lo Scrum Master deve però fare un’altra cosa importante: deve studiare e confrontarsi con altre figure professionali che possano aiutarlo.  Non deve dare nulla per scontato e quindi va benissimo seguire quello che trova scritto, ma sempre con un atteggiamento sanamente critico, nel costante tentativo di trovare nuove soluzioni o nuovi approcci al problema “miglioramento del team”.

Il lavoro dello Scrum Master è un lavoro a tempo pieno? Può svolgere altri ruoli o compiti?

Dal punto di vista del tempo a disposizione possiamo dire che, specialmente all’inizio, è probabile che allo SM avanzi un po’ di tempo: potrebbe quindi dedicarsi ad altre attività. Se possibile, proprio nell’ottica di investire su un percorso di crescita, sarebbe opportuno non dedicare energie ad altre attività diverse da quelle del mestiere di Scrum Master. Se la dimensione dell’organizzazione lo permette, potrebbe dedicare il suo tempo a seguire più di un team (magari soluzione da evitare per chi è alle prime armi). In alternativa, lo Scrum Master può dedicarsi al lavoro all’interno del gruppo, per esempio come membro attivo del team di sviluppo.

Questa configurazione, che è piuttosto frequente all’interno di molte organizzazioni, è compatibile con le responsabilità e attività dei due ruoli. Nel libro “Essential Scrum” [4] sono riportate alcune statistiche che mostrano come il fatto di avere nella struttura una persona che a tempo pieno svolge il lavoro di Scrum Master (e che potrebbe essere percepita come un costo puro) possa aumentare non di poco le performance del gruppo (di un coefficiente maggiore del costo di avere una persona che  “non produce”).

Conclusione

Con questo articolo si sono visti i differenti ruoli coinvolti nel processo Scrum: Dev Team, Product Owner, Scrum Master, analizzando le loro caratteristiche, i loro compiti e le loro responsabilità. Con la prossima puntata inizieremo a parlare di stime agili.

Riferimenti

[1] Giovanni Puliti, “Management dal semplice al complesso – I parte: Il Project Management e l’evoluzione della complessità dei sistemi”, MokaByte 183, aprile 2013, e articoli successivi

https://www.mokabyte.it/cms/article.run?articleId=1UD-SCY-JFM-N8O_7f000001_26089272_f2161e34

[2] Giovanni Puliti, “Aspetti psicologici nella gestione di progetto – II parte: Cosa sono e come si interpretano le transazioni”, MokaByte 175, luglio/agosto 2012

https://www.mokabyte.it/cms/article.run?articleId=2FX-QKF-4GG-G52_7f000001_10575677_6b9a1c88

[3] Il sito che illustra il concetto di “host leadership”

http://hostleadership.com

[4] Kenneth S. Rubin, “Essential Scrum: a practical guide to the most popular agile process”, Addison-Wesley, 2012

[5] Giovanni Puliti, “Verso l’Agile – II parte: Miti, fatti e pianificazione”, MokaByte 189, novembre 2013

https://www.mokabyte.it/cms/article.run?articleId=S6J-QCM-7YV-4GY_7f000001_11231952_6cdbbe92

[6] Mitch Lacey, “The Scrum field guide: practical advice for your first year”, Agile Software Development Series, 2012

Giovanni Puliti

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.