3 fouten van Scrum Masters en hoe je ze oplost

Scrum Master zijn kan een behoorlijk lastige opgave zijn.

Geef je een team te veel advies en begeleiding, dan went het team er al snel aan om alles door de Scrum Master te laten bepalen. Geef je het team echter te weinig begeleiding, dan ontwikkelt het zich langzamer dan nodig. Los je een paar problemen op voor het team, dan wordt al snel verwacht dat je elk probleem oplost. Maar als je de problemen van het team niet oplost, stoppen teamleden op een gegeven moment zelfs met het melden van hun impediments en problemen aan de Scrum Master.

Scrum Masters bewegen zich op een dunne lijn en het is makkelijk om fouten te maken. In dit artikel beschrijven we drie veelgemaakte fouten van Scrum Masters en bieden we voor elk van deze fouten een korte oplossing.

1) Werk laten overlopen naar de volgende Sprint

De eerste fout is naar mijn mening een van de slechtste gewoontes die een team kan ontwikkelen: werk van de ene Sprint naar de volgende laten overlopen.

Dit gebeurt wanneer een team niet alle Product Backlog Items afrondt die voor een Sprint gepland waren, en dit werk gewoon meeneemt naar de volgende Sprint.

Begrijp me niet verkeerd: af en toe zal het voorkomen dat een team niet alles af krijgt. Sterker nog, het is zelfs een goed teken als dat soms gebeurt. Het betekent namelijk dat het team zichzelf een ambitieus plan oplegt en niet uit angst om het niet te halen te weinig werk voor een Sprint inplant.

Toch zou een Scrum Master het ook niet als een kleinigheid moeten beschouwen wanneer een team het geplande werk niet afkrijgt, want anders worden Sprints kunstmatige en betekenisloze grenzen. Teams zouden een lichte druk moeten voelen wanneer het einde van de Sprint nadert. Een team zou moeten denken: "Oei, de Sprint eindigt morgen. Ik moet vandaag echt gefocust blijven en alles afmaken."

Als het overlopen van werk naar de volgende Sprint in jouw team een probleem is, zijn er een paar dingen die je eraan kunt doen:

Als eerste moet je van deze slechte gewoonte af. Moedig de teamleden aan om hun volgende Sprint zo te plannen dat ze zeker al het werk afkrijgen. Dat betekent dat ze het rustig aan moeten doen en de volgende Sprint liever wat voorzichtiger moeten plannen. Als alles dan goed loopt, kan er meer werk in de Sprint worden opgenomen.

Daarnaast kun je proberen ervoor te zorgen dat het team zich een klein beetje schuldig voelt als niet alles wordt afgerond. Het gaat er niet om dat iemand zich echt slecht moet voelen. De teamleden hoeven zich alleen maar zo schuldig te voelen als ik me nu voel. Ik probeer namelijk minder frisdrank te drinken. Ik maak al vorderingen en heb al een week geen frisdrank meer gedronken. Maar vandaag, terwijl ik dit artikel schreef, had ik er zomaar zin in. Dus heb ik mezelf een frisdrank gegund. Ik voel me er niet slecht over, maar morgen wil ik er absoluut niet nog een drinken, zodat ik niet in oude gewoontes terugval.

2) Uitvoering van de Daily Scrums

Een tweede fout die ik vaak bij Scrum Masters zie, is dat ze de uitvoering van de Daily Scrums overnemen. Natuurlijk moet de Scrum Master aan de Daily Scrums deelnemen en zelf ook een update geven. Maar de Scrum Master hoeft de meeting niet te leiden om de teamleden steeds weer op te roepen om mee te doen enzovoort.

De Scrum Master zou de regels en het doel van de Daily Scrum moeten uitleggen en de eerste twee, drie meetings leiden en mensen aanmoedigen om mee te doen. Daarna zou hij het team echter zelf de Daily Scrums moeten laten uitvoeren.

De activiteiten van een Daily Scrum zijn niet bijzonder moeilijk. Er is geen "politieagent" nodig die alles regelt, want als de Scrum Master de meeting op die manier zou leiden, zou de discussie te veel op de Scrum Master gericht zijn.

Met een nieuw team begin ik graag zo dat ik de eerste meetings zeker zelf modereer. Dan zeg ik op een gegeven moment alleen nog maar "Oké mensen, het is tijd om te beginnen" en vraag ik misschien nog wie wil beginnen. Maar al snel stop ik ook daarmee.

Na een paar meetings begin ik dan opzichtig op mijn horloge te kijken als het tijd is om de meeting te starten. Als het nodig is, schraap ik mijn keel luid genoeg zodat iedereen begrijpt wat er aan de hand is. En dan sta ik gewoon stil totdat iemand zegt: "Oh, ik denk dat we moeten beginnen." Na een paar dagen van op mijn horloge kijken en keelschrapen ga ik nog een stap verder en kijk ik alleen nog maar op mijn horloge als het tijd is om te beginnen. En weer na een paar dagen stop ik zelfs daarmee. Ik sta er gewoon en wacht tot de meeting begint.

Natuurlijk zwijg ik niet tijdens de hele meeting. Het kan voorkomen dat ik iemand moet coachen om meer in detail te gaan, of ik onderbreek iemand beleefd en stel voor om de details misschien na de Daily Scrum te bespreken.

Stel je eens voor dat ik (of een andere onbekende persoon) bij jouw Daily aanwezig zou zijn. In dat geval zou je niet alleen door te kijken moeten kunnen achterhalen wie de Scrum Master in het team is. Het zal af en toe zeker voorkomen dat de Scrum Master iets zegt dat alleen een Scrum Master zou zeggen. Maar dat zou niet voortdurend moeten gebeuren.

3) Het team op een burn-out af laten stevenen

Ik ben niet bepaald een grote fan van de meeste Scrum-termen, maar de term Sprint is bijzonder problematisch. Als ik tijdens het hardlopen sprint, word ik snel moe en moet ik steeds weer pauzes nemen. Dat is een behoorlijk slechte metafoor voor een team.

Een Sprint eindigt en de volgende begint. Teams zouden niet aan de volgende Sprint moeten beginnen terwijl ze nog aan het herstellen zijn van de vorige Sprint. Teams zouden juist met een duurzaam tempo moeten werken, dat door Kent Beck bekend werd als Sustainable Pace.

De derde fout die ik vaak zie, is dat Scrum Masters het vaak toelaten dat hun teams dit duurzame tempo overschrijden en richting een burn-out werken. Een goede Scrum Master zou goed moeten opletten en het team indien nodig tegen een burn-out beschermen.

Veel teams zijn optimistisch ingesteld en dat optimisme vertaalt zich naar de hoeveelheid werk die ze voor een Sprint op zich nemen. Scrum Masters zouden op hun hoede moeten zijn en teams tot voorzichtigheid moeten manen als ze tijdens de Sprint Planning het risico lopen meer commitments voor een Sprint aan te gaan dan ze in eerdere Sprints hebben waargemaakt. Waarom? Omdat het team, zelfs als al het werk in de Sprint nog afgerond kan worden, het risico loopt de volgende Sprint uitgeput te beginnen en met te veel optimisme over de hoeveelheid werk. Op een gegeven moment zal het team geen duurzaam tempo meer kunnen aanhouden en „opbranden". Een goede manier om een team tegen deze situatie te beschermen, is het team ruimte te geven waarin ze zelf kunnen bedenken waar ze aan willen werken.

6 x 2 + 1

Hiervoor gebruik ik graag een methode die ik „6 x 2 + 1" noem. Dit verwijst naar zes Sprints van twee weken plus één Sprint van één week helemaal aan het eind. De teamleden mogen dan zelf kiezen waar ze in die laatste Sprint aan willen werken. Sommige mensen gebruiken deze tijd voor hun persoonlijke ontwikkeling (een boek lezen, videotraining enzovoort). Anderen gebruiken de tijd om lelijke code te refactoren die de Product Owner niet heeft geprioriteerd. Weer andere teamleden proberen zich misschien aan een experiment dat volgens hen tot een geweldige nieuwe feature zou kunnen leiden. Dit kan het team helemaal zelf bedenken.

Het invoeren van zo'n cyclus kan echter nog veel meer voordelen hebben. De Product Owner heeft op deze manier bijvoorbeeld ook een hele week zonder door het team „gestoord" te worden. En dat is vaak precies het beste verkoopargument om een Product Owner mee aan boord te krijgen.

Deze cyclus kan ook voor de hele organisatie voordelig zijn wanneer er commitments aangegaan moeten worden zoals: „We moeten deze feature binnen 3 maanden opgeleverd hebben!" De 13e week van de 6 x 2 + 1 Sprints kan ook voor een normale Sprint gebruikt worden als het team achterloopt op een deadline. Als het team later de deadline alsnog heeft gehaald, kun je ze altijd nog een Sprint van één week naar eigen inzicht geven.

Leer meer over deze punten in onze trainingen voor Scrum Master en word binnen drie dagen bekwaam in deze agile rol en leer verantwoordelijkheid te dragen als Servant Leader.