Kan waterval nog wel of moet het altijd agile zijn?

Welke aanpak is het meest geschikt voor verandertrajecten?
Joep de Leeuw
Projectmanager

Veranderingen moeten steeds sneller worden geïmplementeerd, de time to market moet korter wil het resultaat van een project nog concurrerend zijn. Veel grote projecten falen, sterven een schone dood in de realisatiefase door verouderde ideeën en specificaties.

Daarom wordt tegenwoordig steeds vaker gebruik gemaakt van een agile aanpak bij de uitvoering van projecten. Binnen verschillende branches groeit de methode zelfs in rap tempo uit tot een bepalende, nieuwe standaard voor het realiseren van veranderingen. De overgang van de ‘traditionele’ waterval benadering naar een agile werkwijze roept veel vragen op die te maken hebben met voorspelbaarheid, planning en scope.

De claim van agile is dat snel kan worden geanticipeerd op veranderingen en dat het kan worden ingezet wanneer de exacte klantvraag en requirements nog niet helder zijn. Dit klinkt mooi. De vraag is echter in hoeverre al deze veranderingen nodig zijn wanneer op voorhand het gewenste resultaat en plan goed worden uitgedacht. Tegelijk kan men zich afvragen of een agile aanpak wel altijd mogelijk is en zo ja, onder welke condities en welke afwegingen zijn hierbij te maken?

In dit artikel zullen we deze kwestie onder de loep nemen en de keuze voor agile of waterval verder duiden.

Voorspelbaarheid

Allereerst beschouwen we de afweging om al-dan-niet agile te werken vanuit één van de belangrijkste aspecten van goed projectmanagement: het voorspelbaar laten verlopen van verandertrajecten.

Binnen agile wordt de voorspelbaarheid geborgd door diverse mechanismen. Zo zijn er de demo’s en reviews per sprint, waarbij kort cyclisch wordt gemonitord wat de voortgang is en in hoeverre het minimum viable product is behaald. Hierbij kan dus expliciet worden bijgestuurd en ge(her)prioriteerd, waarmee de voorspelbaarheid over de korte termijn wordt geborgd. De planning (voorspelling) over het geheel van een verandertraject wordt vormgegeven via Agile at Scale methoden zoals SAFe en LeSS, waarin op basis van een ‘hoog over’ uitwerking van de probleemanalyse en oplossing een grofmazige planning  over de komende maanden wordt bepaald.

De vraag is of hiermee een agile aanpak even voorspelbaar kan zijn als de klassieke waterval project aanpak. Binnen de klassieke waterval project aanpak wordt de voorspelbaarheid geborgd door een gedetailleerde(re), door de klant geaccordeerde ‘bouwtekening’ als uitgangspunt te nemen en te werken vanuit vooraf gedefinieerde werkpakketten en projectfaseringen. Veranderende inzichten worden dan via het RFC proces afgewikkeld.  In de praktijk blijkt daarbij vaak dat RFC’s aan het eind van een fase of project komen en juist dan relatief duur zijn. Dit omdat er dan (veel) meer moet worden verbouwd, wat extra negatieve budgettaire consequenties heeft.

Betekent dit laatste aspect dan dat de waterval methode tot minder voorspelbare resultaten leidt dan de bij hantering van de agile aanpak? Dat is maar net vanuit welk perspectief je er naar kijkt. Een belangrijk onderscheid is namelijk dat agile uitgaat van een vast budget: je geeft niet meer uit dan een bepaalde hoeveelheid geld en realiseert binnen een vaste timebox die zaken die de meeste klantwaarde leveren. Daarmee is de scope dus variabel geworden. Bij een waterval project is deze juist ‘fixed’. Hierdoor blijkt in de praktijk het budget vaak aan verandering onderhevig en wil men via het RFC proces voorspelbaar blijven en bijsturen om te voldoen aan de veranderende vraag vanuit ‘de nieuwe  werkelijkheid’.

De nieuwe werkelijkheid

Hier zit een tweede fundamenteel verschil tussen agile en waterval. Agile is namelijk gebaseerd op het paradigma ‘embrace change’ en gaat er vanuit dat over het algemeen aan het begin van een project helemaal niet precies bekend is wat het eindresultaat exact zal (moeten) zijn. In een veranderende en dynamische wereld kan namelijk in de loop van het project ook de perceptie over het eindresultaat veranderen. De waterval methode daarentegen gaat er vanuit dat het beeld over het gewenste eindresultaat al in voldoende mate aanwezig is bij aanvang van het project, waardoor wijzigingen tijdens de realisatie minder waarschijnlijk (en wenselijk) zijn en het eindresultaat alleen via een (veelal tijdrovend) change proces kan worden bijgesteld.

Al met al is de constatering dat in zowel de traditionele waterval projectaanpak als in de agile aanpak de voorspelbaarheid wordt geborgd, zij het vanuit verschillende uitgangspunten en beheermechanismen. Het belangrijkste voordeel van agile hierbij is dat door de continue (klant)feedbackloop en de mogelijkheid om in een vroeg stadium gebruik te maken van ‘tussenproducten’ de kans groter is dat het eindproduct beter aansluit bij de veranderende klantwens en in ieder geval de klant eerder duidelijkheid heeft over wat hij precies krijgt.

Moeten we wel voorspelbaar willen zijn?
Voorspelbaarheid is wat we graag willen omdat we bang zijn dat de benefits tegenvallen, in termen van tijd, geld of kwaliteit. Echter vernieuwing gedijt het best in een omgeving waar je kan experimenteren, waar je even niet voorspelbaar bent, en even een stap opzij doet en zo (bij toeval) een nieuw efficiënter pad vindt, waar je de tijd krijgt voor bijvoorbeeld in de vorm van een Proof of Concept een nieuwe techniek uit te proberen. We moeten niet streven naar sec voorspelbaarheid, maar naar de kans op zoveel mogelijk toegevoegde waarde te leveren over een bepaalde periode? Als je dat uitgangspunt neemt, ga je anders om met je backlog (te realiseren functionaliteit) en geef je medewerkers meer tijd om hun creativiteit de ruimte te geven en met nieuwe ideeën te komen. Nuance hierop is dat dit geen doel op zich moet worden en dat je de juiste balans moet vinden in relatie tot het verwachte resultaat. Suggestie: ruim expliciet tijd in voor experimenteren, verbeter ideeën, met als doel het project te versnellen of meer klantwaarde te bieden.

Dus.. dan altijd agile?

Op basis van het voorafgaande zou de conclusie kunnen zijn dat er altijd van agile gebruik moet worden gemaakt. Immers, de voorspelbaarheid wordt in beide methoden geborgd, terwijl de agile aanpak het bijkomend  voordeel oplevert van continue klant feedback. Tegelijkertijd is dit voordeel niet in elke context even relevant en kunnen andere overwegingen ertoe leiden om toch voor waterval te gaan. Factoren die hierbij een rol spelen zijn onder meer:

Autonomie van het team in besluitvorming

De agile aanpak stelt veel eisen aan de organisatie en het team waarbinnen met agile wordt gewerkt. Belangrijke voorwaarde is dat de besluiten door één persoon (product owner) kunnen worden genomen en dat teams direct toegang hebben tot deze product owner. In de praktijk zien we veel gevallen waarin dit onvoldoende is geborgd. De product owner heeft dan onvoldoende mandaat, is veel tijd bezig zijn/haar achterban te managen, waardoor de besluiten die een agile team nodig heeft om efficiënt te werken niet snel genoeg kunnen worden genomen. Voor elk besluit moet de product owner de stuurgroep of de achterban consulteren. Gevolg is dat vertraging optreedt en de agile aanpak niet datgene brengt wat het belooft. In een situatie waarbij de product owner rol onvoldoende wordt ingevuld en hierdoor het team beperkt autonoom beslissingen kan nemen zal de agile aanpak dus niet de best passende projectmethode zijn.

Omgevingsdynamiek & scope en tijd

Agile geeft de mogelijkheid telkens tussentijds te ervaren, evalueren, leren en bij te sturen. Ideaal dus voor een veranderende omgeving. De vraag is waarom je dit zou willen wanneer de projectcontext als vooronderstelde constante kan worden beschouwd? Helemaal in de situatie waarin de scope en opleverdatum onveranderbaar zijn. Bijvoorbeeld in het geval waarbij nieuwe wet –en regelgeving binnen de kaders van een bestaand systeem moeten worden toegepast. Het why en what zijn volkomen helder, de oplossing kan vooraf worden ingeschat en ingeschaald, waarna de realisatie en oplevering als lineair traject kan worden doorlopen. “De nieuwe werkelijkheid”  is dus vooraf exact bekend. Het onnodig gebruiken van agile rituelen leidt in die situaties tot een inefficiënt realisatieproces.

Ervaring met agile

De ervaring van het team met agile werken is een belangrijke factor in de afweging al dan niet met agile te gaan werken. Zeker in relatie tot de verwachte duur van het project. Wanneer het project een korte verwachte tijdspanne heeft en er binnen het team weinig ervaring met de agile werkwijze is, dan ligt het voor de hand dat de investeringen in agile vaardigheden niet opwegen tegen de te verwachten baten. Vanuit de theorie wordt hierbij vaak een leerproces van een half jaar genoemd alvorens de ‘agile machine ‘ op stoom is. Dit is niet alleen van toepassing op de teams die de verandering realiseren maar geldt evenzeer voor de beheerverantwoordelijken in de lijn. Door met DevOps teams te werken komen deze werelden bij elkaar.

“Sliceability” van de oplossing

Deze randvoorwaarde gaat over de vraag in hoeverre de oplossing of het product is op te knippen in opleverbare deelproducten welke demonstreerbaar en ‘potential shippable’ zijn. In feite, hoe goed leent de oplossing zich om door gebruikers te worden getoetst? Dit heeft onder meer met de tastbaarheid van de oplossing te maken, waarbij het voor de hand lijkt te liggen dat vooral front-end oplossingen zich bij uitstek lenen om getoetst en vervolgens (in prototype) te worden gebruikt. Voor back-end functionaliteiten welke minder makkelijk toonbaar zijn lijkt het werken met agile daarentegen een minder voor de hand liggende keuze te zijn.

Omvang van het project

Kleinere project lijken meer geschikt voor agile dan grotere projecten omdat er bij een groot project meer afhankelijkheden gemanaged moeten worden en er meer coördinatie nodig is. Er is dan meer de behoefte om de afhankelijkheden vooraf uit te werken en te specificeren. We zien in de praktijk hier een mengvorm tussen waterval en agile ontstaan waarbij het project als geheel waterval wordt aangepakt en er tijdens de realisatie fasen agile methodieken worden toegepast.

Model

Bovengenoemde factoren bepalen mede of een agile dan wel een waterval aanpak meer of minder geschikt is bij de realisatie van een verandering. Zodoende kan het volgende model worden geschetst dat kan helpen bij het besluit al-dan-niet een agile aanpak te hanteren.

Uiteraard kent dit model beperkingen en pretendeert het niet allesomvattend te zijn. Interessante vragen zijn bijvoorbeeld waar het omslagpunt ligt in de keuze voor agile of waterval in relatie tot de projectomvang en hoe zit het met de veranderingsbereidheid en het verandervermogen van de organisatie? Agile vraagt namelijk om veel meer flexibiliteit, om DevOps teams die via scrum methoden zowel continuïteit als verandering in hun backlog hebben staan. Dit zijn fundamentele keuzes met niet alleen impact op de projectorganisatie, maar veelal ook met ingrijpende consequenties voor de lijn- en beheerorganisatie. De vraag is in hoeverre organisaties deze keuzes willen en kunnen maken.

Verder biedt het model geen garantie dat bij een project dat uitermate geschikt lijkt voor een agile aanpak, de keuze voor agile ook daadwerkelijk leidt tot de gewenste resultaten. Hiertoe is de implementatie van de agile aanpak binnen het project en de organisatie essentieel. Benieuwd welke aandachtspunten hierbij een rol spelen? Download dan onderaan de pagina: Agile: een paar lessons learned. 

Voor nu biedt het model vooral aandachtspunten ter overweging bij de te kiezen projectaanpak. Daarbij is het goed te beseffen dat sommige factoren beïnvloedbaar zijn en dan juist richting kunnen geven aan wat je vooraf zou moeten regelen om agile te kunnen werken. Neem als voorbeeld het mandaat van een product owner: Wanneer blijkt dat dit slechts in beperkte mate aanwezig is en je toch agile wilt gaan werken, stel dan als randvoorwaarde dat het mandaat wordt vergroot.

Conclusie

In een wereld waarin de agile aanpak steeds meer terrein wint ten opzichte van de traditionele waterval projectaanpak, is de vraag in hoeverre agile of waterval de meest geschikte methode voor het succesvol realiseren van veranderingen is.

In dit artikel is deze vraag in eerste instantie opgehangen aan de mate van voorspelbaarheid. Daaruit blijkt dat beide ‘scholen’ vanuit hun verschillende uitgangspunten voorspelbaarheid borgen in mechanismes en/of processen. Agile is een methode voor een organisatie om succesvol veranderingen door te voeren, met als kenmerk dat er snel ingespeeld kan worden op een veranderende klantvraag . Echter, niet in alle gevallen is agile de beste keuze. Er zijn bepaalde projecten die vooraf zo voorspelbaar te plannen zijn, waarbij ‘de nieuwe werkelijkheid’ vooraf scherp te definiëren is, dat daar een waterval aanpak uitstekend bij past. Overigens kunnen in een organisatie waterval projecten en agile projecten ook naast elkaar bestaan.

Daarom zal situationeel en afhankelijk van verschillende factoren moeten worden bepaald welke aanpak het meest geschikt is. Het voorgestelde model kan helpen bij het maken van een gefundeerde keuze.

Het daadwerkelijk kiezen van de meest geschikte aanpak, deze op de juiste wijze implementeren en daardoor voorspelbaar kunnen werken blijft echter de kunst. Tenslotte vereist dit laatste nog steeds een vakkundige besturing van de verandering of het project, ongeacht de gekozen methode.

Dit artikel is verschenen op Managementimpact.nl

Joep de Leeuw
Projectmanager