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 proceduremodel waarin de procedure 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 definitiefasewordt eerst bepaald wat er gecreëerd moet worden. De klant geeft bijvoorbeeld een wens aan: Hij wil een tabel. Vervolgens worden de eisen geanalyseerd en gedefinieerd en wordt er een plan opgesteld voor alles wat er moet gebeuren. Daarin wordt dan een productontwerp gemaakt, in ons voorbeeld een schets van de tafel.
In de implementatiefasewordt het geheel tastbaarder: we kiezen materiaal, bepalen de exacte afmetingen en bouwen de tafel. In de controlefase controleren we of alles werkt zoals we gepland hadden: Staat de tafel? Kloppen de verhoudingen? De evaluatie vindt dan samen met de klant plaats: We overhandigen het product en krijgen 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 ervoor zorgen dat je op dit moment de juiste prioriteiten in je agile Transformatie?
Doe dan onze volwassenheidstest voor je agile transformatie – duurt slechts 3 minuten. Je krijgt zelfs een benchmark op basis van meer dan driehonderd andere deelnemers. Zie knop 🙂
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.
De meeste Agile Coaches gaan rond in cirkels....
...en oppervlakkige symptomen behandelen. Het is tijd om psychologie – te gebruiken voor een duurzame mentaliteitsverandering.
Agile 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 besluitvormingssituaties de optie te kiezen die gepaard gaat met het minste risico –, d.w.z. het minste verlies – met betrekking tot de uitkomst. (vgl. Kahneman & Tversky, 1979)
Agile vs. watervalmethoden vereisen dat we deze vermeende veiligheid 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 waargenomen toename van onzekerheid, omdat je nieuwe – schijnbaar riskante – procedures 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
Zowel de agile methodiek – als de waterval methodiek – bevat 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 van tevoren al bekende en constante eisen bevatten. .
Agile methoden zijn met name optimaal voor projecten waarinveel onvoorspelbare factorenkunnen optreden en flexibele reflectielussen daarom noodzakelijk zijn. In de meeste technologische projecten is een dergelijke onzekerheid onvermijdelijk en daarom zijn agile methoden juist hier in opkomst.
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?
Met alle hype over "agile" kun je soms geneigd zijn om agile methoden als een 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 Net als bij de watervalmethode wordt er een concreet langetermijnplan ontwikkeld met individuele, vaste reeksen: de features. De individuele features zijn echter erg kort, waardoor er op korte termijn gereageerd kan worden op veranderende eisen. De aanpak is niet zo iteratief als agile methoden, maar vormt waar nodig een geschikte middenweg.
En zo komen we tot de nogal verbijsterende conclusie: Het hoeft niet altijd Agile te zijn vs. Watervalmethode. De twee methoden kunnen elkaar ook aanvullen. Beide hebben hun rechtvaardiging. Afhankelijk van het project en de 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 "wendbaarheid" nog onbekend terrein. Ze vragen zich terecht af: Doe ik het project liever agile of volgens waterval? Hoe zou ik beginnen met agile methoden? Een "agile" antwoord hierop zou zijn: Begin met experimenten. Probeer iteratief verschillende dingen uit.
Klassiek worden agile methoden geïntroduceerd op twee manieren die ook ideaal zijn voor "beginners": Kanban en retrospectives.
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 je erover denkt om agile methoden te introduceren...
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.
https://www.pinuts.de/blog/webstrategie/projektmanagement-wasserfall-gegen-scrum
