Agile/Scrum door de bril van een softwareontwikkelaar
Collega Sander van Laarhoven, Front-end Developer bij Oliver IT, vertelt over zijn ervaringen met het werken volgens de Agile/Scrum methode en de ontwikkeling die bedrijven die deze methodiek toepassen hebben doorgemaakt. Een methode die werkt mits deze door de hele organisatie wordt omarmd en de belangrijke pijlers binnen Agile/Scrum goed worden toegepast.
Van de watervalmethode naar Agile/Scrum
Je bent als softwareontwikkelaar altijd gewend geweest om een boekwerk voor je kiezen te krijgen waarin alles wat de business wil krijgen van haver tot gort is uitgewerkt. Soms is elke pixel in het scherm al door een designer op zijn plek gezet en laat niets meer aan de verbeelding over. “Ga het maar maken” luidt dan de boodschap. Alle projecten werden vroeger volgens deze watervalmethode opgepakt. Dan staat er iemand in het team op die gehoord heeft dat er ook een andere manier bestaat, namelijk: Agile/Scrum. Daarmee zijn alle problemen van de watervalmethode verleden tijd. De eerste keer Scrum. Daar begon voor mij een periode van zowel succesvolle als minder succesvolle ervaringen met deze methodiek.
Na tien jaar en meer dan tien projecten te hebben uitgevoerd met Scrum heb ik veel dingen zien verbeteren rondom deze methodiek. Maar jammer genoeg heb ik ook veel goedbedoelde maar foute implementaties van Scrum methodieken voorbij zien komen. Ik ben ooit begonnen als consultant/ontwikkelaar bij een grote klant en heb daar de transitie van waterval naar Agile/Scrum volledig meegemaakt. Eerst als teamlid en later als Scrum master. Na deze tijd heb ik een tiental projecten bij verschillende bedrijven uitgevoerd volgens Scrum. Ik heb gemerkt dat elk bedrijf anders is en zijn eigen uitdagingen kent die een rol spelen.
Scrum implementatie binnen een organisatie
Wanneer een bedrijf de Scrum methodiek invoert is dat een hele verandering. Wat je vaak ziet is dat niet het gehele bedrijf omschakelt en zich er aan committeert. Alleen de ontwikkelteams van de IT-afdeling storten zich dan op Scrum en overige afdelingen zijn dan niet of maar zijdelings betrokken. Dit resulteert in een kromme werkwijze waarin het bovenste deel van de organisatie werkt volgens de waterval en PRINCE2 methodieken en het onderste deel met Agile/Scrum. In de consultancy noemen we dat ook wel ‘Waterscrum’. Dat neemt een hoop voordelen van de methodiek weg en is daarmee verre van optimaal.
De organisatie als geheel, waar ik destijds werkte, was nog niet echt op de hoogte van de methodiek, echter wilde het ontwikkelteam het graag proberen. We begonnen met het werken in sprints en het opleveren van story’s uit een groot functioneel ontwerp (FO). Dit was voor de tijd van Jira en Pivotaltracker en we werden daardoor gedwongen om een fysiek scrumbord te gebruiken. Dit verliep verassend goed doordat we in een vaste ruimte werkten en niet op afstand. Wat volgde waren stand-ups naast het scrumbord en vervolgens het verplaatsen van de briefjes. Post-it’s die vaker werden verplaatst vielen er wel eens af maar het voelde goed om al die briefjes langzaam naar de andere kant van het bord te verschuiven.
De business was niet gewend om met een scrum team om te gaan, dus liepen collega’s in het begin om de haverklap binnen om iets rechtstreeks aan een ontwikkelaar of ander teamlid te vragen en, indien mogelijk, een stukje functionaliteit toe te voegen of te wijzigen. Aangezien het team zelf nog een beetje groen was werden die mensen niet altijd naar de productowner verwezen en werd ‘scope creep’ een probleem. Langzaam leerden we om hier niet meer op in te gaan en de productowner leerde op zijn beurt ons te beschermen. Hij had moeite zich in de organisatie te positioneren omdat de methode nog niet volledig was ingebed. Er werden mensen uit de business uitgenodigd om na elke sprint een review sessie te doen en er werd commitment afgegeven vanuit het team om elke sprint het beloofde stukje functionaliteit op te leveren. Dit ging zo goed dat de organisatie het omarmde en volledig overging op Agile/Scrum. Later groeide deze organisatie uit naar 150 mensen en bestond bijna volledig uit scrum teams. Daarmee werd het echt een succesverhaal, ondanks de langzame weg daar naartoe.
De Scrum methodiek in de praktijk
Sindsdien is Scrum de standaard geworden binnen IT-projecten en is er betere tooling beschikbaar om dit te ondersteunen. Een nadeel is dat er veel mensen zijn die denken te weten hoe de Scrum methodiek zou moeten worden toegepast en daarbij net de belangrijkste aspecten verkeerd uitvoeren.
Een voorbeeld is het pokeren van story’s. Iedereen weet dat het bij Scrum om punten draait maar veel mensen kunnen het niet laten om tijd aan punten te verbinden. Bijvoorbeeld: “Het is ongeveer 2 dagen werk dus 3 punten” of “Je hebt 5 punten voor die story gepokerd, hoeveel dagen is dat?”. Hierbij hebben zij termen als complexiteit, team strength en velocity niet helemaal begrepen. De complexiteit van een story bepaalt het aantal punten en de tijd leert hoeveel punten een team in een sprint kan ‘verbranden’. Dat bepaalt op zijn beurt dan weer de velocity. Een volledig team heeft een 100% team strength en kan de volledige velocity verwachten, terwijl een incompleet team, door bijvoorbeeld vakantie of ziekte, een verminderde team strength heeft en daarmee ook een lagere velocity. Als je vooraf weet dat het team in de sprint een verminderde team strength heeft kan het aantal punten dat wordt opgenomen in de sprint worden verminderd. Zo wordt een team voorspelbaar en kan er ook een lange termijnplanning worden gemaakt. Vervolgens hoeft alleen de backlog te worden gepokerd en te worden uitgezet tegen het aantal sprints, hierbij rekening houdend met team strength en velocity. Daardoor weet de productowner precies welke story’s hij kan opleveren in de tijd die nog rest.
Een ander voorbeeld is het vastzetten van bijna alle pijlers in de beroemde duivelsdriehoek/vierkant:
In waterval projecten liggen alle pijlers uit het vierkant vaak vast en zodra er een wijziging nodig is in de scope volgt er een change. De pijlers Tijd en eventueel Geld worden vervolgens aangepast, waardoor Kwaliteit gewaarborgd blijft. In een Agile/Scrum situatie ligt dit anders. Daar mag de Scope niet vastliggen zoals bij een watervalmethode. Er wordt een tijd afgesproken in de vorm van een aantal sprints en de velocity van een team bepaalt het aantal storypunten dat daarbinnen kan worden gerealiseerd. De productowner bepaalt door middel van het prioriteren van de story’s in de backlog welke story’s binnen de gedefinieerde sprints worden opgenomen en dus welke scope er uiteindelijk wordt gerealiseerd. De scope van het project kan over de hele periode continu veranderen, enkel binnen een sprint liggen de opgenomen story’s in de betreffende sprint vast. Hij kan nieuwe story’s op de backlog zetten waardoor andere story’s opschuiven in prioriteit en dus mogelijk niet worden gerealiseerd als deze te laag op de backlog komen te staan. De story’s die lager op de backlog staan zijn dan blijkbaar niet belangrijk genoeg en daarmee is de business value van de uiteindelijk gerealiseerde functionaliteit zo hoog mogelijk. Mocht het toch van belang zijn deze story’s alsnog te realiseren moet er meer Tijd (in de vorm van sprints) en/of Geld (meer mensen en/of tijd) worden gegeven.
Vaak is het zo dat de organisatie boven het team nog vast zit in de watervalmethodiek en daarom alle functionaliteiten wil die ze hebben bedacht (vaste Scope), voor een vast bedrag (Geld) en met een vaste deadline (Tijd). Zodra er extra wensen of wijzigingen komen, dan is Kwaliteit de enige pijler die nog kan bewegen. Dat is een situatie die vaak voor komt en waar ikzelf ook regelmatig tegen heb moeten vechten. Het is moeilijk voor een organisatie om eraan te wennen dat enkel de hoogste prioriteiten worden gerealiseerd. Het vertrouwen binnen de organisatie in deze werkwijze zal moeten groeien. Dan krijgt de business met Agile/Scrum, door regelmatig terugkoppeling (reviews) te krijgen en door continu bij te kunnen sturen, veel meer waarde voor hun geld dan bij de watervalmethode.
Naar mijn idee kan iedereen een rol spelen in de kentering die een organisatie dient te maken bij het introduceren van Agile/Scrum. Vertel mensen hoe het volgens jou beter zou kunnen en let zelf op dat je je aan de richtlijnen houdt zodat er geen verwarring ontstaat en de tools goed worden gebruikt. De scrum master heeft de rol in het leiden van het team, maar ieder teamlid heeft ook de verantwoordelijkheid om zich maximaal in te zetten. Voorkom bijvoorbeeld dat een stand-up wordt verstoord doordat iemand continu afdwaalt of te lang in de details blijft hangen.
Zoals blijkt uit deze blog ben ik een groot voorstander van het uitvoeren van projecten volgens Agile/Scrum, maar dan enkel als de organisatie deze werkwijze volledig omarmd en erop wordt toegezien dat de belangrijke pijlers binnen de methodiek goed worden toegepast. Er is altijd ruimte voor kleine aanpassingen, echter dienen enkele bepalende aspecten op de juiste manier uitgevoerd te worden. Dat levert namelijk een beter resultaat op.
Auteur: Sander van Laarhoven, Front-end ontwikkelaar
