Agile vs. watervalmethode - vergelijking en verschillen
Op het werk horen we voortdurend dat we ons in een VUCA-wereld bevinden en dat we ons moeten aanpassen aan onze steeds veranderende omgeving. Iedereen heeft het erover dat we ons in een transformatie naar wendbaarheid bevinden. Sommige mensen doorzien dit misschien niet meer en vragen zich af wat het eigenlijk betekent voor organisaties.
In tegenstelling tot de zogenaamde watervalmethode is agile van een heel ander kaliber. Wanneer je probeert te begrijpen wat de Agile vs. Watervalmethode is en welke wanneer beter geschikt is, is het goed mogelijk om in de war te raken.
Als je er net zo over denkt, kunnen we je misschien helpen, want hier leggen we uit wat agile vs. waterval betekent.
Watervalmodel
Onder het motto “oude bezems vegen goed” wordt in veel bedrijven de beproefde watervalmethode gebruikt. Dat is niet verwonderlijk en zeker niet altijd verkeerd, want het watervalmodel is de klassieker van projectmanagement en heeft in veel gevallen bewezen dat het effectief kan zijn.
Maar wat betekent Agile vs. Waterval eigenlijk concreet? Het watervalmodel is een lineair procesmodel waarbij de aanpak is georganiseerd in opeenvolgende projectfasen met concreet gedefinieerde begin- en eindpunten. Grofweg kun je het je als volgt voorstellen:
Voordat we dieper ingaan, een korte opmerking. Onlangs hadden we 11 internationale agile experts te gast in een webinar – over een vraag: Hoe schaal je agile methoden goed op?
Het resultaat is deze fantastische video-opname (Engels), waarin bijvoorbeeld de volgende vragen aan bod komen:
- Is het beter om bottom-up of top-down te beginnen?
- Hoe krijg je leiders op één lijn over een gemeenschappelijke visie?
- Hoe kies je het juiste agile framework – en waarom is dat eigenlijk niet zo belangrijk?
Mijn warmste aanbeveling: neem een kijkje! Het duurt relatief lang, maar het is elke minuut waard.
Laten we het geheel eens bekijken met een eenvoudig voorbeeld:
In de definitiefase wordt eerst bepaald wat er eigenlijk gemaakt moet worden. De klant geeft bijvoorbeeld een wens aan: hij wil een tafel. Vervolgens analyseer en definieer je de eisen en maak je een plan van wat er allemaal moet gebeuren. In het ontwerp maak je dan een productontwerp, in ons voorbeeld een schets van de tafel.
Bij de implementatiefase wordt het geheel concreter: we selecteren materiaal, bepalen de exacte afmetingen en bouwen de tafel. Tijdens de controle controleren we of alles werkt zoals we het gepland hebben: Staat de tafel? Kloppen de verhoudingen? De Evaluatie vindt dan plaats samen met de klant: we leveren het product en ontvangen feedback.
Dus waarom zou je iets veranderen als het gezegde luidt: verander nooit een lopend systeem.
Agile (iteratieve) vs. waterval (lineaire) methodologie
Hoewel het watervalmodel zeker goede kanten heeft en in veel situaties effectief is, zouden bedrijven zich moeten inzetten om wendbaarder te worden. Waarom? Omdat de wereld waarin we allemaal opereren steeds meer complexe en tegenstrijdige eisen aan ons stelt en we het vaak moeilijk vinden om daarop te reageren met watervaldenken.
De watervalmethode heeft een aantal gevaren. Hoewel we een groot gevoel van veiligheid hebben door planning en structuur, zijn we ook erg gebonden aan onze processen. Het werkproces is nogal statisch en door de exacte planning hebben we maar een heel klein beetje flexibele speelruimte. En dat is precies wat we nodig hebben in onze dynamische omgeving. Dit is waar wendbaarheid om de hoek komt kijken. Laten we eens kijken naar de agile vs. watervalmethode.
Maar wat is eigenlijk de definitie van agile? Volgens de Duden agile is zoiets als “Getuigt van behendigheid; bruusk en lichtvoetig” en deze definitie vertaalt zich goed naar de wereld van het werk.
Wendbaarheid in bedrijven betekent in staat zijn om strategieën, structuren en processen iteratief aan te passen aan de actuele, huidige omstandigheden. Dit is essentieel omdat we geconfronteerd worden met complexe veranderingen als gevolg van digitalisering en demografische veranderingen en ons dus moeten kunnen blijven aanpassen.
Trouwens, een korte opmerking in de context van agile transformatie: Wil je er zeker van zijn dat jullie momenteel de juiste prioriteiten stellen in jullie agile transformatie?
Doe dan onze volwassenheidscheck voor jullie agile transformatie - duurt slechts 3 minuten. Je krijgt zelfs een benchmark op basis van de meer dan driehonderd andere deelnemers. Zie button 🙂
Een tafel bouwen met agile methoden
Laten we bij hetzelfde voorbeeld blijven: de klant wil een tafel. We beginnen dus met het maken van een schets. Die laat ik aan de klant zien en hij beslist dan of hij het zich zo heeft voorgesteld of niet. Zo niet, dan wordt de schets opnieuw aangepast. Zodra de schets af is, kies ik het materiaal en vraag ik de klant iteratief of alles naar wens is.
Misschien zegt de klant dan: “Oh nee, ik denk dat ik liever grenen wil in plaats van kersen”. Het is dus toch een andere houtsoort: dus maken we een nieuwe selectie. Daarna wordt de tafel in elkaar gezet en ook hier wordt regelmatig met de klant overlegd en worden er zo nodig wijzigingen aangebracht.
Dat kun je zien: Met de agile methodologie kunnen we flexibel reageren op veranderende eisen, wat relevant is in de complexe omgeving.
Daarom is de statische aard van de watervalmethode niet altijd voldoende. Bovendien kan het gebeuren dat fouten in de implementatie pas tijdens de evaluatie aan het licht komen door de rigide opvatting in het watervalmodel. Dit zou leiden tot aanzienlijk hogere correctiekosten dan een flexibele aanpassing.
"Veel teamleden durven zich niet uit te spreken!"
Los deze uitdaging op
"We ontdekken te veel onverwachte problemen en bugs in een laat stadium!"
Los deze uitdaging op
"Waarom kost het me soms uren om een eenvoudige terugblik voor te bereiden?"
Los deze uitdaging opAgile vs. watervalmethoden op het werk
Het is vaak nog moeilijk om agile en iteratieve processen in bedrijven te ontwerpen. Dit komt doordat mensen van nature risicomijdend zijn en soms al tientallen jaren in hun professionele context gesocialiseerd zijn met een denkpatroon dat gevormd wordt door watervallen.
Risicoaversie verwijst hier naar de neiging om in beslissingssituaties de mogelijkheid te kiezen die het minste risico - dus het minste verlies - met betrekking tot het resultaat met zich meebrengt. (vgl. Kahneman & Tversky, 1979)
Agile vs. watervalmethoden vereisen van ons dat we deze vermeende zekerheid opgeven: in plaats van terug te vallen op beproefde methoden en vaste structuren en principes te gebruiken, worden oude denkpatronen van de planningsillusie doorbroken en worden iteratieve methoden gebruikt. Dit leidt in eerste instantie tot een gevoel van toegenomen onzekerheid, omdat je nieuwe - schijnbaar risicovolle - benaderingen moet toepassen die onzekerheid interpreteren als onderdeel van het plan.
Plannen voor deze onzekerheid leidt tot de nodige flexibiliteit op de lange termijn. We ontwikkelen een reeks opties voor actie, wat op zijn beurt de veiligheid in de VUCA-werkwereld stabiliseert.
Dynamiek en stabiliteit in balans houden
De agile methodologie - evenals de watervalmethodologie - omvat bepaalde nadelen:
- Agile methoden maken planningsonzekerheden zichtbaar en houden er rekening mee, zodat plannen meer ruimte moeten bieden voor nieuwe inzichten
- Het concrete resultaat is moeilijker in te schatten, omdat nieuwe bevindingen kunnen leiden tot afwijkingen van het oorspronkelijke geplande resultaat.
- Om de hierboven genoemde redenen lijken successen minder berekenbaar in tegenstelling tot het klassieke watervalproject.
Vanzelfsprekend zijn, afhankelijk van het project, verschillende benaderingen meer of minder geschikt.
Het watervalmodel is vooral geschikt voor projecten die al van tevoren bekende en constante eisen bevatten.
Agile methoden zijn vooral optimaal voor projecten waarin veel onvoorspelbare factoren kunnen optreden en daarom flexibele reflectielussen nodig zijn. In de meeste technologische projecten is zo’n onzekerheid onvermijdelijk, waardoor juist hier agile methoden sterk in opkomst zijn.
Tussen haakjes: Als je specifiek een agile mentaliteit in je team of bedrijf wilt eisen, is het de moeite waard om eens te kijken naar ons artikel over de verbazingwekkende waarheid achter de agile mindset .
Agile vs. watervalmethode of combinatie?
Bij alle hype rond “agile” kan men soms geneigd zijn om agile methoden als wondermiddel te zien. Ten onrechte. Het misschien verrassende resultaat van deze tekst is duidelijk.
Het blijkt dat het gebruik van van beide methodologieën gecombineerd leidt efficiënt naar het doel (Herrmann, 2007). Dergelijke combinaties zijn nuttig in situaties waarin het watervalmodel vereist is, maar dit niet past bij de complexiteit van het project.
Een soort middenweg van beide methoden is de zogenaamde Feature gedreven ontwikkeling (FDD).
Op FDD ontwikkelt men weliswaar - net als bij de watervalmethodiek - een concreet, langetermijnplan met afzonderlijke, vastgelegde sequenties: de features. De afzonderlijke features zijn echter erg kort, waardoor kortetermijnreacties op veranderende eisen mogelijk zijn. De aanpak is weliswaar niet zo iteratief als agile methoden, maar vormt eventueel een passende middenweg.
En zo komen we tot het eerder verrassende resultaat: Het hoeft niet altijd Agile vs. Watervalmethode te zijn. De beide methoden kunnen elkaar ook prima aanvullen. Beide hebben hun bestaansrecht. Afhankelijk van project en context.
Maar omdat agile methoden voor velen nog onbekend terrein zijn, vragen ze zich terecht af hoe ze agile methoden zouden kunnen uitproberen.
Weet je niet zeker hoe je moet beginnen?
Voor velen is “agile” nog onbekend terrein. Ze stellen zich terecht de vraag: Doe ik het project liever agile of volgens het watervalmodel? Hoe zou ik beginnen met agile methoden? Een “agile” antwoord hierop zou zijn: Start experimenten. Probeer iteratief verschillende dingen uit.
Klassiek worden agile methoden via twee wegen ingevoerd, die zich ook uitstekend lenen voor “beginners”: Kanban en retrospectieven.
Kanban en retrospectives als klassiek startpunt
Kanban maakt gebruik van een publiek zichtbaar (Kanban-)bord waarop elk teamlid zijn huidige activiteiten inzichtelijk maakt. Dit bevordert de communicatie, efficiëntie en uiteindelijk het succes van het project. Je kunt meer informatie vinden over Kanban hier.
Het basisidee achter retrospectives is om als team regelmatig actief op elkaar te reflecteren. Meestal ga je om de twee weken bij elkaar zitten in een retrospectieve vergadering en stel je vragen als: Wat gaat er op dit moment goed? Wat gaat er niet zo goed? En welke maatregelen kunnen we nemen om dingen beter te maken?
Als jullie erover nadenken om agile methoden in te voeren…
Als je nog op zoek bent naar een geschikt retro bord, kan ons artikel je helpen met het onderwerp: De beste retro boards in vergelijking.
Bronnen
Richard H. Thaler, Amos Tversky, Daniel Kahneman, Alan Schwartz, The Effect of Myopia and Loss Aversion on Risk Taking: An Experimental Test, Het Kwartaaltijdschrift voor Economie, Volume 112, Issue 2, Mei 1997, Pagina’s 647–661, https://doi.org/10.1162/003355397555226
Herrmann, A. (2007). Feature Driven Development tussen waterval en flexibiliteit.
