Ingrijpen in een zelf organiserend team

Print Friendly, PDF & Email

Tijdens de Daily Scrum meeting, halverwege de sprint, merk je een zorgwekkende trend op. Een taak, onderdeel van de belangrijkste user story, loopt al drie dagen vertraging op. De afhankelijkheid met een ander agile team is complexer dan ingeschat. Dat wordt een probleem, want de stakeholders hebben een verwachting over wat er uit ‘de fabriek’ komt op een bepaald moment. Dan ben je als Scrum Master geneigd om in te grijpen en te sturen om controle te houden over wat er gebeurt en invloed uitoefenen op het eindresultaat. Maar is dat het leiderschap dat nodig is in een Agile team? Lees wat ik heb geleerd van WEL ingrijpen in een zelf organiserend team.

Onze neiging om te ‘managen’

Als Scrum Master heb je een rol in het ondersteunen van de leden in het scrum team. Ook heb je een begeleidende rol naar andere teams die afhankelijkheden hebben en naar stakeholders in de organisatie die een belang hebben bij het product waar het ontwikkelteam aan werkt. Er ontstaat wel eens druk op het leveren van een functionaliteit in een bepaald tijdsbestek, terwijl het ontwikkelteam zelf organiserend is en dus zelf kiest hoe het sprintdoel wordt behaald. Wanneer dat sprintdoel in gevaar dreigt te komen wil je ‘managen’, ingrijpen dus.

Dit zegt de Scrumgids over zelforganisatie van teams:

‘Scrum Teams zijn zelf organiserend en multidisciplinair. Zelforganiserende teams kiezen zelf hoe zij het beste hun werk kunnen uitvoeren, in plaats van dat dit verteld wordt door iemand van buiten het team.’

‘Ontwikkelteams zijn zelf organiserend. Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit.’

Ontwikkelteams zijn niet zelfsturend, dus als Scrum Master heb je wel het stuur in handen, maar alleen op een hoger productniveau en organisatorisch niveau. Als het gaat om de activiteiten in een sprint heeft het ontwikkelteam de verantwoordelijkheid. Als zelf organiserend team bepalen zij welke taken er moeten worden opgepakt in een sprint en hoe dat wordt uitgevoerd om het sprintdoel te halen. Eerder refereerde ik aan teamverantwoordelijkheid in mijn blog over agile leiderschap; ‘We zijn met z’n allen Agile gebrainwasht’.

Waarom ik WEL ingreep

Vaak is niet alles in detail bekend bij de start van de ontwikkeling en kunnen nieuwe details het sprintdoel in gevaar brengen. Zoals in het voorbeeld over de afhankelijkheid van een ander team dat complexer bleek te zijn. Wanneer dit werd opgemerkt, ging ik ingrijpen en vervolgens uitzoeken hoe ik het probleem voor het team kon oplossen. Bijvoorbeeld door al te bedenken hoe ik de vertraging kon uitleggen aan een stakeholder. Of hoe ik het andere scrum team, met wie we een urgente afhankelijkheid hadden, onder druk kon zetten om iets te leveren. Welke taken we eventueel konden laten vallen in deze sprint zonder dat er serieuze problemen zouden ontstaan. En zelfs of we de reeds beloofde functionaliteit konden verkleinen om toch een werkend increment op te leveren.

De neiging om sturend op te treden was sterk, want er was druk van de omgeving om te leveren wat we hadden beloofd. Daarnaast wilde ik het ontwikkelteam helpen door mezelf het probleem toe te eigenen zodat het team gefocust verder kan gaan met andere taken uit de sprint backlog. Het leverde veel extra communicatie op binnen het team, naar andere scrum teams en naar stakeholders. Dat waren vaak geen leuke gesprekken en bracht ons negatieve energie. Bovendien was hierdoor de bijdrage aan de waardevermeerdering van het product lager dan beoogd.

Tijdens scrum retrospective bijeenkomsten bespraken we de incidenten en zochten we naar manieren om deze te voorkomen. Vaak was dan de conclusie dat het ontwikkelteam meer details wilde hebben bij de start van de ontwikkelactiviteit in een sprint. We gingen dus harder werken om alle details vooraf duidelijk te hebben. De ‘Definition of Ready’ werd steeds scherper gesteld. Dat begon wel erg te lijken op een agile machine die de scrum rituelen slaafs aan het volgen was.

Leermomentje…

Het besef dat het anders moet, kreeg ik bij het ontvangen van de feedback van het ontwikkelteam dat ik me te veel met hun activiteiten aan het bemoeien was. Deze feedback was volledig terecht en bovendien had ik ook zeker wel het vertrouwen in de kunde van alle teamleden. Waarom ging ik dan ingrijpen? Waren die problemen wel zo groot dat sturen noodzakelijk was? Later bleek dat ik dus beter niet kan ingrijpen. Achteraf gezien vond ik het vreemd van mezelf dat ik dat toch deed. Ik was dus iets aan het oplossen wat eigenlijk niet eens mijn probleem was, maar juist een verantwoordelijkheid van het ontwikkelteam. Dus…niet mijn probleem.

Lees in deel 2 van deze blog wat ik heb geleerd van NIET ingrijpen.

Foto: kantoor kat genaamd Jules.