Una panoramica sulle ceremonies in Scrum
Le ceremonies in Scrum sono i momenti chiave in cui il team coordina il proprio lavoro, e non solo per quanto riguarda lo sprint corrente. Funzionando come un framework per lo sviluppo agile di software, le cerimonie di scrum aiutano i team a lavorare su prodotti in continuo miglioramento. Proprio attraverso gli Sprint, le Ceremonies riescono ad assicurare quel tipo di continuità.
Che cos’è Scrum?
Scrum è un framework all’interno del quale gli individui possono inquadrare e affrontare problematiche complesse, mentre realizzano prodotti del più alto valore possibile.
Scrum stesso si basa su una struttura semplice, per garantire una collaborazione efficace al team mentre è al lavoro su prodotti complessi.
Scrum Ceremonies e Framework Scrum
La metodologia Scrum implementa al suo interno il metodo scientifico dell’empirismo. Scrum sostituisce un approccio algoritmico programmato con un approccio euristico, nel rispetto delle persone e dei principi di auto-organizzazione, per affrontare l’imprevedibilità e risolvere problemi complessi. Il grafico qui sotto dà un’idea di Scrum in azione.
Le Quattro Scrum Ceremonies
Scrum viene eseguito attraverso momenti chiamati sprint, brevi percorsi di lavoro che durano di solito non più di due settimane. Per assicurare la corretta esecuzione di uno sprint si impiegano quattro diverse cerimonie in scrum:
- pianificazione dello sprint
- scrum quotidiano
- revisione dello sprint
- retrospettiva dello sprint
Queste cerimonie in scrum sono descritte di seguito.
Pianificazione dello sprint
In questo tipo di scrum ceremonies, la pianificazione dello sprint è il momento in cui il team si incontra e decide cosa dovrà essere completato nello sprint successivo.
Scrum quotidiano
Quando quotidianamente si fanno cerimonie in scrum, lo scrum quotidiano è una riunione di stand up, o una mini riunione molto breve – 15 minuti – che serve al team per assicurarsi che tutti siano ‘sulla stessa pagina’.
Revisione dello sprint
Le scrum ceremonies in modalità sprint review rappresentano un altro tipo di riunione. Nella revisione dello sprint ciascun membro del team riporta ciò che ha fatto nello sprint.
Sprint Retrospective
Se parliamo di sprint retrospective e cerimonie di scrum, allora questo è il momento di tirare le fila. Il team rivede il proprio lavoro, identificando cosa è stato fatto bene e cosa non è andato come previsto, così da poter migliorare lo sprint successivo.
Scrum Ceremonies & Sprint Planning
Cerimonia iniziale: la Pianificazione
Partecipanti: team di sviluppo, scrum master, product owner
Quando: all’inizio di uno sprint
Durata: di solito un’ora per ogni settimana di iterazione-es. uno sprint di due settimane inizia con una riunione di pianificazione di due ore.
Quadro Agile: Scrum (naturalmente anche i team Kanban pianificano, ma non si basano su un programma fisso di iterazione con una pianificazione formale dello sprint).
La cerimonia iniziale Scrum aiuta a mettere le basi per l’intera squadra e la prepara allo sprint successivo, creando un percorso regolare verso uno sprint di successo. La pianificazione dello sprint richiede la partecipazione di tutti i ruoli scrum con responsabilità diretta verso il prodotto: il team di sviluppo, lo scrum master e il product owner. La pianificazione, naturalmente, è precedente allo sprint. Di solito dura un’ora o due.
Sprint backlog e user story
Il product owner si presenta alla riunione con una lista di priorità ricavate dagli elementi del product backlog e le presenta al team. Gli elementi della lista, che vengono anche chiamati user stories, sono poi discussi con il team di sviluppo. Insieme, si realizza una prima stima del tempo che servirà per completare tutti gli elementi compresi nella lista. Da queste informazioni, il team di sviluppo fa una previsione di sprint. Gli sviluppatori delineano quante ore-lavoro saranno necessarie al team per completare la lista delle richieste del product backlog. Vi si farà riferimento come sprint di backlog.
Alcune cerimonie per la pianificazione dello sprint andranno ad approfondire i dettagli provenienti dalla user story, la storia utente. In questo modo tutte le persone coinvolte potranno capire lo scopo del loro lavoro. Tuttavia, ci sarà anche il caso di alcuni membri del team che avranno una riunione o una cerimonia di rifinitura della user story separata. Facendo questo, la cerimonia di pianificazione dello sprint resta breve e diretta solo verso le user stories di interesse collettivo, che saranno ri-affrontate nello sprint successivo.
Cerimonie Quotidiane: Daily Scrum
Partecipanti: team di sviluppo, scrum master, product owner
Quando: una volta al giorno, tipicamente la mattina.
Durata: Non più di 15 minuti. Non prenotate una sala conferenze per fare lo stand up da seduti. Stare in piedi aiuta a mantenere la durata della riunione breve!
Agile Framework: Scrum e Kanban
Si tratta di una breve cerimonia scrum che assicura che tutti sappiano cosa sta succedendo. È un modo per garantire la trasparenza all’interno del team. L’inizio non è momento in cui aver paura o andare in confusione. Ecco perché c’è bisogno di una riunione informativa leggera e divertente, senza mettere nessuno al muro.
Il daily scrum è uno spazio che ogni membro del team si prende per rispondere alle seguenti domande:
- cosa hai completato ieri?
- su cosa stai lavorando oggi?
- sei bloccato su qualcosa?
Il daily scrum è, come dice, un evento quotidiano, che di solito si svolge ogni mattina con il team di sviluppo, lo scrum master e il product owner. È breve, circa 15 minuti, ed è per questo che viene anche chiamato standup meeting. Farlo in piedi fa sì che non si trascini troppo nel tempo.
Per funzionare lo scrum quotidiano richiede una buona dose di responsabilità individuale. Ciascuno riferisce onestamente rispetto a ciò che ha fatto, quello che ha intenzione di fare e come potrebbe rimanere bloccato nel processo. Tutto ciò avviene di fronte agli altri. Dover riferire in un tale contesto sociale prepara il team al successo, perché sarebbe imbarazzante per il singolo non poter mostrare progressi davanti agli altri. Lo scrum quotidiano non è limitato ai team che condividono un luogo fisico. Se i team lavorano in remoto, la cerimonia può essere condotta con una videoconferenza o una chat di gruppo.
Revisione dello sprint
Partecipanti: team di sviluppo, scrum master, product owner
Opzionale: stakeholder del progetto
Quando: alla fine di uno sprint o di una milestone
Durata: 30-60 minuti
Quadro agile: Scrum e kanban.
Come per la pianificazione, la revisione per i team kanban dovrebbe allinearsi con le milestone del team piuttosto che essere impostata su una cadenza fissa.
Una volta che lo sprint è giunto al termine, arriva il momento di riunire la squadra al completo per fare una demo e mostrare il lavoro all’interno del team. Ogni membro del team esamina le nuove caratteristiche sviluppate e qualsiasi dettaglio su cui si è lavorato durante lo sprint. In questo modo i membri del team si congratulano tra di loro per il successo nello sprint – aspetto molto importante per il morale. Vedere il lavoro finito è essenziale per l’intero team, agile mentor e stakeholder compresi. In modo che possa fornire un contributo di ritorno e si possano ottenere feedback dagli stakeholder del progetto.
A differenza di altre ceremonies, qui la revisione può richiedere tutto il tempo necessario per dimostrare per intero il lavoro fatto dal team. Di nuovo, i partecipanti sono: il team di sviluppo, lo scrum master e il product owner, ma anche altri team coinvolti nel progetto e gli stakeholder.
Queste demo non sono revisioni parziali, ma revisioni complete del lavoro. Se non è così, allora il peso specifico della sprint review viene sminuito. Le revisioni devono soddisfare il livello di qualità stabilito dal team o non possono altrimenti essere considerate complete (e in quel caso non dovrebbero essere nemmeno mostrate nella sprint review).
Scrum Retrospectives
Partecipanti: team di sviluppo, scrum master, product owner
Quando: Alla fine di un’iterazione
Durata: 60 minuti
Quadro agile: Scrum e Kanban.
I team delle cerimonie Scrum fanno scrum retrospectives a cadenza fissa. Anche i team Kanban possono beneficiare di retrospettive occasionali.
L’ultima delle quattro scrum ceremonies è chiamata sprint retrospective. Si verifica alla fine di uno sprint, dopo la revisione, e di solito dura un’ora. La retrospettiva include il team di sviluppo, lo scrum master e il product owner.
Poiché le scrum ceremonies fanno parte di un processo e di un metodo agile, è tutta una questione di reazione al cambiamento. Ciò naturalmente include ottenere subito un feedback e poter agire rapidamente su di esso. Le scrum ceremonies sono finalizzate al miglioramento continuo e la retrospective è un metodo per assicurarsi che il prodotto e la cultura di sviluppo siano in costante miglioramento.
La retrospettiva è un modo per il team di capire cosa ha funzionato bene e cosa non ha funzionato nello sprint precedente. Il post-mortem espone le linee di faglia, di rottura all’interno del team e del suo processo, in modo da poter lavorare per rinforzare i punti deboli e avvicinarsi al prossimo sprint con maggiore forza.
All’interno di questa sessione il discorso può andare anche al di fuori dei confini della riunione. La sprint retrospective è un’occasione per confrontarsi che porta all’azione. I membri del team non si devono limitare a lamentarsi o criticare – ma far sì tutti lavorino insieme per risolvere i problemi emersi.
La sprint retrospective non è un momento in cui addossare colpe, ma un mezzo per identificare e correggere i problemi che sono emersi nel corso dello sprint. Ed anche uno strumento per congratularsi con il team per un lavoro ben fatto, in caso non ci siano stati problemi. Ma, se il mantra dello scrum è quello di cercare sempre di migliorare, allora anche la retrospettiva deve essere critica, ma solo in quanto trampolino di lancio verso nuovi miglioramenti. ‘Critica costruttiva’ è la parolina magica in questa fase.
Scrum Ceremonies e Lavoro Remoto
È arrivato il momento di parlare delle cerimonie di scrum nel lavoro a distanza.
Il lavoro remoto è qualcosa che va alla grande negli ultimi tempi, e ciò è fantastico!
Ma, come è stato ampiamente commentato nella comunità agile, quest’orizzonte pone di fronte a noi alcune sfide specifiche quando si implementano le scrum ceremonies o altri approcci agili.
Scrum e le cerimonie scrum non menzionano affatto la co-locazione. Uno dei principi del Manifesto Agile afferma che il metodo più efficiente ed efficace per trasmettere informazioni verso un team e all’interno di un team di sviluppo è la conversazione faccia a faccia. Come promotore del lavoro remoto non sono in disaccordo. La conversazione faccia a faccia è la metodologia più efficiente ed efficace. Ma non è l’unica opzione, e spesso le nostre opzioni remote sono le migliori in un dato contesto.
Molte delle tecniche comuni del metodo agile non possono essere copiate e trasferite dal F2F agli ambienti remoti. Per questa ragione l’organizzazione agile in un ambiente remoto può essere più difficile da ricreare e mantenere.
L’ambiente remoto può far bene a team agili maturi, mentre può far incasinare team meno maturi e consapevoli. Le sfide sono reali, e dopo averle superate il lavoro remoto in modalità agile può risultare ancora più potente rispetto a una configurazione collocata – quando si minimizzano gli aspetti negativi e si sfruttano al massimo i vantaggi.
Costruire un team agile in un ambiente remoto
Il processo/quadro è sempre profondamente legato al Manifesto Agile e ai suoi principi e di solito è fortemente ispirato alla Guida Scrum. Costruire un team agile in un ambiente remoto è una combinazione di due grandi sfide – essere agile e costruire un team. Di seguito vorrei concentrarmi sulle sfide che sono particolarmente comuni quando si combinano questi due aspetti.
I due consigli più importanti
- Mettete da parte un po’ di tempo per controllare la consistenza della comunicazione e il livello della trasparenza, specialmente quando il vostro team è all’inizio del viaggio. In un ambiente remoto è più facile non vedere alcune bandierine rosse di alert.
- Provate a tradurre esercizi e attività in ambiente remoto.
Volete usare una tecnica che conoscete riferita alle riunioni faccia a faccia?
Spesso questa operazione è possibile – vi basterà pensare a come vengono utilizzati elementi dell’ambiente fisico in quella specifica tecnica, a come potete riportarli online online. Esistono lavagne online, documenti condivisi come Google docs, e videochiamate di gruppo (es. puoi dividere una chiamata di 12 persone in quattro chiamate da 3 persone per lavorare in gruppo).
Sfide comuni nella gestione di team remoti
È estremamente facile scivolare nel caos quando si tratta di progetti software. Così tante opzioni nello spazio virtuale, tutte quelle decisioni che non sono ancora state prese, e tutti i cambiamenti che sicuramente arriveranno ad impattare sullo sviluppo.
Come affrontare tutto ciò? La risposta è: struttura flessibile.
Il Framework Scrum
Un buon esempio di questa struttura flessibile è il Framework Scrum. Lo scrum framework stabilisce alcuni must-have e lascia lo spazio per essere riempito con contenuti adatti al prodotto. Nominare esplicitamente ciascuna delle regole, così come le varie fasi del flusso del team è la chiave nel metodo agile, così come il principio kanban – la visualizzazione del flusso di lavoro.
Costruire la fiducia
I primi passi possono essere difficili, ma quando ci si concentra sulla promozione dell’autosufficienza e sul mantenimento della trasparenza si hanno tutte le basi necessarie. Costruire la fiducia è cruciale per una collaborazione efficace.
Concentratevi sulla costruzione della fiducia sia all’interno del team tecnico che tra il team tecnico e il cliente. L’intero team aziendale deve essere formato lato cliente. Abbiamo bisogno di trasparenza tra lo sviluppo e il business, per essere sicuri che stiamo costruendo la cosa giusta. E abbiamo bisogno di apertura all’interno del team per essere sicuri di sviluppare nel modo giusto.
Autosufficienza e autoregolamentazione
Il lavoro remoto richiede maturità. Ogni membro del team deve essere in grado di assumersi le responsabilità relative al proprio ambiente di lavoro e prendere coscienza dell’auto-organizzazione nell’ambito del proprio lavoro. Proprio come nel lavoro agile. Essere un membro di un team che si auto-organizza richiede prima di tutto di prendere possesso del proprio lavoro, in ogni dimensione, fino a espandere la dimensione del proprio ambiente a tutto il team. La fiducia, l’autosufficienza dei membri del team e l’auto-organizzazione del team sono interconnessi.
Devi costruire su tutte queste qualità in modo incrementale – più fiducia significa più spazio per l’autosufficienza. L’autosufficienza e l’autoregolazione del team sono argomenti importanti sia nel lavoro remoto che in quello agile. Quando si sviluppa con metodo agile in un ambiente remoto questa sfida è ancora più importante, perché sia il costo del fallimento che la ricompensa del successo sono raddoppiati.
Il ruolo del project manager nella gestione dei team remoti
Ogni nuovo team ha bisogno di trovare il suo framework, per evitare il caos. Il primo compito del project manager quando si inizia un nuovo progetto è quello di aiutare a trovare quel framework, quella prima struttura di base. Poi arriverà tempo di concentrarsi sulla costruzione della fiducia e sulla trasparenza. Solo così ci assicureremo di poter costruire una vera squadra, unita intorno ad un obiettivo comune. Che è qualcosa di diverso da avere un gruppo di grandi specialisti, ognuno concentrato sul proprio ‘progettino’.
Quando la squadra lavora all’interno di questa prima cornice, è tempo di affrontare la prossima sfida. Durante questo processo la squadra comincia ad appropriarsi della cornice che le è stata data e la adatta ai suoi bisogni specifici. Passo dopo passo si creano nuove regole di gruppo, ciascuno influenza il comportamento dell’altro e impara dagli altri. Il lavoro di un Project Manager, o di uno Scrum Master, implica il fatto di trovarsi lì con loro a sporcarsi le mani – aiutarli nella transizione e nell’adattamento ai cambiamenti che incontrano.
Suggerimenti per un ambiente di lavoro remoto
L’agile management in un ambiente remoto è sicuramente possibile, ma può risultare impegnativa. Dovrete concentrarvi allo stesso modo sulle sfide relative alla costruzione del team e su quelle relative all’organizzazione del lavoro a distanza.
Ricordatevi di:
Dare un nome ai vostri valori
Dovete prima capire quali sono i vostri valori, per essere sicuri di poterli poi condividere con tutto il team. I cinque valori di Scrum sono un buon punto di partenza per gestire i valori del team a distanza: Coraggio, Concentrazione, Impegno, Apertura e Rispetto.
Incontrare la squadra ogni giorno
Assicuratevi di coprire non solo gli argomenti tecnici. Se volete che la squadra sia in grado di elaborare i suoi valori in ambito pratico – date loro lo spazio per farlo. Un buon inizio potrebbe essere quello di scrivere un accordo all’interno della squadra – un contratto di squadra dove discuterete come avete intenzione di lavorare e rendervi reciprocamente responsabili.
Far emergere le lacune di comunicazione e i conflitti
È più facile evitare argomenti spiacevoli in un mondo remoto ed è più difficile di conseguenza ottenere feedback. Inizia da te stesso – dai un piccolo feedback, sia buono che negativo, alla fine di ogni chiamata, ogni incontro.
E alla fine – ricordatevi di lasciare al team lo spazio per imparare sia dai successi che dai fallimenti. Non siete lì per proteggerli da tutto. Passo dopo passo, dovrebbero essere in grado di gestire più caos da soli e diventare meno dipendenti dal supporto dei project manager.
Adattare l’organizzazione agile ad un ambiente remoto è il prossimo grande passo per la comunità agile. Questo sta già accadendo in molte aziende in tutto il mondo – si tratta di una grande sfida per ogni team e ogni impresa in epoca pandemica.
Altri articoli che vi raccomandiamo di leggere:
Cos’è la gestione agile dei progetti?
Competenze e strumenti di gestione per la nuova economia che cambia
Qui potete scoprire di più su di me.
Fonti
https://www.netguru.com/blog/how-to-deal-with-agile-scrum-in-a-remote-environment
https://www.scrumalliance.org/
https://thedigitalprojectmanager.com/
https://www.dummies.com/careers/project-management/agile-project-management-roles
https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities