9 vragen die Scrum Masters en Product Owners zouden moeten stellen
Voordat ik Scrum Master werd, werkte ik als technisch leider met allerlei verschillende teams. Een deel van die baan was het nemen van beslissingen – en ik denk dat ik dat best goed deed. Daadkracht en doorzettingsvermogen zijn nu eenmaal karaktereigenschappen van mij.
Deze eigenschappen hielpen me echter niet echt verder toen ik Scrum Master werd. Ik merkte dat ik, om als Scrum Master succesvol te kunnen zijn, minder stellingen moest poneren en in plaats daarvan meer vragen moest stellen. Omdat dat niet bij mijn natuurlijke stijl paste (en dit nu eenmaal niet de eigenschappen waren die me tot dat punt in mijn carrière succes hadden gebracht), vond ik dat in het begin lastig.
Maar met wat geduld werd ik steeds beter in het stellen van vragen. Een aantal van mijn favoriete vragen
wil ik graag met je delen. De meeste vragen gelden zowel voor Scrum Masters als voor Product Owners.
2 Vragen over inschattingen
Vaak heb ik een grove inschatting van een team nodig. Ik ga ze er niet op vastpinnen. (Ik vraag hier niet om een Commitment. Inschattingen en commitments zijn niet hetzelfde.) Ik wil echt alleen een grove inschatting. In dat geval is dit een goede vraag:
"Ik heb geen inschatting nodig. Maar als ik om een inschatting zou vragen, welke eenheid zou dan bij jullie opkomen? Uren, dagen, weken, maanden of jaren?"
Ja, ik weet het, deze eenheden kunnen overlappen – een paar weken kunnen meer dan een maand zijn. Maar een inschatting als "Oh, weken, een paar weken." is vaak goed genoeg om een beslissing te kunnen nemen, en dat kan ook betekenen: de beslissing nemen om het team te vragen het werk wat nauwkeuriger in te schatten.
In situaties waarin ik een officiële inschatting van een team heb, stel ik vaak nog een vraag:
"Hoe zeker zijn jullie over deze inschatting?"
Hier wil je achterhalen hoe betrouwbaar de inschatting is en of de teamleden het erover eens zijn. Een inschatting waar het team voor 90% zeker van is, zal nauwkeuriger zijn dan een inschatting waar het team over het geheel niet erg zeker van is en waar de meningen sterker uiteenlopen.
Onenigheid binnen het team over de inschatting kan bovendien een indicator zijn dat het team te overhaast deze inschatting heeft gegeven. Dat hoeft niet erg te zijn, maar je moet je er wel van bewust zijn dat de inschatting dan minder betrouwbaar is.
3 Vragen over teambeslissingen
Als Scrum Master of Product Owner wil je soms graag een gevoel krijgen voor hoe grondig het team over een beslissing heeft nagedacht. Hier zijn drie vragen die ik vaak stel:
- "Welke drie andere opties hebben jullie overwogen voordat jullie deze beslissing namen?"
- "Wat is het ergste dat zou kunnen gebeuren als we in deze richting doorgaan?"
- "Wat moet er goed gaan om dit echt de beste beslissing te laten zijn?"
Je hoeft misschien niet alle drie de vragen tegelijk te stellen, en ook niet dezelfde vragen bij elke afzonderlijke beslissing van het team.
Bovendien stel je als Scrum Master of Product Owner deze vragen niet omdat je de beslissing van het team kunt terugdraaien. Je hebt echter wel het recht om te begrijpen hoe zeker het team zich voelt bij de beslissing en of ze het eens waren over de beslissing.
Deze vragen zijn bedoeld om dergelijke meningsverschillen aan het licht te brengen. Wanneer je vraagt "Wat moet er goed gaan om dit echt de beste beslissing te laten zijn?" en iemand zegt "Alles!", dan betekent dat meestal dat er een probleem is.
2 Vragen over Meetings
Ik ben niet echt een fan van meetings. Als ik in een gang zou staan met aan het ene uiteinde een hoop slangen en aan het andere uiteinde een meeting, zou ik niet weten welke kant ik op zou rennen.
Daarom probeer ik zoveel mogelijk het aantal meetings en het aantal deelnemers aan die meetings tot een minimum te beperken. Aan het begin van een meeting stel ik vaak de volgende vragen:
- "Hebben we iedereen nodig die hier nu aanwezig is?"
- "Wie zou er nog meer bij moeten zijn?"
De eerste vraag wordt gesteld om te achterhalen of we het zonder de een of andere persoon kunnen stellen. Ik zie vaak agile teams die het iets te goed bedoelen met teamwork en samenwerking. De teamleden hebben dan het gevoel dat ze bij elke meeting aanwezig moeten zijn, ook al is die voor hen totaal irrelevant. Dat kan bijvoorbeeld de JavaScript-developer zijn die deelneemt aan een meeting over de vraag of het de moeite waard is om over te stappen op de nieuwe update van de databaseleverancier.
Als de leden van je team iets te enthousiast zijn als het om meetings gaat, bedank ze dan voor hun inzet voor samenwerking, maar maak ze tegelijkertijd ook duidelijk dat ze niet bij elke meeting aanwezig hoeven te zijn. Stel de regel op dat geen enkel teamlid aan een meeting zou moeten deelnemen als diegene niet genoeg kan bijdragen aan de meeting of er niet genoeg waarde uit kan halen.
(Ja, dit kan misbruikt worden. Mogelijk moet je sommige mensen duidelijk maken dat dit niet betekent dat ze aan helemaal geen enkele meeting meer hoeven deel te nemen. Uiteindelijk zou het team als geheel het recht moeten hebben om de beslissing van een individueel persoon om niet naar een meeting te komen, te overrulen.)
Met de tweede vraag wil je dan ook achterhalen of er iemand aanwezig zou moeten zijn die er nog niet bij is. Ook al heb ik een hekel aan meetings (ik zou waarschijnlijk de slangen verkiezen), soms moeten we gewoon meer mensen in de meetings hebben.
Kies bij twijfel voor te weinig meetings en te weinig mensen, maar sommige meetings moeten gewoon plaatsvinden – en die meetings zijn nog waardevoller als de juiste mensen erbij zijn.
1 Vraag voor het rondlopen op kantoor
Vooral wanneer ik als Scrum Master werk, besteed ik veel tijd aan het deelnemen aan gesprekken op kantoor. Dit staat ook bekend als Management by Wandering Around (nl.: management door rond te lopen). Als ik bijvoorbeeld merk dat een programmeur en een tester een ogenschijnlijk belangrijk gesprek voeren, loop ik soms naar ze toe om te kijken of ik ergens mee kan helpen.
(Dit moet je natuurlijk niet elke keer doen en ook niet als het eruitziet als een privégesprek!)
Soms zijn de gesprekken die ik toevallig opvang ook waardevol voor andere mensen. Misschien zou de technisch schrijver moeten weten wat de tester en de programmeur hebben besloten. Daarom vraag ik:
- "Zou iemand anders hier ook van op de hoogte moeten zijn?"
Als dat het geval is, bied ik aan om deze informatie te delen als dat voor mij mogelijk is. Zo niet, dan bied ik aan om de betreffende persoon er direct bij te halen.
1 Vraag voor Daily Standups
Tijdens de Daily Standup bekijk ik het Burndown Chart van het team en vraag ik me dan vaak af hoe het team van plan is al het werk voor het einde van de Sprint af te krijgen. Maar als ik het team vervolgens vraag of ze denken dat ze alles gaan halen, zijn ze meestal erg optimistisch.
Als ik dat onrealistisch vind, bekijk ik het Burndown Chart opnieuw en vraag ik:
- "Weten jullie iets wat ik niet weet?"
Misschien krijg ik als antwoord dat een van de teamleden zijn uren nog niet heeft bijgewerkt in de teamtool. Of iemand legt uit dat ze weliswaar wat achterliggen, maar dat ze veel hebben geleerd en dat alles nu weer in een stroomversnelling raakt. (Ik vind zoiets zelden realistisch, maar hoor het vaak.)
Het team vragen wat zij weten en ik niet, biedt een geweldige kans om aannames te synchroniseren. Misschien gaan zij ervan uit dat alles nu weer sneller zal gaan, maar ik denk van niet. Daarom is het een uitstekende vraag om verschillende aannames boven tafel te krijgen.
Conclusie: Vragen zijn beter dan beweringen
Toen ik voor het eerst de rol van Scrum Master op me nam, wist ik nog niets over de kracht van vragen en miste ik veel kansen om meer te leren over mijn team en hun werk. Pas na een hele tijd ontdekte ik dat ik het meeste kan leren door vragen te stellen en echt te luisteren naar de antwoorden.
Ik hoop dat je deze vragen net zo nuttig vindt als ik.
Dit artikel komt uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.
