9 domande che Scrum Master e Product Owner dovrebbero porre
Prima di diventare Scrum Master, lavoravo come responsabile tecnico con una varietà di team. Una parte di questo lavoro consisteva nel prendere decisioni – e credo di averlo fatto abbastanza bene. Risolutezza e determinazione fanno parte delle mie caratteristiche personali.
Queste caratteristiche non mi hanno però aiutato molto quando sono diventato Scrum Master. Mi sono reso conto che, per avere successo come Scrum Master, dovevo fare meno affermazioni e porre più domande. Poiché questo non corrispondeva al mio stile naturale (e non erano le qualità che mi avevano portato al successo fino a quel punto della mia carriera), all'inizio mi è stato difficile.
Ma con un po' di pazienza sono diventato sempre più bravo nel porre domande. Alcune delle mie domande preferite
vorrei condividerle con voi. La maggior parte delle domande vale sia per gli Scrum Master che per i Product Owner.
2 domande sulle stime
Spesso ho bisogno di una stima approssimativa da un team. Non li inchioderò su questo. (Non sto chiedendo un commitment. Stime e commitment non sono la stessa cosa.) Voglio davvero solo una stima approssimativa. In questo caso, questa è una buona domanda:
"Non ho bisogno di una stima. Ma se chiedessi una stima, quale unità vi verrebbe in mente? Ore, giorni, settimane, mesi o anni?"
Sì lo so, queste unità possono sovrapporsi – alcune settimane possono essere più di un mese. Ma una stima come "Oh, settimane, un paio di settimane." è spesso sufficiente per prendere una decisione, il che può anche significare decidere di chiedere al team di stimare il lavoro un po' più nel dettaglio.
In situazioni in cui ho una stima ufficiale da un team, pongo spesso un'altra domanda:
"Quanto siete sicuri della stima?"
Qui si vuole scoprire quanto è affidabile la stima e se i membri del team sono d'accordo. Una stima di cui il team è sicuro al 90% sarà più precisa di una stima di cui il team complessivamente non è molto sicuro e in cui le opinioni divergono maggiormente.
I disaccordi all'interno del team riguardo alla stima possono inoltre essere un indicatore del fatto che il team ha dato questa stima in modo troppo frettoloso. Non deve essere per forza negativo, ma bisogna essere consapevoli che la stima non è così affidabile.
3 domande sulle decisioni del team
Come Scrum Master o Product Owner, a volte si vuole avere un'idea di quanto approfonditamente il team abbia riflettuto su una decisione. Ecco tre domande che pongo frequentemente:
- "Quali altre tre opzioni avete considerato prima di prendere la decisione?"
- "Qual è la cosa peggiore che potrebbe succedere se continuiamo in questa direzione?"
- "Cosa deve andare bene affinché questa sia davvero la decisione migliore?"
Forse non dovreste porre tutte e tre le domande contemporaneamente e nemmeno le stesse domande per ogni singola decisione del team.
Inoltre, come Scrum Master o Product Owner non ponete queste domande perché potete revocare la decisione del team. Tuttavia, avete il diritto di capire quanto il team si senta sicuro della decisione e se erano d'accordo.
Queste domande sono pensate per far emergere tali disaccordi. Se chiedi "Cosa deve andare bene affinché questa sia davvero la decisione migliore?" e qualcuno risponde "Tutto!", questo di solito significa che c'è un problema.
2 domande sui meeting
Non mi piacciono molto i meeting. Se mi trovassi in un corridoio con un mucchio di serpenti a un'estremità e un meeting all'altra, non saprei in quale direzione andare.
Per questo cerco il più possibile di ridurre al minimo il numero di meeting e il numero di partecipanti. All'inizio di un meeting pongo spesso le seguenti domande:
- "Abbiamo bisogno di tutti quelli che sono qui?"
- "Chi altro dovrebbe essere presente?"
La prima domanda viene posta per scoprire se si può fare a meno dell'una o dell'altra persona. Vedo spesso team agili che esagerano un po' con il lavoro di squadra e la collaborazione. I membri del team sentono poi di dover partecipare a ogni meeting, anche se è completamente irrilevante per loro. Può essere ad esempio lo sviluppatore JavaScript che partecipa a un meeting in cui si discute se vale la pena passare al nuovo aggiornamento del fornitore del database.
Se i membri del tuo team sono un po' troppo zelanti riguardo ai meeting, dovresti ringraziarli per il loro impegno nella collaborazione, ma allo stesso tempo comunicare loro che non devono essere presenti a ogni meeting. Stabilisci la regola che nessun membro del team dovrebbe partecipare a un meeting se non può contribuire abbastanza o non può trarne abbastanza valore.
(Sì, questo può essere sfruttato. In alcune circostanze dovrai chiarire ad alcune persone che questo non significa che non devono più partecipare a nessun meeting. Alla fine, il team nel suo complesso dovrebbe avere il diritto di prevalere sulla decisione di una singola persona di non venire a un meeting.)
Con la seconda domanda si vuole di conseguenza scoprire se qualcuno dovrebbe essere presente ma non c'è ancora. Anche se odio i meeting (probabilmente preferirei i serpenti), a volte dobbiamo avere più persone nei meeting.
Nel dubbio, optate per meno meeting e meno persone, ma alcuni meeting dovrebbero semplicemente tenersi – e questi meeting hanno ancora più valore quando le persone giuste sono presenti.
1 domanda per il giro in ufficio
Soprattutto quando lavoro come Scrum Master, passo molto tempo a partecipare a conversazioni in ufficio. Questo è noto anche come Management by Wandering Around (gestione camminando). Quando ad esempio noto che un programmatore e un tester stanno avendo una conversazione apparentemente importante, a volte vado da loro per vedere se posso aiutarli con qualcosa.
(Questo non va fatto ogni volta e nemmeno quando sembra una conversazione privata!)
A volte le conversazioni che colgo casualmente sono preziose anche per altre persone. Forse il Technical Writer dovrebbe sapere cosa hanno deciso il tester e il programmatore. Quindi chiedo:
- "Qualcun altro dovrebbe essere informato di questo?"
Se è così, mi offro di condividere queste informazioni, se mi è possibile. In caso contrario, mi offro di coinvolgere direttamente la persona interessata.
1 domanda per i Daily Standup
Nel Daily Standup guardo il Burndown Chart del team e poi mi chiedo spesso come il team intenda completare tutti i lavori entro la fine dello Sprint. Quando poi chiedo al team se riusciranno a completare tutto, sono di solito molto ottimisti.
Se ritengo questo irrealistico, guardo di nuovo il Burndown Chart e chiedo:
- "Sapete qualcosa che io non so?"
Forse ricevo come risposta che uno dei membri del team non ha ancora aggiornato le sue ore nel tool del team. Oppure qualcuno spiega che sono un po' in ritardo, ma hanno imparato molto e ora le cose si stanno accelerando. (Raramente trovo questo realistico, ma lo sento spesso.)
Chiedere al team cosa sanno e io no offre un'ottima opportunità per sincronizzare le ipotesi. Forse loro presumono che ora tutto si accelererà, ma io non la penso così. È quindi un'ottima domanda per far emergere ipotesi diverse.
Conclusione: le domande sono meglio delle affermazioni
Quando ho assunto per la prima volta il ruolo di Scrum Master, non sapevo ancora nulla del potere delle domande e ho perso molte opportunità di imparare di più sul mio team e sul loro lavoro. Solo dopo un bel po' di tempo ho scoperto che imparo di più quando pongo domande e ascolto davvero le risposte.
Spero che tu trovi queste domande utili quanto le trovo io.
Questo articolo proviene dal blog di Mike Cohn ed è stato tradotto in italiano da noi.
