In de meeste organisaties zie je dat de IT-afdelingen overgaan naar Scrum. Hierbij worden teams zelfsturend en werken ze in korte sprints om zo vaker naar productie te kunnen gaan. In plaats van hele brokken functionaliteit worden er ‘stories’ opgepakt die gepokerd zijn en het scrumteam geeft commitment af op het aantal stories dat zij oppakken zodat de organisatie weet wat het kan verwachten. Deze verandering van de werkwijze op de IT-afdeling betekent natuurlijk niet dat de hele organisatie overgaat naar Scrum. Sterker nog, in de praktijk merk je dat er nog regelmatig projecten zijn die botsen met het Scrum-proces doordat er afdelingen bij betrokken zijn die nog werken volgens de watervalmethodiek. Hoe kun je hier nu het beste mee omgaan?
Botsingen Scrum en waterval
Er zijn twee gebieden waarop ik in de praktijk de meeste botsingen zie ontstaan als er binnen projecten zowel volgens Scrum als waterval wordt gewerkt.
Lange- versus kortetermijn
De projecten werken nog met een langetermijnplanning wat botst met Scrum waarbij je pas bij een planningssessie vlak voor de sprint bepaalt wat je in een sprint oppakt. Daarnaast zullen de meeste Scrum-teams niet alle stories op hun backlog gepokerd hebben. Dit komt doordat je niet alle details van een story bekend zijn op het moment dat deze op de backlog wordt geplaatst. En het heeft pas zin om te pokeren als bekend is wat de volledige impact is van een story. Deze verschillende manieren van plannen botsen met elkaar, omdat je met scrum maar commitment afgeeft voor 1 sprint en niet voor een langetermijnplanning.
Verdeling hoeveelheid werk
Tevens zie je bij projecten vaak dat er meer druk op komt te staan zodra bepaalde mijlpalen gehaald moeten worden. In de oude wereld betekende dat overwerken/meer mensen inzetten of bepaalde functionaliteit laten vallen. Echter met Scrum geeft het team commitment af op een hoeveelheid werk het kan oppakken. Wat gebeurt er als het noodzakelijk is voor het project om meer functionaliteit op te pakken dan in een normale sprint opgepakt kan worden?
Hoe los je dit op?
Voor deze problemen zijn er een aantal oplossingen. Het Scrum-team kan de planningen beter op elkaar laten aansluiten door de de backlog te pokeren en daarbij gebruik te maken van T-shirt maten in plaats van punten. Waarbij elke maat een range van punten vertegenwoordigd. Een S is dan bijvoorbeeld 1-3 , M 3-5, L 7-13 enzovoorts. Op deze manier is er globaal bekend hoe groot de stories op de backlog zijn. Als je dan rekening houdt met de velocity van het team kan je een langetermijnplanning maken.
Het nadeel hiervan is dat de details van een story nog niet bekend zijn waardoor het daadwerkelijke aantal punten behoorlijk kan afwijken van de eerste inschatting. Dit is naar mijn mening een goede manier om inzicht te geven in een langetermijnplanning, omdat in de praktijk deze planning aardig klopt met de werkelijkheid doordat sommige stories te hoog worden ingeschat en sommige te laag waardoor de inschattingen gemiddeld genomen aardig kloppen.
Als er meer druk op een project komt te staan door bijvoorbeeld een mijlpaal, wordt het Scrum-team gedwongen hierin mee te gaan (tenminste zo heb ik het bij diverse organisaties ervaren). Er zijn een aantal opties om hiermee om te gaan. Het is mogelijk om gedurende één á twee sprints het Scrum-proces los te laten en het team gaat “best effort” aan de slag om zoveel mogelijk af te ronden. Een andere mogelijkheid is om meer punten op te pakken in een sprint dan normaal. Door over te werken zorgt het team ervoor dat de extra punten ook worden afgerond. Dit is naar mijn mening de beste oplossing omdat je toch vasthoudt aan Scrum-werkwijze en er op die manier ook voor zorgt dat de mijlpalen van het project gehaald worden.
Zoeken naar balans
Iedere organisatie zal moeten zoeken naar de balans tussen de Scrum-werkwijze van de IT-organisatie en de manier van werken bij overkoepelende projecten. Uiteindelijk zal je samen moeten kijken hoe je het gezamenlijke doel kunt behalen. De product owner speelt hierbij een belangrijke rol. Hij is een belangrijke link tussen het Scrum-team en de organisatie en moet de sprints zo plannen dat ze allemaal op elkaar aansluiten. Ook moet de langetermijnplanning bij hem bekend zijn. Daarnaast moet het Scrum-team hem ondersteunen door bijvoorbeeld mee te werken aan een T-shirt pokersessie en de product owner inzicht te geven in de voortgang van een sprint zodat deze een goed beeld heeft waar het team staat en op tijd kan aangeven als het team een sprint of de planning niet haalt. Tenslotte moet het team extra werk op willen pakken om de mijlpalen te halen. Want of je nu werkt volgens Scrum of waterval, het gaat uiteindelijk echt om de effort die je als team en collega’s in het project wil steken. Dit maakt het verschil tussen slagen en falen.