3 errori degli Scrum Master e come correggerli

Essere uno Scrum Master può essere un compito piuttosto difficile.

Se dai troppe indicazioni e supporto al team, questo si abituerà presto a farsi dettare tutto dallo Scrum Master. Se invece dai troppo poco supporto, il team si svilupperà più lentamente di quanto potrebbe. Se risolvi alcuni problemi per il team, presto ci si aspetterà che tu risolva ogni problema. Se però non risolvi i problemi del team, i membri prima o poi smetteranno persino di segnalare i propri impedimenti e problemi allo Scrum Master.

Gli Scrum Master camminano su un filo sottile ed è facile commettere errori. In questo articolo vengono descritti tre errori che gli Scrum Master commettono frequentemente, e per ciascuno viene offerto un breve suggerimento per la soluzione.

1) Lasciare che il lavoro traciml da uno Sprint all'altro

Il primo errore è, a mio avviso, una delle peggiori abitudini che un team possa sviluppare: lasciare che il lavoro si riversi da uno Sprint a quello successivo.

Questo accade quando un team non completa tutti i Product Backlog Item pianificati per uno Sprint e li porta semplicemente nel prossimo Sprint.

Non fraintendermi: di tanto in tanto capiterà che un team non riesca a completare tutto. In realtà, è persino un buon segno quando succede occasionalmente. Significa infatti che il team si pone obiettivi ambiziosi e non pianifica troppo poco lavoro per paura di non farcela.

Tuttavia, uno Scrum Master non dovrebbe nemmeno considerare come un peccato veniale il fatto che un team non completi il lavoro pianificato, altrimenti gli Sprint diventano confini artificiali e privi di significato. I team dovrebbero avvertire una leggera pressione quando si avvicina la fine dello Sprint. Un team dovrebbe pensare: "Oh, lo Sprint finisce domani. Oggi devo davvero restare concentrato e finire."

Se il traboccare del lavoro nello Sprint successivo è un problema nel tuo team, ci sono alcune cose che puoi fare:

Per prima cosa devi eliminare questa cattiva abitudine. Incoraggia i membri del team a pianificare il prossimo Sprint in modo da completare sicuramente tutto il lavoro. Ciò significa che dovrebbero prendersela con calma e pianificare il prossimo Sprint con un po' di cautela. Se poi tutto va bene, si possono aggiungere più attività allo Sprint.

Inoltre puoi cercare di far sì che il team provi un lieve senso di colpa quando non tutto viene completato. Non si tratta di far sentire qualcuno davvero male. I membri del team dovrebbero provare più o meno lo stesso senso di colpa che provo io in questo momento. Sto cercando di smettere di bere bevande gassate. Sto anche facendo progressi e non ne bevo da una settimana. Ma oggi, mentre scrivevo questo articolo, mi andava. Così me ne sono concessa una. Non mi sento male per questo, ma domani sicuramente non ne vorrò un'altra, per non ricadere nelle vecchie abitudini.

2) Conduzione dei Daily Scrum

Un secondo errore che osservo frequentemente negli Scrum Master è che si assumono la conduzione del Daily Scrum. Naturalmente lo Scrum Master dovrebbe partecipare ai Daily Scrum e dare il proprio aggiornamento. Tuttavia, non deve condurre il meeting, sollecitando continuamente i membri del team a partecipare ecc.

Lo Scrum Master dovrebbe spiegare le regole e lo scopo del Daily Scrum e condurre i primi due o tre meeting sollecitando le persone a partecipare. Dopo di che dovrebbe lasciare che il team conduca da solo i Daily Scrum.

Le attività di un Daily Scrum non sono particolarmente difficili. Non serve un "poliziotto" che regoli tutto, perché se lo Scrum Master conducesse il meeting in questo modo, la discussione sarebbe troppo rivolta verso lo Scrum Master.

Mi piace iniziare con un nuovo team moderando decisamente i primi meeting. Poi a un certo punto dico solo "Ok ragazzi, è ora di cominciare" e magari chiedo chi vuole iniziare. Ma presto smetto anche con quello.

Dopo alcuni meeting comincio a guardare ostentatamente l'orologio quando è ora di iniziare il meeting. Se necessario, mi schiarisco la voce abbastanza forte perché tutti capiscano cosa sta succedendo. E poi resto semplicemente in piedi in silenzio fino a quando qualcuno dice: "Oh, credo che dovremmo iniziare." Dopo qualche giorno in cui guardo l'orologio e mi schiarisco la voce, faccio un passo avanti e guardo solo l'orologio quando è ora di iniziare. E dopo qualche altro giorno smetto anche con quello. Resto semplicemente in piedi e aspetto che il meeting inizi.

Naturalmente non resto in silenzio durante tutto il meeting. Potrebbe essere necessario fare coaching a qualcuno perché entri più nel dettaglio, oppure interrompo qualcuno educatamente suggerendo se non si potrebbe approfondire dopo il Daily Scrum.

Immagina semplicemente che io (o un'altra persona esterna) sia presente al tuo Daily. In questo caso non si dovrebbe riuscire a capire chi sia lo Scrum Master del team solo guardando. Certamente ogni tanto lo Scrum Master dirà qualcosa che solo uno Scrum Master direbbe. Ma non dovrebbe succedere continuamente.

3) Lasciare che il team vada verso il burnout

Non sono un grande fan della maggior parte dei termini Scrum, ma il termine Sprint è particolarmente problematico. Quando spunto durante la corsa, mi stanco rapidamente e devo fare pause frequenti. È una metafora piuttosto infelice per un team.

Uno Sprint finisce e il successivo inizia. I team non dovrebbero iniziare il prossimo Sprint mentre si stanno ancora riprendendo dall'ultimo. Piuttosto, i team dovrebbero lavorare a una velocità sostenibile, resa nota da Kent Beck come Sustainable Pace.

Il terzo errore che vedo spesso è che gli Scrum Master permettono ai loro team di superare questa velocità sostenibile e di andare verso il burnout. Un buon Scrum Master dovrebbe prestare attenzione e proteggere il team da un eventuale burnout.

Molti team hanno un atteggiamento ottimista e questo ottimismo si trasferisce sulla quantità di lavoro che si prefiggono per uno Sprint. Gli Scrum Master dovrebbero stare in guardia e consigliare cautela ai team quando, durante lo Sprint Planning, rischiano di assumersi più impegni per uno Sprint di quanti ne abbiano portati a termine negli Sprint precedenti. Perché? Perché il team, anche se riesce a completare tutto il lavoro dello Sprint, rischia di iniziare il prossimo Sprint esausto e con troppo ottimismo riguardo alla quantità di lavoro. A un certo punto il team non sarà più in grado di mantenere una velocità sostenibile e "brucierà". Un buon modo per proteggere un team da questa situazione è creare spazi liberi in cui i membri possano decidere autonomamente su cosa lavorare.

6 x 2 + 1

Per questo mi piace usare un metodo che chiamo "6 x 2 + 1". Si riferisce a sei Sprint di due settimane più uno Sprint di una settimana alla fine. I membri del team possono scegliere autonomamente su cosa lavorare nell'ultimo Sprint. Alcune persone usano questo tempo per la propria formazione personale (leggere un libro, video training ecc.). Altre usano il tempo per fare refactoring di codice non elegante che il Product Owner non ha prioritizzato. Altri membri del team tentano forse un esperimento che secondo loro potrebbe portare a una nuova fantastica funzionalità. Tutto questo il team può deciderlo da solo.

Introdurre un tale ciclo può però avere molti più vantaggi. Il Product Owner ha così ad esempio un'intera settimana senza essere "disturbato" dal team. E questo è spesso il miglior argomento di vendita per coinvolgere un Product Owner.

Questo ciclo può essere vantaggioso anche per l'intera organizzazione, quando ci sono impegni da rispettare come ad esempio "Dobbiamo consegnare questa funzionalità entro 3 mesi!" La 13ª settimana dei 6 x 2 + 1 Sprint può essere utilizzata anche per uno Sprint normale se il team è in ritardo rispetto a una scadenza. Se il team riesce poi a rispettare la scadenza, gli si può comunque concedere successivamente uno Sprint di una settimana a libera disposizione.

Scopri di più su questi argomenti nei nostri training per Scrum Master e diventa competente in questo ruolo agile in soli tre giorni, imparando ad assumerti la responsabilità come Servant Leader.