Advies

Waarom scrum niet altijd beter is

Digitale projecten ‘agile’ aanpakken wordt steeds populairder. Logisch, want het is een goede manier om snel en efficiënt resultaten te behalen en daarnaast biedt het de kans voortdurend tussentijds bij te sturen, zelfs op basis van real time gebruikerservaringen. De traditionele ‘waterval-methodiek’ verliest dan ook in hoog tempo terrein. Maar is dat wel helemaal terecht? BOOM-adviseur en interactiedesigner Jasper Rijk plaatst meteen een belangrijke kanttekening: “Een project moet zich wel lenen voor een agile aanpak en dat is lang niet altijd het geval”.

“Neem een grote Europese aanbesteding van een overheidsinstelling”, zegt Rijk. “Daarbij is het vooraf vaststellen van budget, planning en scope vaak een vereiste. Dan is agile werken geen optie, want daarbij moet altijd één van deze drie factoren flexibel zijn. Ook een kleiner, kortlopend project zoals een eenvoudige corporate website komt niet automatisch in aanmerking voor een agile aanpak. Daarbij is er namelijk vaak helemaal geen budget of tijd om iets te doen met voortschrijdend inzicht.”

 

Agile: stapsgewijs ontwikkelen

Om te kunnen bepalen of een digitaal project geschikt is om agile aan te pakken, is het belangrijk goed in beeld te hebben wat dit precies betekent. Agile wil zeggen dat je een methode gebruikt – zoals scrum – die iteratief is en stapsgewijs werkt. Het tegenovergestelde dus van traditionele ontwikkelmethoden zoals waterval, waarbij eerst alle wensen en eisen in kaart worden gebracht voordat er iets ontwikkeld wordt. Als je agile werkt, worden de wensen en eisen steeds duidelijker tijdens de ontwikkeling van een product of dienst. “Je weet dus vooraf niet precies hoe het eindproduct eruit gaat zien.”

 

“Een goede product owner is essentieel”

Scrum is één van de vele agile methodieken. Bij scrum werk je met een multidisciplinair team, met daarin een aantal vaste rollen. Zo is er een product owner - die eerste aanspreekpunt is namens de opdrachtgever - en een scrum master: een soort projectleider. Verder zijn er programmeurs en designers die vanaf het begin betrokken zijn bij het traject. Rijk: “Het is heel belangrijk dat je in al deze rollen kunt voorzien. Vaak zien we dat organisaties de rol van product owner niet ingevuld krijgen, omdat er niemand in huis is die én genoeg digitale kennis heeft én beslissingsbevoegd is of budgetmandaat kan krijgen. Een valkuil is om dan maar iemand in die rol te zetten die welwillend is en ‘wel vaker iets met digitale projecten heeft gedaan’. Maar juist omdat je bij scrum in korte tijd resultaten moet bereiken, is het essentieel dat ieder teamlid optimaal toegerust is voor zijn of haar rol. Dan kan je beter een externe product owner inschakelen, of een andere methodiek kiezen.”

Vertrouwen op onzekerheid

Groot voordeel van scrum is dat ieder deelproduct dat uit een sprint komt, meteen kan worden voorgelegd aan gebruikers. Daardoor is direct duidelijk of het product waardevol is of niet. Zo niet, dan zijn er maximaal vier weken werk ‘verloren’ gegaan. Rijk: “Vergelijk dat met de waterval-methodiek waarbij vooraf voor het héle product een allesbepalend programma van eisen wordt geschreven dat leidend is. Als na maanden werken het eindproduct niet werkt zoals gehoopt, moeten vaak alle fases opnieuw doorlopen worden.” Ook vinden veel klanten het prettig dat ze onderdeel kunnen zijn van het team in de rol van product owner.

 

Ieder voordeel kent echter ook valkuilen. Als de teamleden niet goed samenwerken of de backlog niet goed is ingericht, moeten de teamleden op elkaar wachten. Dan is de efficiëntie weg. En als de benodigde tijd en middelen per user story niet goed zijn ingeschat, is de kans groot dat sprintdoelstellingen niet worden gehaald. Rijk: “Bovendien moet je als organisatie simpelweg bereid zijn om op deze manier te werken. Niet iedereen vindt het prettig of durft te vertrouwen in een traject waarbij het eindproduct niet vaststaat. Als dat vertrouwen er niet is, kan de Waterval-methode geschikter zijn.”

 

De structuur van de waterval-methodiek

De waterval-methodiek wordt al sinds de jaren zeventig gebruikt voor softwareontwikkeling en is - ten opzichte van scrum – erg gestructureerd. Een waterval-project verloopt in strikt gescheiden fases: analyse > programma van eisen > ontwerp > technische ontwikkeling > testen > implementatie > onderhoud. Iedere verantwoordelijke per discipline rondt een fase af en draagt vervolgens het stokje over aan de verantwoordelijke van de volgende fase. Al in de tweede fase ‘programma van eisen’ worden alle doelstellingen, technische vereisten en functionaliteiten uitgewerkt. Op dat moment staan de scope, het budget en de tijdlijn van het project dus al vast. “Dit is ideaal als je te maken hebt met een projectleider die bij iedere stap de goedkeuring van verschillende managementteams nodig heeft. Vaak is dat in grotere organisaties het geval”, aldus Rijk. “Ook heeft deze methode voordelen als er sprake is van veel wisselingen in het betrokken team: bij waterval is alles zo goed en tot in de puntjes gedocumenteerd, dat een nieuw teamlid zo is ingewerkt. Tot slot dwingt het uitputtende en allesbepalende programma van eisen het team om vooraf zeer grondig onderzoek te doen naar doelstellingen en gebruikersbehoeften. Hierdoor kom je er soms al op voorhand achter dat er helemaal geen behoefte is aan het product dat ontwikkeld zou gaan worden.”

 

De juiste aanpak?

“Wat dan uiteindelijk de juiste aanpak is, hangt af van het type project en het type organisatie. In de praktijk zie je dat Scrum vooral tot zijn recht komt bij doorlopende ontwikkelingstrajecten, zoals de ontwikkeling van een app als Blendle of Strava. Hierbij worden continu nieuwe functionaliteiten uitgerold, getest en weer aangepast. Waterval leent zich dan weer beter voor een groot traject waaraan strenge eisen worden gesteld en waarvan de verantwoording niet bij één persoon gelegd kan worden. Denk aan de ontwikkeling van een Digi-D-portal.”

 

“En dan zijn er nog hybride constructies denkbaar. Je kunt bijvoorbeeld een nieuwe website ontwikkelen via de waterval-methodiek, maar wel tussendoor een gebruikerstest inlassen om aannames te valideren. Andersom kan je een Scrum-traject naar een hoger niveau tillen door voorafgaand grondig onderzoek te doen, of náást het programma van eisen ook met een backlog te werken, zodat je zeker niets over het hoofd ziet. Op die manier kan je het eindresultaat naar een nóg hoger niveau tillen, zonder een van de methodes geweld aan te doen. Wil je op zeker spelen, bijvoorbeeld als je voor het eerst met een nieuw team werkt, dan is het verstandig om één methode tot op de letter te volgen. Welke dat is, is dus voor ieder project en iedere organisatie weer anders.”