De “Kun je dit even voor mij doen?”-vraag binnen scrum

De “Kun je dit even voor mij doen?”-vraag binnen scrum

Binnen scrum wordt gebruik gemaakt van de product backlog. extra werkDit is een grote to-do lijst met alles wat we voor een project moeten doen. Geen statische, in beton gegoten lijst zoals bij traditionele projecten, maar een dynamische lijst waar nieuwe dingen bijkomen, vanaf vallen (buiten scope vallen) en waarbij de prioriteit kan veranderen. Deze product backlog is de basis voor de werkagenda voor het team. Als het team bepaald wat ze in de komende sprint gaan doen, vormt de product backlog met de prioriteiten daar de basis voor. Tot zover klopt het theoretische verhaal. Maar het vergt wel discipline binnen het team om zich daar aan te houden. Ik kom in de dagelijkse praktijk helaas te vaak situaties tegen waarin er een product backlog is en er een sprint inhoud is vastgesteld, maar dat er toch teamleden zijn die zich niet aan deze agenda houden. Dat wordt veelal veroorzaakt door werk dat tijdens de sprint rechtstreeks bij teamleden wordt neergelegd. Een manager, teamleider, collega’s van de afdeling, etc vragen goedbedoeld of een bepaald stukje werk “er even tussendoor” gedaan kan worden omdat het “zo belangrijk”is. Ofwel, de “kun je dit even voor mij doen?”-vraag. Vaak vanuit een enthousiasme wordt er een toezegging gedaan om het extra stukje werk op te pakken.

Structureel of incidenteel?

Zolang het sprintdoel niet in gevaar komt, is het geen probleem. Toch? De vraag is of dit “extra werk” incidenteel of structureel is? Bij incidentele verzoeken zijn de gevolgen, mits het sprintdoel gehaald wordt, nihil. Bij structurele verzoeken kan het ten koste gaan van de productiviteit van het team. M.a.w. het team zou in een sprint meer werk kunnen doen als die verzoeken achterwege zouden blijven. Wat er namelijk gebeurt is dat de teamleden ieder voor zich de prioriteitskeuze maken dat de extra taken meer prioriteit krijgen dan het reguliere, planbare sprintwerk. En dat is geen goede ontwikkeling. Het is tenslotte de verantwoordelijkheid van de product owner om de prioriteit te bepalen wat concreet betekent dat de PO bepaald waar en wanneer het team aan werkt.

Transparantie

Hoe dan wel met deze vragen om te gaan? Transparantie is het sleutelwoord. Als teamlid zul je het allereerst met het team moeten bespreken waarbij antwoord moet worden gegeven of het doel van de huidige sprint in gevaar komt. Zoniet en besluit je als team dat het geen gevaar vormt, dan kun je het wel doen. Indien het sprintdoel wel in gevaar komt of als het structureel is, zet dan dit onplanbare werk om in planbaar werk door het op de backlog te laten zetten en in te plannen. De aanvragen dak dan een verzoek bij de Product Owner indienen om het werk op de backlog te laten zetten. De Product Owner zal dit verzoek beoordelen en de juiste prioriteit geven, rekening houdend met al het andere werk dat gedaan moet worden.

Geen automatisme

Door deze werkwijze houd je grip op al die extra taken die binnenkomen en de priotiteit van het andere werk. Je haalt hiermee het automatisme eruit dat extra, tussentijdse verzoeken om werk een hogere prio krijgen dan de geplande werkzaamheden. Dat geeft rust aan de teamleden omdat ze op een transparante manier kunnen reageren op deze veelvuldige verzoeken. En aan deze transparante manier van keuzes maken kan toch niemand een probleem hebben?

Johan van Delden is trainer en Agile Coach bij scrum@work, het bureau voor het succesvol toepassen van scrum. Wilt u weten scrum ook uw project kan helpen, neem dan contact met ons op.

No Comments

Sorry, the comment form is closed at this time.

X