Lavoro di squadra coordinato Scrum
La base di Scrum, il più popolare framework di gestione Agile, è iniziata con un articolo della Harvard Business Review del 1986 scritto da Hirotaka Takeuchi e Ikujiro Nonaka. Nell'articolo, Takeuchi e Nonaka hanno introdotto il termine "Scrum" evidenziando le strategie di lavoro utilizzate dalle squadre per segnare punti e hanno suggerito che i team di sviluppo del prodotto potrebbero utilizzare metodi simili per migliorare i loro tassi di successo.
La ricerca presentata nell'articolo indicava che i piccoli team auto-organizzati avevano prestazioni significativamente migliori su prodotti complessi quando ai team venivano assegnati gli obiettivi ma avevano la libertà di scegliere come raggiungerli da sé.
Ken Schwaber e Jeff Sutherland hanno sviluppato la struttura Scrum e formalizzato i ruoli dei membri del team Scrum negli anni '90. Nel 1995, hanno pubblicato un documento intitolato "SCRUM Software Development Process." Dopo aver gradualmente apportato altri miglioramenti a Scrum e aver pubblicato altri documenti, Schwaber e Sutherland hanno completato la prima pubblicazione della Guida Scrum nel 2010.
La Guida Scrum si riferisce a Scrum e ai suoi ruoli di team come "struttura all'interno della quale le persone possono affrontare problemi di adattamento complessi, fornendo al contempo in modo produttivo e creativo prodotti del massimo valore possibile. ... Il framework Scrum è costituito dai team Scrum e dai ruoli, dagli eventi, dagli artefatti e dalle regole associati."
Le descrizioni all'interno della Guida Scrum sui ruoli del team affermano che il "team Scrum è composto da un product owner, dal team di sviluppo e da uno Scrum Master. I team Scrum sono autoorganizzanti e interfunzionali. I team che si auto-organizzano scelgono il modo migliore per portare a termine il proprio lavoro, piuttosto che essere diretti da altri al di fuori del team. I team interfunzionali hanno tutte le competenze necessarie per portare a termine il lavoro senza dipendere da altri che non fanno parte del team. Il modello team in Scrum è stato progettato per ottimizzare flessibilità, creatività e produttività. I team Scrum forniscono i prodotti in modo iterativo e incrementale, massimizzando le opportunità di feedback."
Schwaber e Sutherland hanno rilasciato un'edizione aggiornata della Scrum Guide nel luglio 2016. Il contenuto più importante aggiunto all'edizione 2016 è la sezione Valori Scrum, che include dettagli su come i membri dei team Scrum dovrebbero interagire tra loro e con gli altri dipendenti dell'azienda.
Guida alla gestione dei progetti
Il tuo punto di riferimento per la gestione di tutti i progetti
Vuoi ottenere di più dai tuoi sforzi di gestione dei progetti? Consulta la nostra guida completa alla gestione dei progetti per suggerimenti, best practice e risorse gratuite per gestire il tuo lavoro in modo più efficace.
Raccomandazioni per le dimensioni del team Scrum
Per ottenere un team Scrum più coeso e massimizzare il livello di lavoro all'interno del gruppo, gli esperti spesso offrono consigli sulle dimensioni del team. Schwaber, che fornisce formazione Scrum attraverso la sua organizzazione Scrum.org, offre raccomandazioni sulle dimensioni del team nel suo libro del 2007, The Enterprise and Scrum. Schwaber spiega che i team Scrum dovrebbero essere "di dimensioni limitate per massimizzare la velocità, il contenuto, l'accuratezza e la larghezza di banda delle comunicazioni. Le dimensioni del team devono essere di massimo nove persone."
Più avanti nel suo libro, Schwaber offre i seguenti consigli: "Mantieni le dimensioni del team il più vicino possibile a sette. Sette menti sembrano in grado di raggiungere e mantenere un modello mentale condiviso di un sistema, nonché la sua rappresentazione nella progettazione e nel codice senza aiuti artificiali come la documentazione. Le incomprensioni e il tempo di registrazione sono ridotti al minimo."
Mindi Schnase, project manager per Renown Health, ha una certificazione CSM (Certified ScrumMaster) da Scrum Alliance e una come PMP (Project Management Professional) dal PMI (Project Management Institute). Presso l'International Game Technology (IGT), suo precedente datore di lavoro, Schnase ha lavorato come ingegnere responsabile dell'assicurazione della qualità prima di passare al ruolo di Scrum Master. L'esperienza di Schnase ha comportato il lavoro su team Scrum di diverse dimensioni.
Schnase afferma che sette-nove persone per team sono una dimensione buona e gestibile, ma spiega anche che le dimensioni del team sono influenzate dalle specifiche del progetto. "Dipende davvero dall'ambito del progetto. Sono stata Scrum Master per diversi team; uno aveva tre membri, altri da sette a 10."
Sutherland, che continua a tenere corsi Scrum attraverso la sua organizzazione Scrum Inc., ha incluso molte informazioni sulle dinamiche del team sul sito web della sua organizzazione, tra cui la seguente analisi sulle dimensioni e la produttività del team:
"Lawrence Putnam, una figura leggendaria nello sviluppo di software, ha studiato tutta una vita quanto tempo ci vuole per fare le cose e perché. Il suo lavoro continuava a dimostrare che i progetti con venti o più persone risultavano più problematici rispetto a quelli con cinque o meno. E non di poco. Così ha esaminato 491 progetti di medie dimensioni in centinaia di aziende diverse. Si trattava di progetti che richiedevano la creazione di nuovi prodotti o funzionalità, non una riproposizione di versioni precedenti. Ha diviso i progetti per le dimensioni del team e ha notato subito qualcosa. Una volta che i team sono cresciuti a oltre otto membri, hanno impiegato molto più tempo per portare a termine le cose. I gruppi composti da tre a sette persone hanno richiesto circa il 25% dello sforzo di gruppi da nove a venti persone per ottenere la stessa quantità di lavoro svolto."
Dagli esperti sembra che sette membri del team siano il numero magico. Tuttavia, non aver paura di modificare la quantità di membri in base a progetti specifici.
Il flusso di lavoro e gli eventi Scrum rendono i team Scrum più efficaci
Team di tutte le forme e dimensioni partecipano a un particolare flusso di lavoro quando prendono la decisione di seguire Scrum nell'ambito della gestione dei progetti Agile. Gli eventi Scrum hanno uno scopo prezioso: incoraggiano una comunicazione regolare, soprattutto tra i membri del team, e minimizzano la necessità di riunioni extra non definite in Scrum.
Senza incorporare gli eventi Scrum nei loro programmi, i team non sarebbero così efficaci o concentrati. L'elenco seguente rappresenta il tipico flusso di lavoro utilizzato dai membri del team Scrum per lo sviluppo del prodotto.
Visione del prodotto: il product owner riassume la visione del prodotto in una dichiarazione dopo aver ricevuto input da varie fonti, tra cui utenti finali, clienti, membri del team e altri stakeholder. La dichiarazione di visione del prodotto include dettagli di business case sugli obiettivi del prodotto e su come il prodotto si inserisce nelle strategie dell'azienda.
Backlog e perfezionamento del prodotto: gli elementi di backlog di prodotto rappresentano tutto ciò che può essere consegnato per un progetto in modo indipendente. La maggior parte di questi elementi si concentra sulla fornitura di valore ai clienti, proprio come fanno le caratteristiche del prodotto e le user story. Le user story presentano scenari specifici e dettagliati per spiegare ciò che gli utenti realizzeranno con una nuova funzione. I backlog di prodotto possono anche includere requisiti di mercato, specifiche, casi d'uso e altri elementi.
Il product owner assegna la priorità agli elementi di backlog di prodotto in base al valore aziendale rappresentato da ogni elemento. In generale, l'80% del valore di un prodotto si trova nel 20% delle sue caratteristiche. L'assegnazione di un valore aziendale per dare priorità agli elementi di backlog di prodotto garantisce che le funzionalità più apprezzate siano create per prime. Gli elementi nella parte superiore del backlog di prodotto sono ben definiti e inclusi in uno Sprint imminente; altri elementi devono invece essere perfezionati durante una riunione di perfezionamento del backlog di prodotto.
Alcuni product owner e team di sviluppo organizzano una riunione di perfezionamento del backlog di prodotto verso la metà o la fine dello sprint corrente per perfezionare ulteriormente gli elementi di backlog di prodotto per gli sprint futuri. Altri team Scrum considerano il perfezionamento come un processo in corso.
Esecuzione di sprint efficaci: i due passaggi seguenti saranno completati per aiutare i team a eseguire sprint efficaci. Uno sprint (a volte chiamato iterazione di lunghezza fissa) è il periodo di tempo in cui i team completeranno una singola iterazione di lavoro prima di riconvocarsi e prepararsi per la successiva, ed è una componente importante della gestione dei progetti Agile.
- Pianificazione degli sprint: il product owner, lo Scrum Master e il team di sviluppo si incontrano durante una sessione di pianificazione degli sprint per scegliere gli elementi di backlog di prodotto per il prossimo sprint e impegnarsi a raggiungere un obiettivo. I membri del team di sviluppo selezionano gli elementi nella parte superiore del backlog di prodotto fino a quando non hanno abbastanza lavoro per riempire il periodo di tempo dello sprint. Gli elementi selezionati vengono spostati in un backlog di sprint.
- Backlog di sprint e bacheca Scrum: tutti gli elementi del backlog dello sprint devono essere completati entro la fine dello sprint. Per garantire un senso di responsabilità condivisa, gli elementi sono collocati in una delle colonne, generalmente etichettate come Da fare, Lavoro in corso (WIP) e Fatto, su una bacheca Scrum fisica o digitale (task board). La bacheca Scrum deve essere visibile all'intero team e gli elementi associati (spesso scritti su note adesive come attività o user story) devono riflettere lo stato dello sprint in tempo reale. Seguire questa linea guida consente al team di apportare modifiche se un determinato elemento è in ritardo.
Sprint: gli sprint durano da una a quattro settimane. Ogni sprint rappresenta un breve ciclo di sviluppo e si traduce in un aumento del prodotto (ufficialmente noto come aumento di prodotto potenzialmente spedibile) o nel prodotto finito. I team non sono sempre in grado di completare un incremento di prodotto che sia spedibile, soprattutto all'inizio; tuttavia, questo è un aspetto che il team dovrebbe sforzarsi di perseguire come miglioramento nel tempo.
Scrum giornaliero: durante ogni sprint, i membri del team di sviluppo partecipano a riunioni giornaliere di stand up note come scrum giornalieri. La durata massima della riunione è di 15 minuti perché i partecipanti condividono solo le risposte a tre domande di base: 1) Cosa è stato realizzato dall'ultima riunione?, 2) Cosa verrà fatto prima della riunione successiva e 3) Quali ostacoli si incontrano?
Lo scopo di questa riunione è dare al team di sviluppo l'opportunità di coordinare gli sforzi, sincronizzare il lavoro e segnalare gli ostacoli (problemi tecnologici, ostacoli al reparto, ecc.). Questo non è il tipo di riunione in cui i dipendenti danno al proprio manager un report sull'avanzamento. Lo Scrum Master può partecipare per scoprire quali ostacoli deve risolvere, ma il product owner di solito non partecipa.
Riunione "Scrum of Scrums": una dichiarazione in evidenza dell'istruttore di Scrum Mike Cohn al sito web di Scrum Alliance descrive la riunione Scrum of Scrum come "una tecnica importante per scalare Scrum su grandi team di progetto. Queste riunioni consentono a gruppi di team di discutere del proprio lavoro, concentrandosi in particolare sulle aree di sovrapposizione e integrazione. Immagina un progetto perfettamente bilanciato composto da sette team, ciascuno con sette membri. Ciascuno dei sette team conduce (simultaneamente o in sequenza) la propria riunione di scrum giornaliero. Ogni team designa quindi una persona per partecipare anche a una riunione di Scrum of Scrums."
Alle riunioni Scrum of Scrum gestite da Schnase, i partecipanti includevano Scrum Master, product owner, responsabili tecnici, nonché alcuni responsabili QA, sponsor di programma e responsabili di reparto che erano direttamente collegati ai progetti a cui i team Scrum stavano lavorando. "Ogni due settimane, tenevamo una riunione Scrum of Scrum per discutere i risultati raggiunti, le milestone, i progressi, le dipendenze e gli ostacoli", afferma Schnase.
Revisione dello sprint: alla fine di ogni sprint, il team conduce una revisione dello sprint (nota anche come revisione dell'iterazione o demo dello sprint) per dimostrare agli stakeholder la funzionalità del prodotto creata durante lo sprint, con le persone direttamente interessate dal risultato del prodotto. Le revisioni degli sprint o le dimostrazioni di sprint sono un'opportunità preziosa anche per dimostrare il prodotto alle persone che utilizzano il software e possono fornire feedback immediati.
Retrospettiva dello sprint: dopo la revisione dello sprint, il team Scrum partecipa a una riunione retrospettiva per discutere i successi e i difetti dello sprint e fare piani per miglioramenti. Un altro scopo della retrospettiva è quello di sviluppare ulteriormente il processo e le pratiche utilizzate dal team Scrum e renderlo più efficace per il prossimo sprint.
Il team trova anche il modo di aumentare la qualità del prodotto e, se necessario, modificare gli elementi in base alla definizione di quanto completato. "The Basics of Scrum" in Scrum Inc. definisce la definizione del valore "fatto": "Un elemento del backlog è pronto se è indipendente, attuabile, gli è stato assegnato un valore a punto e ha una chiara definizione dei criteri che significano che è stato fatto. Questa a sua volta viene definito come la definizione di "fatto", che garantisce che tutti sappiano esattamente cosa ci si aspetta da un elemento al momento della consegna."
Modello di sviluppo team Scrum
Per costruire un team Scrum efficace, Schnase afferma che è importante che tutti abbiano passione e un atteggiamento positivo nei confronti del processo, in modo che i membri del team lavorino bene insieme. Diverse risorse Scrum menzionano il modello di sviluppo del gruppo di Bruce Tuckman come metodo efficace da seguire durante la costruzione di un team Scrum o l'aggiunta di nuove persone al team. L'articolo di Tuckman, "Developmental sequence in small groups", pubblicato nel Psychological Bulletin nel 1965, afferma che i nuovi team devono attraversare varie fasi prima di raggiungere un livello di prestazioni elevate e fornire risultati ottimali. Tuckman ha etichettato queste fasi come: "Forming", "Storming", "Norming" e "Performing".
Il nome di ogni fase all'interno del modello di sviluppo del gruppo di Tuckman riflette accuratamente le dinamiche del team durante quel particolare periodo.
Forming: Tuckman si riferisce a questa fase come quella incentrata sull'orientamento, il test e la dipendenza. I membri del team non hanno ancora familiarità tra loro e pensano ancora al loro lavoro come compiti individuali piuttosto che a uno sforzo collaborativo da parte di tutto il team nel suo insieme. Le sessioni di team building e i pranzi di gruppo spesso aiutano il team a sentirsi più a proprio agio.
Storming: nella fase di Storming, i membri del team generalmente seguono le proprie opinioni e resistono a vari aspetti del team che potrebbero influenzarli, motivo per cui spesso si verificano conflitti all'interno del gruppo. Nella fase di Storming, i membri del team sono incoraggiati ad accettare che ci saranno differenze all'interno del team, ma a capire anche che la diversità può comportare più idee e aumentare la produttività. Per passare alla fase successiva, i membri del team hanno bisogno di rassicurazioni sulle loro esigenze lavorative e sulle richieste di attività. Con l'instaurarsi della fiducia e della stabilità, sarà più facile risolvere i conflitti.
Norming: quando il team raggiunge la fase di Norming, i membri hanno stabilito aree di accordo e raggiunto un consenso. Sono state stabilite linee guida chiare sui ruoli individuali, con il risultato di una ritrovata apertura e coesione tra i membri. L'obiettivo in questa fase è quello di lavorare insieme per sviluppare standard di gruppo e discutere di idee e interpretazioni pertinenti.
Performing: all'interno della fase di Performing, il gruppo ha una visione unificata, un'energia collettiva e un senso di scopo. Il team ha imparato a lavorare bene insieme e a risolvere le questioni in modo positivo e diplomatico. Secondo Tuckman, i ruoli sono diventati flessibili e funzionali e la struttura del team può supportare un livello superiore di prestazioni.
Schnase ha raccomandato di tenere conto del modello di Tuckman quando le persone vengono aggiunte a un team Scrum perché un nuovo membro modifica le dinamiche del team. Ogni volta che il team cambia, secondo lei, passerà attraverso le fasi di Forming, Storming, Norming e Performing. "La velocità diminuirà quando aggiungi un nuovo membro del team, quindi dovresti tenerne conto."
Schnase ha anche sottolineato un altro motivo per cui è efficace condurre retrospettive Sprint. "Le retrospettive sono importanti perché il team deve riflettere sugli aspetti positivi e su quali elementi potrebbero potenzialmente migliorare. Aiutano inoltre il team ad arrivare alla fase di Performing."
Team building iniziale Scrum
Come la maggior parte dei modelli di sviluppo, ci vuole tempo per ottenere risultati; lo stesso vale per i team Scrum. Un nuovo team non genera immediatamente risultati superiori. Il tempo necessario prima che un team raggiunga la fase di esecuzione dipende dagli individui e da altri fattori, inclusa l'unità del team, motivo per cui il team building è indispensabile.
"Il team building iniziale è utile per stabilire la fiducia e per permettere a tutti i membri del team di riconoscere i punti di forza degli altri membri", afferma Schnase. "Ci vuole tempo per crescere come team."
La chiave del team building è trovare qualcosa che sia interessante e divertente per tutti e abbandonare gli imbarazzanti esercizi di team building a cui nessuno piace partecipare. Prepara un elenco di potenziali attività del team, chiedi ai membri quali preferirebbero intraprendere e chiedi ulteriori suggerimenti. Puoi prendere in considerazione un'escursione per rafforzare i legami al di fuori dell'ufficio, come una gita a un museo o una partita di una squadra locale, un'opportunità di volontariato di gruppo o un semplice pranzo collettivo per promuovere un forte ambiente di squadra. Inoltre, partecipare insieme a un workshop di formazione Scrum, in particolare uno che includa sessioni di breakout, ti aiuterà ad analizzare i punti di forza individuali che beneficeranno complessivamente il team.
Team Scrum remoti o co-localizzati
Il team building è difficile quando i membri del team si trovano in città diverse, per non parlare di paesi diversi. Schnase ha lavorato con membri di team Scrum da tutto il mondo. Sebbene alcuni esperti raccomandino di creare solo team co-localizzati perché spesso è più facile sviluppare coesione e fiducia lavorando insieme in un unico luogo, Schnase ha affermato che questo tipo di organizzazione non è sempre fattibile.
Le posizioni di Schnase presso IGT, ad esempio, comportano la collaborazione con i membri del team Scrum provenienti da Australia e Cina, nonché da varie città degli Stati Uniti. Afferma che, anche se le differenze di fuso orario possono essere impegnative, soprattutto per le riunioni di gruppo, è possibile far funzionare la situazione.
In queste situazioni, il processo di team-building potrebbe aver bisogno di svolgersi online utilizzando uno strumento di videoconferenza. Alcune aziende comprendono il vantaggio di riunire inizialmente i membri del team e pagheranno affinché il team si riunisca in un'unica posizione centrale per la formazione o per altri scopi di team building. Se questo è il caso del tuo datore di lavoro, potresti chiedere ai membri del team Scrum se appoggeranno l'idea di incontrarsi a una conferenza di formazione Scrum, ad esempio. Se tutti approvano, suggerisci l'opzione al tuo datore di lavoro.
Ruoli, responsabilità e tratti preferiti del team Scrum
I primi sviluppatori di Scrum prevedevano ruoli del team Scrum all'interno di una struttura autoorganizzata simile a quella che le squadre di rugby utilizzano quando passano una palla avanti e indietro e si spostano sul campo come un'unica unità coesa. La struttura del team Scrum è ora un modello collaudato che i team di sviluppo del prodotto devono seguire per ottenere risultati continui, coordinati e affidabili.
Un team Scrum ben bilanciato comprende:
- un product owner che promuove la visione del prodotto e assegna priorità al backlog di prodotto per massimizzare la funzionalità e il valore del prodotto per il cliente;
- uno Scrum Master che allena efficacemente il team di sviluppo, facilita gli eventi ed elimina le distrazioni che interferiscono con i progressi del team;
- e i membri del team di sviluppo che rimangono concentrati sul completamento dei deliverable in incrementi (funzionalità del prodotto completate alla fine di ogni sprint) e sulla creazione di un prodotto finale superiore.
Sutherland e Schwaber sottolineano che esistono ruoli Scrum specifici per un motivo e che la combinazione di questi ruoli spesso causa una diminuzione della produttività. I datori di lavoro devono inoltre riconoscere che i team sono molto più produttivi e stabili quando i loro membri si concentrano solo su un prodotto per sprint e non sono obbligati a lavorare su più prodotti o con altri team.
Nelle sezioni seguenti, esaminiamo le responsabilità e i tratti preferiti associati a ciascun ruolo per facilitare la valutazione dei candidati da parte dei responsabili delle assunzioni.
Ruolo di product owner
La Guida Scrum descrive il product owner come responsabile della "massimizzazione del valore del prodotto e del lavoro del team di sviluppo". In altre parole, il product owner è responsabile della fornitura di un prodotto di alta qualità che massimizza il ritorno sugli investimenti (ROI) dell'organizzazione. Le altre responsabilità principali sono relative alla comprensione e alla spiegazione delle aspettative del cliente per un prodotto, nonché alla gestione del backlog di prodotto, un elenco prioritario delle caratteristiche del prodotto stesso.
Schnase afferma che il product owner dovrebbe avere un tipo di personalità in grado di "fornire al team requisiti e obiettivi generali per il prodotto, ma che consentirà al team di determinare come raggiungere questi obiettivi".
I product owner hanno in genere esperienza nella gestione di prodotti o progetti, nel marketing o nella progettazione dell'esperienza utente (UX). Spesso hanno un background che coinvolge l'analisi delle aspettative dei clienti, dei prodotti competitivi, delle richieste del mercato e delle tendenze future per il tipo di prodotto in fase di sviluppo. Le credenziali accademiche variano a seconda del tipo di prodotto, business e settore. Ancora più importante, il product owner deve avere una visione e una connessione forti con il prodotto.
L'elenco seguente rappresenta le responsabilità che la descrizione del lavoro del product owner dovrebbe coprire per raggiungere il successo all'interno di questo ruolo.
- Sviluppa la visione del prodotto e sottolinea le aspettative del cliente: il product owner dovrebbe essere qualcuno in grado di valutare le informazioni da varie fonti, sviluppare una visione del prodotto e promuovere quella visione. Il product owner deve essere in grado di presentare messaggi chiave sul prodotto che risuoneranno con il team Scrum, gli stakeholder e altre persone in tutta l'organizzazione. È particolarmente importante per il product owner rappresentare il punto di vista del cliente quando spiega il prodotto e come le sue funzionalità nuove o migliorate supereranno le aspettative.
- Considera il lato aziendale dello sviluppo del prodotto: i product owner devono essere esperti di business, comprendere le esigenze aziendali che includono lo sviluppo del prodotto e riconoscere l'importanza dei tempi, delle condizioni positive del mercato e delle decisioni in base alle preoccupazioni di bilancio e al ROI. I product owner devono inoltre essere strategici nello sviluppo di piani di release del prodotto e nella promozione del prodotto a diversi livelli, sia che si tratti del mercato, del management superiore o del team Scrum.
- Motiva il team con obiettivi chiari e stimolanti: il product owner deve discutere i requisiti e gli obiettivi generali di ogni progetto con il team di sviluppo, rispondere a tutte le domande e lasciare che il team decida come soddisfare queste aspettative. Il product owner è responsabile della priorità del backlog di prodotto, ma sono i membri del team di sviluppo a decidere quanto lavoro completare durante ogni sprint e quanti sprint saranno necessari. Pertanto, il product owner deve avere un tipo di personalità che motiva i membri del team senza cercare di controllarli.
- Massimizza il valore del prodotto e i progressi del team di sviluppo: questa responsabilità completa sottolinea come sia essenziale per il product owner identificare correttamente quali caratteristiche del prodotto sono attualmente le più importanti e si trovano in cima all'elenco delle priorità per il prossimo sprint. Per farlo bene durante il processo di sviluppo del prodotto, il product owner deve continuamente perfezionare e ridefinire gli elementi di backlog di prodotto. Gli elementi di backlog di prodotto o, più specificamente, le caratteristiche e le user story del prodotto, devono avere priorità in base al valore che ciascuno porta al prodotto. Alcuni esperti fanno un ulteriore passo avanti e affermano che il valore è determinato dalla negoziazione del valore aziendale più alto per le voci di costo più basso; tuttavia, a volte è necessario soddisfare i clienti chiave e analizzare altri fattori della strategia aziendale.
- Assegna priorità e gestisce il backlog di prodotto: essendo l'unico responsabile del backlog di prodotto, il product owner esperto riconosce le dipendenze che devono essere considerate e valutate correttamente. I product owner più efficaci comprendono la necessità di essere selettivi quando qualcuno si avvicina a loro per richiedere una modifica o un'altra nuova funzionalità. Sanno di non poter dare la loro approvazione a tutto e di dover mantenere gli altri aspetti dello sviluppo del prodotto in linea con il valore aziendale e le aspettative realistiche. Sapere quando dire "no" è una parte importante del lavoro.
- Affina regolarmente il backlog di prodotto: per garantire che l'intero team comprenda ogni funzionalità elencata nel backlog di prodotto, il product owner chiarisce le descrizioni, spiega il loro livello di importanza e chiede al team se ha domande. Questi dettagli aiutano anche a garantire l'impegno del team per un prodotto di alta qualità che corrisponda alle aspettative del cliente. Alcuni product owner chiedono ai membri del team di sviluppo di aggiungere specifiche tecniche e altri dettagli simili al backlog di prodotto, ma il tempo che gli sviluppatori dedicano a queste attività deve essere ridotto al minimo.
- Presenta user story incentrate sulle funzionalità del prodotto: il team di sviluppo è responsabile del backlog dello sprint determinato durante la riunione di pianificazione dello sprint, ma il product owner è responsabile delle user story, che sono descrizioni delle funzionalità raccontate dal punto di vista dell'utente. Alcuni product owner creano la maggior parte delle user story da soli, altri coinvolgono l'intero team nel processo.
- Rimani in contatto con il team e continuamente disponibile: mostrare l'impegno a fornire il miglior prodotto possibile significa essere attivamente impegnati con il tuo team. I product owner sottolineano la propria disponibilità per il team e utilizzano le proprie capacità di comunicazione per sviluppare relazioni forti.
- Aumenta la conoscenza attraverso il networking: i product owner devono sapere perché è necessario rimanere in contatto con altri nel settore, partecipando periodicamente a conferenze e workshop. È un ottimo modo per acquisire conoscenze ascoltando ciò che gli altri hanno da dire sulle tecniche di modellazione aziendale, sulle lezioni apprese, sulle storie di successo dei prodotti e altro ancora.
Ruolo di Scrum Master
Lo Scrum Master è il principale responsabile di garantire che il team Scrum comprenda e segua le pratiche e le regole Scrum. Insieme a questa responsabilità, lo Scrum Master si assicura che gli altri all'interno dell'organizzazione rispettino la teoria Scrum abbastanza da limitare la quantità di distrazioni per il team Scrum e accettare il feedback su eventuali interazioni che interferiscono con i progressi del team.
In qualità di coach del team e facilitatore per progetti complessi, lo Scrum Master fornisce valore eliminando il maggior numero possibile di ostacoli per mantenere il team di sviluppo concentrato sui suoi obiettivi. Schnase ha affermato che gli Scrum Master dovrebbero aiutare il team rimuovendo gli ostacoli e gli impedimenti quando necessario. "Se qualcuno non riesce a entrare in una cartella di rete di cui ha bisogno o se l'ambiente di test non è disponibile, lo Scrum Master può aiutare a risolvere questi problemi", afferma Schnase. "Gli Scrum Master devono essere in grado di comunicare con qualsiasi stakeholder, oltre a essere assertivi ed entusiasti."
Gli Scrum Master provengono da una varietà di background e discipline accademiche, tra cui design, ingegneria, IT, marketing, gestione di prodotti o progetti, garanzia di qualità e test. Hanno qualità come l'umiltà, la perseveranza e la lealtà, insieme a un'ampia base di conoscenze e forti capacità di leadership che consentono loro di essere facilitatori e negoziatori eccellenti che sanno risolvere i conflitti. Anche gli Scrum Master devono rimanere impegnati in Scrum indipendentemente dalla pressione che ricevono da altre fonti.
Per avere sempre prestazioni elevate, Gli Scrum Master devono affrontare molteplici responsabilità e possedere diverse caratteristiche personali, come dimostrato dall'elenco dettagliato di seguito.
- Assolve il ruolo di "leader a disposizione": un vero leader a disposizione sa che deve assicurarsi che il team abbia ciò di cui ha bisogno per fornire risultati al cliente in modo da soddisfare gli obiettivi aziendali. A questo proposito, lo Scrum Master serve diverse entità contemporaneamente: i membri del team, il cliente e l'azienda. Secondo la Guida Scrum, il ruolo dello Scrum Master comporta responsabilità specifiche al servizio del product owner, del team di sviluppo e dell'organizzazione. Lo Scrum Master dà l'esempio ed è il tipo di persona che gli altri membri del team vogliono seguire. Uno Scrum Master stimolante incoraggia gli altri a credere nelle proprie capacità e a lavorare al proprio potenziale, anche quando le cose non vanno come previsto.
- Accetta responsabilità senza sentirsi in diritto di autorità: nel suo post sul blog intitolato "Leader of the Band", Cohn spiega l'aspettativa di responsabilità senza potere: "Mentre uno Scrum Master non si assume la responsabilità del successo del progetto, che rimane del team, si assume la responsabilità dell'adozione e della pratica di Scrum da parte del team. Uno Scrum Master si assume questa responsabilità senza assumere alcuno dei poteri che potrebbero essere utili per raggiungerla."
In un altro post, "Advice for Interviewing Scrum Masters", Cohn ha chiarito le aspettative dichiarando: "Un direttore d'orchestra una volta ha spiegato che non ha alcun potere reale sul modo in cui i singoli musicisti suonano. Eppure sente un'enorme responsabilità nell'aiutarli a essere i migliori musicisti che possano essere."
- Risolve gli ostacoli e, se possibile, li previene: lo Scrum Master protegge il lavoro del team di sviluppo risolvendo o rimuovendo gli ostacoli quando possibile. Spesso i membri del team parlano allo Scrum Master di un impedimento durante lo scrum quotidiano e spiegano perché potrebbe interferire con la loro capacità di completare il lavoro durante uno sprint.
Nei recenti elenchi di lavoro, i responsabili delle assunzioni hanno mostrato una preferenza per Scrum Master che hanno un'ampia conoscenza tecnica e/o comprendono pienamente i dettagli di un particolare settore. Gli Scrum Master con questo tipo di conoscenze hanno il vantaggio di essere in grado di aiutare i propri team ad affrontare più rapidamente gli ostacoli che comportano problemi tecnici.
Alcuni ostacoli nascosti sotto la superficie sono minacce per l'efficacia complessiva del team, motivo per cui l'impiego di uno Scrum Master osservatore e impegnato in grado di eliminare tali minacce è altamente auspicabile. Più è esperto uno Scrum Master, più sarà facile per lui riconoscere un potenziale problema e risolverlo prima che diventi serio.
- Istruisce il team su come migliorare: gli Scrum Master istruiscono i propri team fornendo esempi in base alle loro conoscenze ed esperienze e guidandoli a sfruttare al meglio il loro potenziale. In questo modo, aiutano i membri del team a comprendere meglio se stessi e a implementare pratiche che implicano l'auto-organizzazione e l'interfunzionalità. Quando gli Scrum Master incoraggiano a sfruttare l'auto-organizzazione, i team aumentano la proprietà del proprio lavoro, trovano più facile prendere decisioni e stime di lavoro e sentono di poter raggiungere uno scopo comune insieme.
Cohn confronta il coaching Scrum Master con il tipo di assistenza che i personal trainer forniscono. "Pensa all'aiuto di uno Scrum Master come a quello di un personal trainer che ti aiuta a rispettare un regime di esercizio ed eseguire tutti gli esercizi con la forma corretta. Un buon allenatore fornirà motivazione e allo stesso tempo si assicurerà che non bari saltando un duro esercizio. L'autorità dell'allenatore, tuttavia, è limitata. L'allenatore non può costringerti a fare un esercizio che non vuoi fare. Invece, ti ricorderà i tuoi obiettivi e come hai scelto di raggiungerli."
- Riconosce e risolve i conflitti il prima possibile: tutti i membri di un team Scrum hanno la libertà di affrontare atteggiamenti improduttivi e comportamenti disfunzionali, ma a volte il conflitto nasce da incomprensioni o dalla necessità di compromessi. In questi casi, gli Scrum Master devono riconoscere il conflitto di squadra abbastanza presto per risolverlo prima che sia necessario un eccessivo controllo dei danni. Gli Scrum Master sanno anche che un conflitto è inevitabile e non sempre una cosa negativa. La capacità di superare i conflitti renderà il team più forte.
Nel suo post sul blog intitolato "Advice for Interviewing Scrum Masters", Cohn discute di come la mentalità collaborativa che gli Scrum Masters apportano al lavoro aiuti a risolvere i conflitti. "Un buon Scrum Master lavora per garantire una cultura collaborativa all'interno del team. Lo Scrum Master deve assicurarsi che i membri del team si sentano in grado di sollevare problemi da discutere in modo aperto. Quando sorgono controversie, gli Scrum Master collaborativi incoraggiano i team a pensare in termini di soluzioni che avvantaggino tutti i soggetti coinvolti piuttosto che in termini di vincitori e perdenti."
- Facilita gli eventi Scrum : i migliori Scrum Master sembrano istintivamente sapere come facilitare gli eventi e guidare le persone. In realtà, la maggior parte degli Scrum Master riceve questo tipo di formazione da corsi di leadership e/o anni di esperienza. Le persone che partecipano ai loro eventi Scrum apprezzano la loro preparazione e la capacità di stabilire aspettative chiare.
- Ascolta e osserva: anche in questo caso, l'equilibrio è fondamentale. Gli Scrum Master efficaci hanno capacità di comunicazione eccezionali, ma sanno anche quando semplicemente ascoltare e osservare. Per ascolto, si intende un ascolto mirato e attivo. Per osservazione, ci riferiamo all'osservazione di ciò che non viene comunicato ad alta voce, ma è comunque evidente osservando da vicino il linguaggio del corpo, le espressioni facciali e altri segnali.
- Agisce come educatore e promotore di Scrum: gli Scrum Master non solo assicurano che i membri del team Scrum comprendano e seguano Scrum, ma si assicurano anche che gli altri dipendenti che sono collegati ai loro team comprendano Scrum a loro volta. Se le organizzazioni stanno adottando Scrum per la prima volta, sono gli Scrum Master a guidare questo sforzo pianificando l'implementazione di Scrum, suggerendo modifiche per aumentare la produttività del team Scrum e fornendo assistenza durante un periodo di aggiustamento. Nelle grandi aziende, questo sforzo a volte comporta la collaborazione con altri Scrum Master per aumentare l'efficacia di Scrum.
Mentre insegnano il metodo Scrum agli altri, gli Scrum Master potrebbero dover superare lo scetticismo di alcune persone, promuovendo il valore di Scrum e il modo in cui il suo quadro e i principi guida hanno già generato risultati significativi per altre aziende.
- Utilizza le competenze politiche aziendali per influenzare le persone in tutta l'organizzazione: gli Scrum Master esperti sanno che potrebbero essere in grado di cambiare il comportamento delle persone dando loro un motivo per mutare le loro azioni o influenzare le persone modificando la cultura e le condizioni in cui devono operare, ma che non possono effettivamente cambiare le persone in sé. Questi Scrum Master sanno anche come utilizzare la persuasione e la motivazione per influenzare le altre persone a vari livelli in un'organizzazione, perché capiscono chi prende le grandi decisioni, come capitalizzare le alleanze esistenti e come girare intorno alle persone che più probabilmente rappresenteranno un ostacolo.
Ruoli del team di sviluppo
Le persone che creano il prodotto sono note collettivamente come team di sviluppo. Questo gruppo comprende in genere professionisti che hanno esperienza e formazione come sviluppatori di software, progettisti di interfacce utente, specialisti di database, ingegneri operativi, ingegneri di garanzia della qualità, tester, analisti di sistemi e scrittori tecnici (specialisti della documentazione). Secondo la Guida Scrum, "Scrum non riconosce titoli per i membri del team di sviluppo diversi dallo sviluppatore, indipendentemente dal lavoro svolto dalla persona; non ci sono eccezioni a questa regola."
La funzione principale del team di sviluppo è eseguire il lavoro necessario per una serie di sprint e incrementi di prodotto di successo, seguiti dalla consegna di un prodotto finale di alta qualità. Se hai intenzione di assumere qualcuno per il tuo team di sviluppo Scrum, Schnase suggerisce di cercare un professionista disposto a fornire assistenza per i test ed eseguire altre funzioni come l'automazione. "Ogni membro del team dovrebbe essere disposto a formarsi e ad aiutarsi a vicenda."
"The Basics of Scrum", pubblicato da Scrum Inc., affronta anche l'importanza di avere un team di sviluppo interfunzionale. "Inoltre, ci dovrebbero essere almeno due persone nel team che possano completare qualsiasi elemento nel backlog di prodotto. Ciò aiuta a eliminare le dipendenze dalle competenze di un membro del team specifico nel caso in cui il collega si ammali, vada in ferie o passi a un altro lavoro."
L'elenco seguente include le responsabilità condivise dal team di sviluppo, insieme ai tratti desiderabili dei migliori membri potenziali.
- Offre il livello di funzionalità e qualità promesso: i dipendenti più adatti al lavoro di Scrum sono collaboratori e comunicatori che migliorano costantemente quanto più a lungo rimangono con un team e sono in grado di implementare le funzionalità come pianificato e di fornire lavoro di alta qualità. Attraverso le loro azioni, dimostrano un forte impegno per gli obiettivi e la capacità di prosperare in un ambiente Scrum.
- Si preoccupa veramente di rilasciare un prodotto finale che i clienti apprezzeranno: i membri del team più apprezzati sono quelli che conoscono bene i loro clienti e sarebbero loro stessi delusi se non si impegnassero a superare le aspettative del cliente. Questi dipendenti sono orgogliosi del loro lavoro e sono entusiasti di ricevere feedback positivi dai clienti.
- Aiuta il team a concentrarsi sul completamento: i team di sviluppo sono responsabili di tutte le attività nel backlog dello sprint. I team ad alte prestazioni copiano queste attività in una bacheca Scrum ed effettuano frequentemente aggiornamenti per garantire che tutti abbiano un riferimento visivo su dove qualsiasi attività si trova in tempo reale. Le colonne della bacheca Scrum devono indicare chiaramente quali attività sono state completate e quanti progressi sono stati fatti sugli elementi rimanenti. I membri del team che seguono queste linee guida elimineranno la confusione e manterranno il team concentrato sull'avanzamento.
- Utilizza ogni giorno Scrum e altre riunioni come strumenti di comunicazione: i membri del team coscienziosi sanno che il loro tempo è prezioso e limitato e trattano il tempo dei loro colleghi con lo stesso rispetto. Utilizzano le riunioni giornaliere Scrum e altre riunioni in base alle linee guida e sono preparati a comunicare entro il tempo consentito. Mantengono anche le altre comunicazioni con i colleghi concise e puntuali.
- Prende impegni realistici: i time manager efficaci si rendono conto che una certa quantità di downtime fa necessariamente parte della giornata di tutti. Tutti abbiamo bisogno di tempo per rilassarci e ricaricarci, soprattutto se vogliamo promuovere la creatività. Una certa quantità di rallentamento nei nostri programmi è necessaria per questi scopi e per pianificare adeguatamente situazioni impreviste ed emergenze. Gli sviluppatori esperti lo sanno e stimano di conseguenza le scadenze per gli impegni.
- Fornisce idee per sprint futuri: tutti apprezzano un membro del team che prende l'iniziativa fornendo opzioni funzionali per gli elementi non affrontati che nota nel backlog di prodotto. Sebbene il backlog di prodotto faccia parte dell'elenco delle responsabilità del product owner, offrire idee su come perfezionarne i contenuti è qualcosa che l'intero team può fare. Migliorare gli elementi del backlog di prodotto migliora a sua volta e inevitabilmente gli incrementi del prodotto e il prodotto finale.
- Offre opportunità di formazione trasversale e di apprendimento continuo: i membri del team orientati alla crescita sono entusiasti delle opportunità di apprendimento avanzate perché comprendono l'importanza dell'innovazione e si adattano continuamente a un ambiente tecnico in rapida evoluzione. Sono aperti al cambiamento e disposti a formarsi e a impegnarsi in situazioni collaborative. Sono inoltre disposti a condividere le loro esperienze con altri dipendenti e a fungere da mentori per i nuovi membri del team.
- Combina l'esperienza tecnica con le conoscenze aziendali: i membri del team di sviluppo che comprendono i concetti aziendali quasi quanto la tecnologia sono preziosi su diversi fronti. Non solo possono spiegare la tecnologia al personale aziendale, ma possono anche informarlo sulle conseguenze della release di un prodotto che si concentra troppo sul marketing piuttosto che sui fattori tecnici sottostanti.
Ad esempio, quando l'aggiunta di troppe funzionalità pesa sulle prestazioni complessive del prodotto, questi sviluppatori informeranno il product owner delle proprie preoccupazioni il prima possibile. Questi sviluppatori sono risorse preziose perché possono spiegare le loro preoccupazioni in termini aziendali che il product owner comprenderà, indicano di essere disposti a lavorare su possibili soluzioni e mostrano di comprendere come aspetti tecnici quali le prestazioni possono influire sul valore di mercato di un prodotto.
- Impone una politica di non interferenza per il team: gli altri membri di un'azienda possono essere tentati di spingere le proprie richieste a un team di sviluppo, motivo per cui la Guida Scrum ha ritenuto necessario includere un'istruzione per affrontare questa tendenza: "A nessuno è permesso di dire al team di sviluppo di lavorare a partire da una diversa serie di requisiti, e al team di sviluppo non è permesso di agire in base a ciò che dice qualcun altro."
Suggerimenti generali per l'assunzione di tutti i ruoli del team Scrum
Ora che abbiamo trattato le specifiche, esaminiamo un elenco generale delle qualità che gli esperti Scrum dicono di cercare nei membri del team.
- Ammette gli errori e impara da questi ultimi: sebbene tutti commettano errori, è importante che i dipendenti imparino da questi errori e migliorino di conseguenza. Prima di assumere o invitare qualcuno a unirsi al tuo team Scrum, impara a riconoscere quali candidati non ammettono di aver commesso errori: questo potrebbe essere un indicatore di tratti più preoccupanti, come una mancanza di responsabilità. I team lavorano insieme su innumerevoli dettagli, quindi è fondamentale aggiungere un candidato che possa passare senza intoppi a un ruolo di squadra senza mostrare la tendenza a incolpare altri.
- Dà valore al feedback: i membri del team consapevoli sanno come dare e ricevere feedback in modo chiaro, diretto e rispettoso. Sanno anche che il feedback dovrebbe essere utile ed edificante. Quando possibile, questi membri del team cercano il modo di fornire il loro feedback in privato. Anche la fiducia è una parte importante dell'equazione. I compagni di squadra che si fidano l'uno dell'altro lavorano meglio insieme. Valutare correttamente il modo in cui i candidati percepiscono il feedback e la fiducia rivela molto sul loro carattere.
- Porta umorismo, energia e divertimento: entrare a far parte di un team e sentirsi connessi agli altri richiede un investimento personale da parte di tutti. I dipendenti che mostrano la loro personalità attraverso l'umorismo, l'energia e le attività divertenti spesso si connettono con gli altri più rapidamente. Non è sempre facile valutare queste qualità durante i colloqui di lavoro, ma porre domande generali sugli interessi e gli hobby preferiti, sui viaggi e sulle attività del fine settimana può rivelare alcuni indizi su come il candidato si inserirebbe in un particolare team Scrum.
Strumenti Scrum
La proprietà collettiva è una parte importante di Scrum. Per migliorare come team, è importante monitorare le prestazioni e i progressi utilizzando una varietà di strumenti.
- Bacheca Scrum: esistono vari tipi di schede di attività, ma il modello più comune utilizzato in Scrum è la bacheca Scrum menzionata in precedenza in questo articolo. Come abbiamo descritto, la bacheca Scrum include colonne generalmente etichettate come Da fare, Lavoro in corso e Fatto. Ciascuna delle attività del backlog dello sprint è scritta su note adesive inserite all'interno di una di queste colonne per aiutare il team Scrum a determinare quanto lavoro deve ancora essere completato prima della fine dello sprint.
Le schede Scrum possono anche essere utilizzate per monitorare l'output del team con una metrica nota come velocità. Per misurare la velocità, il team assegna un valore di punto relativo a ogni attività dal backlog dello sprint. Al termine dello sprint, il team può aggiungere punti nella colonna Fatto e calcolare la velocità totale del team per quel particolare sprint. L'utilizzo di questo metodo aiuta i team a creare una base per le prestazioni e a prevedere quanto lavoro sarà possibile gestire negli sprint futuri.
I team possono anche utilizzare schede Scrum e velocità per prevedere la data di completamento di un progetto o analizzare se una modifica del flusso di lavoro ha effettivamente aiutato il team a migliorare il proprio tasso di prestazioni. Per ulteriori informazioni, consulta i corsi della Bacheca Scrum presso Scrum Inc.
- Diagramma di burndown: nel completamento di uno sprint, i team potrebbero voler utilizzare un diagramma di burndown giornaliero dello sprint per mostrare la quantità rimanente di lavoro rimanente nel backlog dello sprint. Il lavoro rimanente viene tracciato sull'asse verticale e il tempo (in base ai giorni all'interno di uno sprint) viene tracciato sull'asse orizzontale. Questo tipo di rappresentazione visiva può aiutare i team a misurare i progressi e a assicurarsi che siano sulla buona strada per la data di completamento prevista. I diagrammi di burndown possono anche essere utili per monitorare le tendenze e il lavoro durante la sequenza temporale di release di un prodotto. Per ulteriori informazioni sulla creazione di un diagramma di burndown, consulta i corsi del diagramma burndown Sprint presso Scrum Inc.
- Matrice RACI: come ogni team sa, ci sono volte in cui è necessaria la responsabilità individuale. In questi casi, è utile disporre di uno strumento come la matrice RACI (acronimo inglese per Responsible, Accountable, Consulted, Informed) per suddividere i compiti e i deliverable in un diagramma di ruoli e responsabilità organizzati. Per ulteriori dettagli su questo strumento, vedere "A Comprehensive Project Management Guide for Everything RACI."
Utilizza Smartsheet per gestire facilmente i progetti Scrum
Dalla semplice gestione delle attività e pianificazione dei progetti, alla complessa gestione delle risorse e del portfolio, Smartsheet ti aiuta a migliorare la collaborazione e ad aumentare la velocità del lavoro, consentendoti di ottenere di più. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.