Daily Scrum: 4 suggerimenti per farlo bene

In un mondo in cui lo “smart working” sta prendendo sempre più piede e i team hanno sempre più il bisogno di sincronizzarsi quotidianamente senza perdere troppo tempo, vorrei darti dei consigli eroici su come affrontare al meglio il daily scrum a testa alta, evitando gli strafalcioni che ho provato sulla mia pelle.

Ecco di seguito un’anticipazione dei 4 consigli:

• Il “daily scrum” è un’opportunità per prevenire i rischi, non una seccatura 
• Controlla la temperatura della stanza 
• Mantieni il daily scrum time-boxed 
• Non nominare i cavalieri della tavola rotonda ma “Walk the board”

Se sei un Product Manager o qualcuno fortemente interessato al mondo Agile, questo articolo è per te. 

Quindi, chin up, petto in fuori and let’s start the show.  

Il Daily Scrum è uno dei 5 rituali della Metodologia Agile Scrum ed è uno dei meeting più popolari nel mondo Agile è il “daily scrum” dove l’intero team di sviluppo si riunisce per 10-15 minuti ogni giorno e si sincronizza sui progressi ottenuti sino a quel momento. 

Molto comunemente viene anche chiamato “stand-up”. Questo termine proviene dalla cosiddetta “standup comedy” americana, dove i commedianti hanno un tempo prestabilito per fare i loro sketch, rigorosamente in piedi. Se avete l’opportunità di guardare la fantastica signora Maisel, fatelo, vi farete un’idea. 

Di seguito, i 4 suggerimenti che ti aiuteranno a trasformare la pratica del daily scrum in un meeting a prova di proiettile. 

1. Il “daily scrum” è un’opportunità per prevenire i rischi, non una seccatura 

Il daily scrum può diventare alquanto monotono, soprattutto per i programmatori che la mattina hanno solo voglia di un bel tazzone di caffè e non hanno alcuna intenzione di parlare dei loro “progressi”. 

Gli sviluppatori senior, soprattutto, non vogliono essere trattati come dei bambini, vogliono che tu ti fidi di loro e delle loro capacità, sono pagati per risolvere problemi, non per raccontarti le loro storielle ogni mattina. 

Quindi, cosa fare? Eliminarlo a priori e sperare che tutto vada secondo i piani? 

Assolutamente no! 

Più di una volta mi è stato chiesto di eliminarlo o farlo uno/due volte a settimana perché tanto ci sono le chat, c’è slack che può essere utilizzato per dare aggiornamenti live… 

Eliminarlo o farlo in maniera discontinua non è la soluzione. 

Quello che bisogna fare invece è far capire il perché esiste un daily scrum e perché è importante farlo TUTTI I GIORNI. Dai un problema da risolvere ai tuoi programmatori e non una soluzione. 

Chiedi cosa vorrebbero condividere in quel meeting e come potrebbe essere trasformato in un’opportunità per prevenire rischi e anticipare problemi.  

Una cosa che aiuta moltissimo in questo contesto e che ho imparato negli anni, è cercare di puntare sull’unicità del team, quali sono le caratteristiche che lo contraddistinguono? 

Si tratta di un team che si prende facilmente alla leggera o di un team molto serioso?  

Come si può trasformare un meeting giornaliero in un’opportunità imperdibile per fare meno e meglio?  

D’altronde, tutti noi siamo animali sociali e abbiamo la necessità di “appartenere”. E questo sentimento di appartenenza di “cameraderie” come dicono gli inglesi, è il fulcro del daily scrum, è quello che lo rende insostituibile. 

E se hai il consenso del team su come strutturare il meeting e come renderlo utile sei già mille miglia avanti rispetto a chiunque altro. 

Non a caso, “il lupo solitario muore ma il branco sopravvive”.  

Caso pratico: 

Una volta mi è successo di avere a che fare con un team molto particolare dove il silenzio imbarazzante si poteva tagliare letteralmente a fette durante lo standup.  

Il team era abbastanza nuovo e i membri non si conoscevano bene tra di loro, questo contribuiva ad aumentare il “discomfort.” 

Cosa ho fatto? 

Le prime volte ero sempre io ad introdurre la conversazione, magari partendo da qualche problema che era accaduto nei giorni precedenti, non sempre questo portava buoni risultati perché alla fine erano sempre gli stessi membri che parlavano, quelli un po’ più coraggiosi. 

Ad un certo punto però escogitai una tecnica, chiesi all’intero team di guardare al cosiddetto burn-down chart durante il meeting. 

Il burn-down chart è un grafico che permette di capire quanti task sono stati completati e quanti invece sono ancora in progress. Se la linea rossa sta al di sotto di quella grigia significa che il team sta bruciando (burn) più task del previsto e sta andando nella giusta direzione. 

Esempio di un “troppo buono per essere vero” burn-down chart: 

Se invece la linea rossa sta al di sopra di quella grigia, significa che il team non sta bruciando abbastanza e che la stima dei task è stata troppa ottimistica. In pratica, il team sta arrancando per finire lo sprint. 

Ed era proprio questa la situazione cui ci trovammo di fronte! Una bella fila di palazzi o picchi senza testa ne coda. Guardare per credere l’esempio qui sotto. 

Esempio di cattivo burn-down chart: 

Una volta che il team si trovava di fronte uno snapshot di vita reale sul loro operato, in questo caso non molto buono, a parte la sonora risata iniziale, il ghiaccio era finalmente rotto. 

Le capacità creative dei programmatori-e-non venivano a galla e chiunque si improvvisava ingegnere del burn-down chart. Tutti cominciavano a chiedersi cosa avrebbero potuto fare di meglio per rendere il grafico più “salutare” e di conseguenza il lavoro fatto durante lo sprint? 

Devo dire che, a parte qualche impedimento iniziale, da allora la maggior parte dei burn-down si presentavano così: 

Ambiziosi, ma non troppo! 

Quindi, in questo caso, la strategia di mettere di fronte al team la realtà dei fatti rompendo il ghiaccio aveva funzionato alla grande. 

Pensandoci, i programmatori amano i dati e questo gruppo ne era abbastanza affascinato.  

È bastato puntare sull’unicità del team e creare un sentimento di appartenenza per rompere il ghiaccio una volta per tutte. 

2. Controlla la temperatura della stanza 

Lo standup è un meeting “fatto” dal team e “per” il team. Questo include Product Owner / Product Manager. Ciò non significa che il Product Manager deve fare da protagonista. 

La strategia più opportuna per un Product Manager è quella di andare ma diventare un silente ascoltatore. 

L’intelligenza emotiva del team spesso emerge quando gli si viene data la possibilità di essere autonomi e indipendenti.  

Ci vuole molto coraggio nel mettersi da parte piuttosto che stare al centro dell’attenzione. Il team di sicuro non ha bisogno di un proxy che parli per loro o che faccia le domande al posto loro. Il team necessita di fiducia e di imparare ad auto-organizzarsi. 

Attenzione, l’auto-organizzazione di sicuro non è innata, ma crescerà insieme al team giorno dopo giorno.  

A volte ci sarà bisogno di intervenire per fare le domande giuste e facilitare la collaborazione, soprattutto all’inizio quando il team è ancora acerbo e ha bisogno di una guida forte. 

Altre volte, invece, bisognerà mordersi la lingua e lasciare che il team impari dai propri errori. 

In ogni caso, la strategia che funziona di più, è fare un passo indietro è testare la “temperatura della stanza”, capire a che grado di maturità si è e procedere di conseguenza. 

3. Mantieni il daily scrum time-boxed 

A chi non è mai capitato di avere un membro del team un po’ logorroico alzi la mano! 

A me, più di una volta. Cosa fare in queste situazioni? 

Essere diretti ma anche un po’ diplomatici. Sembra impossibile? 

No, non lo è! Basta essere chiari con chi si ha di fronte e spiegare il motivo per il cui il daily scrum deve essere time boxed. 

Cosa significa quando un evento è time boxed? 

Semplicemente che non può prendere più tempo di quanto previsto inizialmente. 

Il time box permette al team di soffermarsi sugli aspetti più importanti e di rispondere alle 3 domande tipiche del daily scrum: 

• Cosa hai fatto ieri? 
• Cosa farai oggi?
• Ci sono dei problemi che ti impediscono di andare avanti? 

Esempio di vita reale: 

In uno dei team in cui ero Project Manager, c’era un membro abbastanza brontolone. Per lui era consueto arrivare al daily imbronciato e cominciare a raccontare tutti gli impedimenti che aveva affrontato il giorno prima. In più, si aspettava che i problemi si risolvessero da soli o che qualcun altro del team lo facesse per lui. 

In poche parole, gli piaceva lamentarsi. 

La prima volta, lo presi di lato e cercai di capire quali fossero i reali motivi per cui si lamentava. Dopo essersi sfogato con me riguardo le sue frustrazioni, sembrava quasi avesse capito… in realtà, la strategia funzionò per uno o due daily successivi, ma poi, eravamo di nuovo punto e a capo. 

Al secondo tentativo, decisi di fare un altro esperimento. Questa volta, non appena mi accorgevo che stesse andando fuori strada durante il meeting, gli chiedevo di venire a parlarmene dopo il meeting. Anche questo esperimento funzionò per un giorno o due e poi di nuovo, tornavamo al punto di partenza. 

Terzo esperimento: questa volta proposi una strategia diversa. Gli proposi di attenersi alle tre domande del daily scrum in maniera letterale. In più, se avesse avuto qualcosa che lo disturbava o pensava avesse preso più tempo, ne avrebbe parlato con la persona diretta interessata subito dopo il daily con un follow-up meeting. 

Questa volta funzionò! 

E sai perché?  

Perché la persona interessata aveva finalmente capito che lamentarsi non serviva a nulla e che andare direttamente alla fonte dei problemi avrebbe fatto risparmiare tempo ed energie a tutti.  

4. Non nominare i cavalieri della tavola rotonda ma “Walk the board” 

“Colpevole”, lo ammetto!  

Anch’io mi sono lasciata andare alla tentazione di chiamare i membri del team per nome durante il meeting e chiedergli quali fossero gli update… Non si fa! 

Come già detto, il daily scrum è fatto dal team e per il team. Di sicuro gli sviluppatori non hanno bisogno di qualcuno che gli imbocchi le parole. 

All’inizio succede spesso che si cominci il meeting con un silenzio abbastanza “imbarazzante” e che nessuno abbia il coraggio di prendere la parola.  

La tentazione di puntare il dito al primo sviluppatore di turno e chiedere: “ehi, vuoi cominciare tu con gli update?” è tanta, ma bisogna trattenersi. 

Io ho scoperto un trucchetto niente male che in inglese si chiama “walk the board”, letteralmente “cammina la lavagna”. 

Questa metodologia guida la discussione, facendo parlare gli sviluppatori “proprietari” dei task uno alla volta che seguono la board fisica o virtuale da destra verso sinistra. 

Perché questo metodo aiuta un sacco? 

Perché ci si concentra molto di più su quei task che sono quasi completi: “in progress”, “in review” e meno su quelli che ancora devono cominciare. 

In questo modo, si attiva il cosiddetto “swarming”, una tecnica molto conosciuta in Agile, in cui l’intero team fa in modo di sbloccare i task già iniziati, testandoli e portandoli a compimento, mettendo per un attimo da parte quelli che ancora non sono stati toccati. 

Questo mindset aiuta tantissimo in quegli ambienti dove il multi-tasking è deleterio e porta a non finire nessun task. 

“Smettila di cominciare, comincia a finire” questo è il mio mantra in situazioni del genere. 

Io la uso anche nella vita quotidiana e funziona a bomba. 

Adesso che ti ho elencato i 4 suggerimenti per avere un daily scrum a prova di proiettile, tocca a te sperimentare e mettere in pratica le tecniche elencate qui sopra. 

Mi raccomando, non preoccuparti se la prima volta non va tutto rose e fiori, ma sii costante e non demordere, sono sicura che con un po’ di costanza anche le situazioni più difficili si possono trasformare in opportunità di crescita. 

Che la forza sia con te!