3 fouten die een Scrum Master maakt en hoe deze te corrigeren

Als Scrum Master kun je het zwaar hebben.

Een team van te veel advies voorzien zou ertoe kunnen leiden dat zij de gewoonte krijgen de Scrum Master alle werkzaamheden voor te laten kauwen. Maar wanneer je niet genoeg advies geeft bestaat de kans dat het Development team te langzaam vordert met het takenpakket. Los een aantal problemen op voor het team en voor je het weet ontstaat de verwachting dat de Scrum Master ieder probleem oplost. Daarentegen, wanneer je problemen niet oplost zullen de leden van het Development team de neiging hebben de Scrum Master niet meer te informeren over belemmeringen in het werkproces.

Scrum Masters bewandelen een fijne lijn als het gaat om het aanbieden van hulp. Er worden daarom veel fouten gemaakt. In deze blog omschrijf ik drie veelgemaakte fouten die ik Scrum Masters heb zien maken. Voor iedere fout bied ik een bondige oplossing aan om de fout te kunnen corrigeren.

Werk meenemen naar een volgende sprint

Allereerst vertel ik iets wat één van de slechtste gewoonten is dat een Scrum team kan ontwikkelen: toestaan dat werkzaamheden van de ene sprint worden overgebracht op de andere. Dit betekent dat werkzaamheden die ingepland stonden voor de huidige sprint niet zijn afgerond en worden overgedragen op de volgende sprint.

Voor de duidelijkheid: het komt wel eens voor dat een Development Team niet alle taken weet af te ronden. Eigenlijk is het goed dat dit af en toe gebeurt, omdat dit aangeeft dat een team eerder agressief is in het inplannen van werkzaamheden in plaats van zich iedere keer aan te weinig taken vast te leggen.

Echter, de Scrum Master en het Development Team zouden geen arrogante houding moeten aannemen door te denken dat zij de eindstreep toch wel halen. Wanneer zij dit wel doen worden de grenzen van sprints kunstmatig en betekenisloos. Teams zouden een klein beetje druk moeten voelen als het einde van een sprint nadert. Ik wil dat het team denkt, “Uh-oh, de sprint eindigt morgen. Het is beter als ik vandaag gefocust blijf en alles afrond.”

Als deze overdracht van werkzaamheden een probleem blijkt voor jouw team, zou je kunnen overwegen de volgende zaken toe te passen.
Eerst zal je de gewoonte moeten doorbreken. Moedig het team aan de volgende sprint op zo’n manier te plannen dat beslist alle taken worden afgerond. Plan met beleid en leg niet te veel werkzaamheden vast. Later, als alles goed gaat, kun je meer taken aan de sprint toevoegen.

Zorg er vervolgens voor dat het team zich een klein beetje schuldig voelt als zij niet alles binnen de vastgestelde termijn af weten te ronden. Ik wil niet dat zij zich rot gaan voelen. Dat is niet het punt dat ik wil maken. Ik wil dat zij zich net zo slecht voelen als ik op dit moment. Ik probeer te minderen met het drinken van frisdrank. Hoewel ik vooruitgang boek – ik heb het al een week niet meer gedronken –, kreeg ik vandaag behoefte een drankje te drinken. Dus dat deed ik. Ik voel me er niet heel slecht over, maar ik zorg ervoor dat ik er zeker niet nog een drink morgen, omdat ik niet wil terugvallen in die gewoonte.

Als Scrum Master leid je de Daily Scrum

Een tweede fout die je als Scrum Master kunt begaan is het leiden van de Daily Scrum. Echter denk ik wel dat een Scrum Master deel zou moeten nemen aan de dagstart en updates moet geven over de huidige stand van zaken. Maar het zou niet de taak van de Scrum Master moeten zijn om de meeting te leiden.

De Scrum Master zou de regels en het doel van de Daily Scrum kunnen uitleggen, vervolgens de eerste twee of drie mensen moeten oproepen om iets te vertellen en daarna het team de meeting zelf laten begeleiden.

De handelingen die bij een dagstart komen kijken zijn niet moeilijk onder de knie te krijgen. De meeting behoeft geen verkeersagent om mensen op te roepen iets mede te delen. Wanneer een Scrum Master de meeting alsnog begeleidt, wordt de discussie specifiek gericht tot de Scrum Master. Hierdoor verliest de dagstart zijn interactieve vermogen.

Leer meer over de Daily Scrum:

Met een nieuw team begeleid ik graag de eerste twee of drie meeting, maar zal dan de verandering maken door eenvoudigweg te vermelden, “Ok, iedereen, het is tijd om te beginnen.” Of ik vraag wie er als eerste wil. Maar al snel stop ik zelfs daarmee en laat ik het Development Team zichzelf begeleiden.

Na een aantal van dat soort meetings zal ik ander gedrag vertonen, waarbij ik zichtbaar op mijn horloge kijk wanneer het tijd is de meeting de beginnen. Indien nodig schraap ik op een luide manier mijn keel. Vervolgens blijf ik stil, totdat iemand zegt “Oh, ik denk dat we moeten beginnen.” Na dit ritueel een aantal dagen herhaald te hebben, versimpel ik de handelingen en kijk ik slechts op mijn horloge op de vooraf bepaalde starttijd. Na weer een aantal dagen kijk ik niet eens meer op mijn horloge. Ik ga er gewoon bij staan en wacht tot het team besluit de meeting te starten.

Daarentegen blijf ik zeker niet stil tijdens de gehele meeting. Soms behoeft een teamlid wat coaching om meer details te vertellen, of ik zou iemand er vriendelijk op moeten wijzen na de Daily Scrum dieper in te gaan op de details.

De volgende uitdaging geef ik graag aan je mee: beeld je in dat een buitenstaander aanwezig is bij de Daily Scrum. Tijdens het observeren van de meeting zou deze persoon niet in staat moeten zijn de Scrum Master te identificeren. Het komt wel eens voor dat de Scrum Master iets typisch zegt dat alleen een Scrum Master zou zeggen, maar in de meeste meetings gebeurt dat niet.

Toestaan dat een team geheel opbrandt

Ik ben geen fan van het Scrum vocabulaire, maar vooral sprint is een hinderlijk begrip. Wanneer ik een sprint inzet tijdens het hardlopen, word ik snel moe en loop ik tussendoor om mijn lichaam bij te laten komen.

Dat is een vreselijke metafoor voor hoe ik mijn team zou willen laten werken. Op het moment dat de ene sprint stopt, begint gelijk de andere al. Scrum teams zouden niet een nieuwe sprint moeten beginnen, terwijl ze nog aan het herstellen zijn van de vorige periode. In plaats daarvan zouden teams moeten werken volgens de voorwaarde van Kent Beck, namelijk middels een houdbaar tempo.

Zo komen we op de derde fout die ik Scrum Masters vaak zie maken: ze staan toe dat een team een sneller tempo hanteren en uiteindelijk opbranden. Een goede Scrum Master is op zijn hoede dit te voorkomen.

Veel teams zijn optimistisch, wat ertoe leidt dat zij een enorme hoeveelheid aan taken in één sprint proberen te verwerken. Scrum Masters behoren dergelijk gedrag in de gaten te houden en Development Teams moeten waarschuwen wanneer zij meer taken op zich nemen tijdens de sprint planning dan zij in het verleden in één sprint hebben opgeleverd. Waarom? Zelfs als het team al het geplande werk voor het einde van de sprint weet af te ronden, loopt dat team het risico de volgende sprint te starten met vermoeidheid en overmatig optimisme over de hoeveelheid werk dat ze aan kunnen. Zo’n team is eerder geneigd nogmaals meer werk op zich te nemen dan eigenlijk op een comfortabele manier opgeleverd kan worden. Doordat het team probeert te werken op een onhoudbaar tempo zullen de leden uiteindelijk uitgeblust zijn. Een andere manier om het team hiertegen te beschermen is het vrijmaken van tijd om het team te laten werken aan dingen die ze zelf kiezen.

Ik doe dit graag door een cyclus van ‘6 x 2 + 1’ te introduceren. Dit verwijst naar zes sprints van ieder twee weken gevolgd door een sprint van één week. In de laatste week beslist het team zelf waar zij aan werken. Sommigen gebruiken deze tijd voor persoonlijke ontwikkeling, zoals lezen, trainingen, etc. Anderen besteden deze tijd aan het uitvoeren van een experiment waarvan zij denken dat het een fantastische nieuwe functie kan zijn. Dit is volledig aan het team om te besluiten.

Niet alleen het team profiteert van de introductie van deze cyclus. Ook de Product Owner haalt hier als voordeel uit een hele week niet afgeleid te worden door het team. Vaak is dit hét punt dat de Product Owner over de streep trekt ook akkoord te gaan met de vernieuwing.

Vrij vertaald uit “Three Mistakes Scrum Masters Make and How to Correct Them” door Mike Cohn.

Meer weten over de Scrum Master? Bekijk onze animatie.

Updates ontvangen van de laatste ontwikkelingen?
Onze Agile Coaches voorzien je één keer in de twee weken van een informatief artikel. Zo blijf je altijd op de hoogte van de nieuwste inzichten binnen Scrum. Schrijf je via onderstaand formulier gemakkelijk in en ontvang artikelen, fijne tips en templates.

Ook interessant:

• De meest geboekte Scrum Master training van NL
• 10 tips voor je eerste Scrum project
• 9 vragen die Product Owners en Scrum Masters moeten stellen
• Agile training en coaching, nu ook in Duitsland

Volg ons op LinkedIn (we delen onze blogs met je) Of deel het in je netwerk: [addtoany]