Een gemeente die een nieuwe brug laat bouwen, wil vooraf precies weten wat die kost, hoe hij eruitziet en wanneer hij klaar is. Een webwinkel die een nieuwe app ontwikkelt, weet vaak pas na de eerste reacties van klanten wat die app eigenlijk moet kunnen. Beide organisaties voeren een project uit, maar ze hebben een totaal andere aanpak nodig. Daar draait de keuze tussen de watervalmethode en Agile om: niet welke methode beter is, maar welke past bij het soort werk en de organisatie.
In dit vergelijkende stuk zetten we de twee benaderingen naast elkaar, met hun herkomst, hun sterke en zwakke kanten en de vragen die helpen bij een verstandige keuze.
De watervalmethode: eerst ontwerpen, dan bouwen
Bij de watervalmethode doorloopt een project een vaste reeks fasen, zoals eisen vastleggen, ontwerpen, bouwen, testen en opleveren. Een fase begint pas als de vorige is afgerond en goedgekeurd. Het werk stroomt als het ware van boven naar beneden, vandaar de naam.
De methode wordt vaak toegeschreven aan Winston Royce, die er in 1970 een artikel over schreef in de context van software-ontwikkeling. Opvallend is dat Royce de zuiver opeenvolgende aanpak juist riskant noemde en voorstelde om het proces minstens twee keer te doorlopen. Het woord ‘waterval’ gebruikte hij zelf niet. De strakke variant die later bekend werd, is dus eerder een vereenvoudiging van zijn ideeën dan een letterlijke weergave.
De kracht van de watervalmethode zit in voorspelbaarheid. Omdat de eisen vooraf vastliggen, kun je budget, planning en capaciteit goed inschatten. Een Gantt-chart maakt de volgorde en afhankelijkheden van taken overzichtelijk. Voor opdrachtgevers die vaste afspraken nodig hebben, zoals overheden of partijen in een aanbesteding, is dat een groot voordeel. Ook methoden als Prince2 werken met duidelijke fasen en beslismomenten, al is Prince2 zelf breder inzetbaar.
Het nadeel is dat je pas laat ziet of het resultaat werkt. Blijkt tijdens het testen dat een eis verkeerd is begrepen, dan moet je terug naar een eerdere fase. Dat kost tijd en geld, en hoe later de fout aan het licht komt, hoe duurder hij wordt.
Agile: in korte stappen leren wat werkt
Agile is geen afzonderlijke methode, maar een verzameling uitgangspunten. Die werden in februari 2001 vastgelegd in het Agile Manifesto, opgesteld door zeventien softwareontwikkelaars die bijeenkwamen in het Amerikaanse Snowbird, zo staat in de geschiedenis van het manifest. Ze verkozen onder meer werkende software boven uitgebreide documentatie, samenwerking met de klant boven contractonderhandelingen en inspelen op verandering boven het volgen van een plan.
In de praktijk betekent Agile dat een team in korte cycli werkt, vaak van twee tot vier weken. Elke cyclus levert iets bruikbaars op dat de opdrachtgever of gebruiker kan beoordelen. Op basis van die feedback bepaalt het team wat er daarna gebeurt. Scrum is de bekendste uitwerking van dit gedachtegoed, met vaste rollen zoals product owner en scrum master en vaste momenten om terug te kijken en bij te sturen.
Het grote voordeel is dat je vroeg ontdekt of je de goede kant op gaat. Wie eerst een minimum viable product uitbrengt, leert sneller wat klanten echt willen dan wie maanden aan een compleet ontwerp werkt. De keerzijde is dat het eindresultaat bij de start minder vastligt. Voor een opdrachtgever die een vaste prijs en een vaste opleverdatum wil, kan dat ongemakkelijk zijn. Agile vraagt bovendien veel van de organisatie: teams die zelf beslissingen mogen nemen, een opdrachtgever die regelmatig beschikbaar is en leidinggevenden die minder op detailplanning sturen.
De belangrijkste verschillen op een rij
De twee benaderingen verschillen op een paar wezenlijke punten. Bij de watervalmethode staat de omvang van het werk vast en zijn tijd en geld daarvan afgeleid. Bij Agile liggen tijd en budget per cyclus vaak vast en is de inhoud flexibel. Waterval stuurt op het plan, Agile op de feedback van gebruikers. Bij waterval ziet de opdrachtgever het resultaat vooral aan het eind, bij Agile na elke cyclus.
Ook de rol van documentatie verschilt. In een watervalproject is een uitgebreide beschrijving van eisen en ontwerp het fundament van het werk. In een Agile project is documentatie ondersteunend en wordt kennis meer gedeeld via direct overleg en werkende tussenproducten. Dat is geen kwestie van goed of fout. Wie een vliegtuig bouwt of een ziekenhuis inricht, heeft simpelweg meer vastgelegde specificaties nodig dan wie een marketingcampagne test.
Welke aanpak past bij jouw organisatie?
De keuze hangt minder af van de mode van het moment dan van een paar nuchtere vragen over het project en de omgeving waarin het wordt uitgevoerd.
Hoe zeker zijn de eisen?
Weet je vooraf precies wat er moet komen en verandert dat waarschijnlijk niet, dan werkt een fasegewijze aanpak goed. Denk aan de verhuizing van een kantoor, de invoering van een wettelijk verplicht systeem of een bouwproject. Zijn de wensen van gebruikers onzeker of veranderlijk, zoals bij een nieuw digitaal product, dan helpt Agile om onderweg bij te sturen.
Wat kost een late verandering?
In software kun je een functie relatief eenvoudig aanpassen. Een fundering die al gestort is, verplaats je niet zomaar. Hoe duurder het is om later van koers te veranderen, hoe belangrijker een grondig ontwerp vooraf wordt.
Hoe ziet de organisatie eruit?
Agile werkt het best in een organisatie waar teams ruimte krijgen om zelf te beslissen en waar fouten maken in een vroeg stadium geaccepteerd is. In een sterk hiërarchische organisatie met veel goedkeuringsrondes loopt een Agile team al snel vast. Het 7S-model laat zien waarom: een nieuwe werkwijze slaagt alleen als structuur, systemen, stijl van leidinggeven en cultuur meebewegen. Een Agile team invoeren zonder de rest van de organisatie aan te passen, levert vaak een watervalproject met dagelijkse overleggen op.
Wat verwachten de stakeholders?
Kijk ook goed naar de stakeholders. Een raad van bestuur of een externe opdrachtgever die vaste toezeggingen over budget en datum wil, past minder goed bij een open Agile traject. Het kan dan helpen om vooraf duidelijke afspraken te maken over wat er per cyclus wordt opgeleverd en hoe vaak de opdrachtgever meekijkt.
Combineren is vaak realistischer
In de praktijk kiezen veel organisaties niet strikt voor de ene of de andere aanpak. Ze werken met een hybride vorm. Een programma kan op hoofdlijnen fasegewijs worden gepland, met vaste beslismomenten voor budget en scope, terwijl de teams binnen die fasen in korte cycli werken. Bij een nieuw klantportaal kan de technische infrastructuur bijvoorbeeld volgens een vast plan worden aangelegd, terwijl de schermen en functies stap voor stap met gebruikers worden ontwikkeld.
Zo’n combinatie vraagt wel om duidelijkheid. Iedereen moet weten welke onderdelen vastliggen en waar ruimte is voor verandering. Zonder die afspraken ontstaat het slechtste van twee werelden: de rigiditeit van waterval zonder de voorspelbaarheid, en de onzekerheid van Agile zonder de snelle feedback. Meer over de basisprincipes van het vak lees je op de pagina over projectmanagement.
Conclusie
De watervalmethode en Agile zijn geen concurrenten waarvan er één de winnaar moet zijn. Waterval past bij projecten met duidelijke, stabiele eisen en hoge kosten voor late wijzigingen. Agile past bij projecten waarin je onderweg moet ontdekken wat werkt en waarin snelle feedback van gebruikers mogelijk is. Welke aanpak het beste werkt, hangt ook af van de cultuur, de besluitvorming en de verwachtingen van opdrachtgevers.
Wie een projectaanpak kiest, doet er goed aan eerst te kijken naar het werk zelf: hoe zeker zijn de eisen, wat kost een koerswijziging en hoeveel ruimte krijgen teams? Het antwoord op die vragen wijst meestal vanzelf de richting, en komt niet zelden neer op een verstandige combinatie van beide.
