Dit is de tweede aflevering van een reeks waarin Koen, Armand en Cris de twaalf principes van het Agile Manifesto onder de loep nemen. Het Manifesto is inmiddels vijfentwintig jaar oud, en in die tijd is Agile uitgegroeid van een rebelse beweging tot de standaard in softwareontwikkeling. Tegelijk horen we steeds vaker de vraag of Agile eigenlijk niet gewoon dood is. In teams, op conferenties, op Reddit: de hype is eraf. Wij willen de principes afstoffen en toetsen of ze nog stand houden in 2026. Wat is tijdloos? Wat verdient een update? Wat mag de prullenbak in?
Principe #2 van het Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
“Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Jouw processen benutten de verandering tot concurrentievoordeel van de klant.”
Op het eerste gezicht klinkt dit als een vrijbrief: wijzigingen mogen op elk moment binnenkomen, want we zijn toch agile. Daar begint het ongemak. De kerngedachte van principe #2 is in onze ogen juist, een organisatie die niet wendbaar is, redt het tegenwoordig niet meer. Wat principe #2 niet doet, is voorschrijven hoe je dat verwelkomen inricht.
Dat is bewust: de twaalf principes zijn op een hoog abstractieniveau geschreven, zodat elk bedrijf ermee uit de voeten kan. De invulling is aan jou. En precies daar wringt het; veel organisaties worstelen met die invulling. Dat verklaart een groot deel van de klaagzang die je rond Agile leest, en het verklaart waarom Lean en DevOps op precies dat punt verder zijn gegaan dan het Manifesto deed.
Waarom dit principe bestaat
Softwareteams werkten in 2001 in lange watervalprogramma’s met bevroren requirementsdocumenten. Projectteams van twintig mensen die maandenlang requirements opstelden tot een boekwerk met alle knopjes, kleuren en technische ontwerpen. Er werd vergaderd, afgestempeld en ingevroren. Pas een jaar later, bij de eerste release, hoorde de klant wat er gebouwd was. Dan volgde de onvermijdelijke reactie: dit hebben we eigenlijk helemaal niet meer nodig, want ons proces is ondertussen veranderd.
Dat is verspilling in de meest directe zin. Maanden werk dat niemand nog kon gebruiken, plus een testproces waarbij testers een jaar oude documentatie erbij moesten pakken om te toetsen of een feature correct gebouwd was. Maar vaak wist men niet eens meer wat er destijds precies bedoeld werd. Principe #2 is een antwoord op die patronen.
Het ongemak: verwelkom is vrijblijvend
De kerngedachte van principe #2 is in 2026 minstens zo actueel als in 2001. Armand wijst op de versnelling van de wereld: markten verschuiven sneller, en concurrenten zijn sneller in staat om zich aan te passen. Wat vandaag de norm is kan over een jaar achterhaald zijn. De coronaperiode heeft dat scherp laten zien. De organisaties die goed door die jaren kwamen, waren juist degenen die zich snel wisten aan te passen. Sommige kwamen er zelfs sterker uit dan ze ervoor waren, een verschijnsel dat Nassim Taleb anti-fragile noemt: systemen die niet alleen schokken overleven, maar er beter van worden. Wendbaarheid is geen luxe, het is een overlevingsstrategie geworden. Cris haalt een parallel uit de militaire wereld: speciale eenheden die te maken hebben met onconventionele oorlogsvoering, zijn ingericht op flexibiliteit en heldere communicatielijnen, juist zodat ze kunnen acteren op een veranderende situatie. In een turbulente markt geldt hetzelfde voor organisaties: degene die het snelst kan omschakelen, wint. Koen trekt daar de logische conclusie uit: voorspelbaarheid was lang de norm, wendbaarheid is dat nu.
Het ongemak zit in het woord verwelkom. Het zegt niet wanneer je iets mag weigeren, en het zegt niet onder welke voorwaarden je iets zou moeten verwelkomen. Dat creëert ruimte voor misbruik. “We zijn toch agile” is een veelgehoorde rechtvaardiging geworden om elke wijziging op elk moment door te voeren, ook halverwege een sprint, ook zonder herprioritering. Op Reddit lees je de klassieke voorbeelden: midden in een sprint krijgt een team te horen dat de scope wijzigt en dat er nog twee user stories bij komen. Dat heet dan verwelkomen van verandering, terwijl het in werkelijkheid het overrulen van het team is. Onder het mom van “Agile” wordt op deze manier doorgedrukt wat anders gewoon scope creep zou heten.Een veelgehoorde klacht op Reddit en HackerNews gaat precies over dit punt: principe #2 wordt door management gebruikt om scope te blijven uitbreiden, terwijl het team onder druk staat om te leveren.
Eén developer schrijft dat hij zijn laatste twee Agile-banen sneller heeft opgezegd dan de twee daarvoor: “The constant change was presented as empowerment. It was exhaustion.” Het patroon erachter is herkenbaar: stakeholderdrift met verzoeken die buiten de intake om binnenkomen, een sprintplanning die elke week voller wordt, niets dat echt afkomt. De ervaring is reëel, maar de diagnose klopt vaak ten dele. Wat hier misgaat, is dat één principe wordt opgepakt zonder de andere elf. Het Manifesto is een samenhangend geheel: continu tempo, vaste cadans, technische kwaliteit, reflectie, samenwerking met de business. Wie alleen “verwelkom verandering” toepast en de rest negeert, doet feitelijk geen Agile, en gebruikt principe #2 als excuus om engineers onder druk te zetten.
De architectuurlaag: laat wijzigen heeft een prijs
Een tweede klacht die je vaak terugziet, is dat het principe in 2001 is geschreven voor zelfstandige desktopapplicaties, niet voor moderne gedistribueerde systemen. In een microservicelandschap raakt een late requirement-change al snel meerdere teams: API-contracten moeten worden aangepast, databaseschema’s herzien, afhankelijke testsuites bijgewerkt. De claim die daaruit volgt, is dat het principe achterhaald is omdat de complexiteit te groot is geworden om er nog losjes “verwelkom verandering” over te zeggen.
Hier moeten we genuanceerd in zijn. De klacht heeft een reële kern: ja, in een gedistribueerd systeem kost een verkeerd geplande verandering meer dan in een monolithische desktopapplicatie uit 2001. Maar de claim dat principe #2 daarom achterhaald is, slaat over wat er in de tussenliggende vijfentwintig jaar gebouwd is om de kosten van late wijzigingen juist laag te houden. Trunk-based development, feature flags en blue-green deployments: dit zijn DevOps-praktijken die expliciet ontworpen zijn om flexibel met wijzigingen om te gaan. Wie klaagt dat principe #2 niet werkt in microservices, klaagt vaak in werkelijkheid dat zijn organisatie geen van die praktijken op orde heeft.
Daarmee is het architectuurpunt nog niet weg. Cris brengt het terug op een van de architectuurprincipes die je hoort na te streven: zorg dat je architectuur zelf flexibel is en kan meebewegen met verandering. Modulair opgezet, loosely coupled, met duidelijke team-API’s. De afgelopen tien jaar is duidelijk geworden dat architectuur evolueert, en een architect die dat niet inbouwt, maakt principe #2 onuitvoerbaar voor het team. Tegelijk is er een categorie beslissingen die je niet meer zomaar terugdraait: de keuze voor cloud of on-premise, de keuze voor een specifieke message bus, de keuze voor een datastructuur bij hoge performance-eisen. Die beslissingen vragen vooraf om zorgvuldig nadenken, op basis van duidelijk opgehaalde non-functionele requirements als performance, schaalbaarheid, beveiliging en flexibiliteit.
Dezelfde logica geldt voor disciplines die makkelijk pas later in beeld komen, zoals security en legal. DevOps schrijft expliciet voor om die vanaf de start mee te nemen, zodat ze niet als verrassing binnenkomen wanneer de architectuur al vast staat. Dit heet Shift Left.
Het patroon herhaalt zich. Principe #2 geeft geen richting over de architectuurlaag. Het zegt “verwelkom verandering” zonder te specificeren dat je daarvoor je systeem moet ontwerpen om veranderbaar te zijn. Dat ontwerp is geen vanzelfsprekendheid. Het is het resultaat van jaren technische discipline.
Meer weten?
We helpen je je bedrijfsvoering zo te organiseren dat je instaat bent om de verandering te omarmen Dit zorgt voor duurzame relaties en een organisatorische groei.
Strategie en uitvoering: de voorwaarden voor verwelkoming
Het Manifesto is in 2001 opgesteld door softwareontwikkelaars die het over hun eigen werk hadden. Late in development verwijst daar letterlijk naar het ontwikkelproces zelf, naar een team dat code aan het bouwen is. Op strategisch niveau is het verwelkomen van veranderende behoeftes minder van toepassing. Strategische keuzes hebben een tijdshorizon van jaren, en een merk dat elke maand van identiteit verandert verwart de klant. Of het verwelkomen op de werkvloer ook lukt, hangt af van hoe de organisatie haar lagen heeft ingericht. Wat er gebeurt zonder die inrichting ziet Koen in de zorg: een team heeft een kwartaalplan, maar de raad van bestuur kan op elk moment via verschillende kanalen nieuwe prioriteiten bij het team neerleggen, soms omdat de vertaling van strategie naar de werkvloer niet is ingericht en soms dwars door bestaande processen heen. Het team draait constant van koers, en wie het hardst roept bepaalt waar de prioriteit ligt.
Ten eerste is het belangrijk om te beseffen dat de lagen in een organisatie elk op hun eigen ritme draaien. Strategie beweegt over jaren. Op een dieper niveau wordt in kwartalen gewerkt aan de productrichting, de roadmap en de campagne van dit jaar. Op het uitvoerende detailniveau zit het ontwikkelteam dat in dagen en weken op signalen van de klant reageert. Als die lagen coherent zijn ingericht, kan elk niveau zelfstandig zijn werk doen op zijn eigen tijdschaal. Cris brengt Vodafone Ziggo in als voorbeeld waar dat zichtbaar is: het basisaanbod en de merknaam liggen jaren vast, terwijl de techniek erachter en het functionaliteitenaanbod meebewegen met wat klanten vragen. Koen herkent het patroon uit marketing: huisstijl, logo en merknaam blijven jaren staan omdat de klant daar zijn herkenning op bouwt, terwijl campagne, doelgroep en kanaal voortdurend opnieuw worden afgewogen. In beide gevallen reageert het team aan de uitvoeringskant op klantvragen die binnen de gegeven richting passen, zonder dat elke vraag bij de directie hoeft te eindigen. Principe #2 hoort thuis op de werkvloer.
Een tweede voorwaarde is mandaat: helder wie wijzigingen mag voorstellen, accepteren of afwijzen, en wie tussen strategie en team staat om dat mandaat te bewaken. In veel grote organisaties is dat niet uitgewerkt, en dan komen wijzigingen op het verkeerde niveau te liggen. Kleine kwesties belanden bij management omdat het team niet weet of het mag beslissen, terwijl koersvragen in het team blijven hangen omdat ze nergens anders worden opgepakt. Cris brengt Defensie in als voorbeeld waar het wel is geregeld: onder de term TechDevOps wordt software direct in het veld getoetst met de gebruikers erbij, en het team heeft voldoende mandaat om snel te schakelen op wat het ziet. Dat brengt ons bij Lean en DevOps, waar voor dit soort voorwaarden concrete handvatten zijn uitgewerkt.
Wat Lean en DevOps toevoegen aan het verwelkomen van veranderingen
Lean, DevOps en Agile delen hetzelfde einddoel: klantwaarde leveren in een omgeving die verandert. De drie zijn parallelle bewegingen met verschillende oorsprongen. Het Manifesto blijft op het punt van veranderende behoeftes bewust hoog-over; Lean en DevOps geven daar concrete invulling aan.
Lean filtert verandering op economische waarde. Bij elke wijziging luidt de Lean-vraag: is de waarde groter dan de kosten van een late wijziging, en groter dan de kosten van uitstel? Pas dan ga je verder. Het Manifesto laat dat economische filter open; Lean voegt het toe.
DevOps maakt verandering werkbaar via tooling en architectuur. Een geautomatiseerde delivery pipeline met unit-tests, integratietests, security-scans en stapsgewijze deployments zorgt dat code stabiel naar productie blijft gaan, hoe vaak en hoe laat er ook wordt gewijzigd. Trunk-based development voorkomt dat lang levende branches uit elkaar lopen, en feature flags maken het mogelijk om code in productie te zetten zonder dat de gebruiker er al iets van merkt. Met die technieken kan een team elke wijziging door de pipeline laten lopen en blijven schakelen op wat de klant signaleert.
Bij elkaar leveren Lean en DevOps de werkwijzen die het verwelkomen van veranderingen werkbaar maken: een economisch filter dat onderscheid maakt tussen wijzigingen die waarde toevoegen en wijzigingen die alleen kosten oproepen, en technieken die wijzigingen stabiel naar productie brengen. Wie principe #2 in de praktijk wil laten werken, kan niet om Lean en DevOps heen.
Ons oordeel: tijdloos, maar niet compleet
Onze conclusie is dat dit principe geen begrafenis verdient. Het wordt niet minder relevant, eerder meer. Een wereld die in een split second kan kantelen, vraagt organisaties die kunnen meebewegen, of dat nu door corona, geopolitiek, of een nieuwe AI-doorbraak komt.
De formulering van dit principe is breed en universeel, en dat is een kracht. Bijna elk bedrijf dat in een veranderende omgeving opereert, kan ermee uit de voeten.
Wat het principe niet doet, is invullen onder welke voorwaarden je verandering werkelijk welkom kunt heten. Op organisatorisch niveau, op architectuurniveau, op procesniveau. Die invulling is bewust aan de uitvoerder gelaten, waardoor het principe niet aan een tijd of een vakgebied gebonden raakt. Tegelijk laat het de uitvoerder zonder voorwaarden achter, en eindigt het in de praktijk soms als excuus: iedereen roept dat hij agile is en veranderende scope verwelkomt, terwijl het systeem er niet op is ingericht en het team de prijs betaalt. De andere agile-principes geven hier deels antwoord op (hoge technische kwaliteit en goed ontwerp versterken wendbaarheid), maar geen ervan zegt expliciet: investeer in de voorwaarden om verandering daadwerkelijk te kunnen ondersteunen. Lean en DevOps doen dat wel, ieder vanuit zijn eigen invalshoek, en in andere domeinen leveren andere disciplines vergelijkbare invulling.
Onze herformulering:
Verwelkom veranderende behoeftes en bouw de voorwaarden waaronder dat kan.
Het tweede deel van het origineel, over concurrentievoordeel, laten we los. Dat is een uitleg van het principe, geen principe op zich. En zelfs laat in het ontwikkelproces was een argument tegen waterval; in 2026 is die tegenstelling minder dringend. Dat laten we ook weg.
Dit was de tweede aflevering. Kan je niet wachten op aflevering 3? Laat het ons dan weten.
Meer weten?
We helpen je je bedrijfsvoering zo te organiseren dat je instaat bent om de verandering te omarmen Dit zorgt voor duurzame relaties en een organisatorische groei.
Dit artikel is inhoudelijk gebaseerd op onder andere:
- Uitgebreide discussie tussen Armand La Rose, Koen Paquay & Cris Cadinu
- agilemanifesto.org; de oorspronkelijke formulering van alle twaalf principes