Dit is de eerste aflevering van een reeks waarin Koen, Armand en Cris de twaalf principes van het Agile Manifesto onder de loep nemen. Het Manifesto is inmiddels 25 jaar oud. In die tijd is Agile uitgegroeid van een rebelse beweging tot de standaard in softwareontwikkeling, maar tegelijk horen we steeds vaker de vraag: is Agile eigenlijk dood? In teams, op conferenties, op Reddit. De hype is eraf. Wij willen de principes afstoffen en toetsen: houden ze nog stand in 2026? Wat is tijdloos, wat verdient een update, en wat mag de prullenbak in?
We beginnen bij het begin. Principe #1 van het Agile Manifesto, geformuleerd in 2001:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.”
Klinkt logisch, bijna vanzelfsprekend. Maar zodra je het principe goed bekijkt, zitten er een paar aannames in die de moeite waard zijn om uit te pluizen.
Waarom bestond dit manifesto überhaupt?
Om het principe te begrijpen, moet je terug naar de context van 2001. Softwareteams werkten toen in lange watervalprogramma’s: dikke requirementsdocumenten, maandenlange planningen, uitgebreide specificaties die werden bevroren, afgestempeld en vervolgens uitgevoerd. De klant kreeg pas na maanden, soms zelfs langer dan een jaar, iets te zien, en dat was dan zelden wat hij had bedoeld. In de tussentijd was de wereld verder gegaan: de markt was verschoven, de concurrentie had niet stilgezeten, en wat ooit een relevante klantvraag was, bleek achterhaald.
Naast dat systeemprobleem speelde er ook iets cultureels. Managers deelden taken uit, verwachtten overuren en behandelden developers als uitvoerende krachten. De zeventien ontwikkelaars die in 2001 het Manifesto opstelden, onder wie grondleggers van Extreme Programming, Scrum en Crystal zoals Kent Beck, Martin Fowler en Ken Schwaber, waren het zat. Ze wilden op een humaan, continu tempo doorwerken zonder dat het systeem over ze heen rolde.
Vanuit die context ontstond het Manifesto, en principe #1 weerspiegelt een van de kerngedachten: lever vroeg, lever vaak, en zorg dat het waarde heeft voor de klant.
De eerste frictie: software eruit
Het woord dat ons direct opviel? Software.
Het principe is geschreven vanuit en voor softwareontwikkeling, en dat is logisch: het Manifesto kwam voort uit de frustraties van softwareteams. Maar wie vandaag met Agile werkt, zit lang niet altijd in de software. Steeds meer teams in marketing, recruitment en operations gebruiken dezelfde principes. Er zullen lezers zijn die zeggen dat je het Manifesto niet moet lostrekken van die oorspronkelijke context.
Toch nemen we hier stelling. De onderliggende gedachte van dit principe is breder toepasbaar dan op software alleen. Overal waar je te maken hebt met complexiteit, waar je de mogelijkheid hebt om regelmatig op te leveren en waar een klant baat heeft bij vroege feedback, gaat dezelfde logica op.
Een concreet voorbeeld uit Koens praktijk. Een recruitmentteam dat al meer dan een jaar worstelt met verbeteringen die ze nooit oppakken, omdat structureel tijd maken voor verbeteringen altijd het onderspit delft tegen de waan van de dag. Een tweewekelijkse sprint van twee uur geeft hen gestructureerde ruimte om stap voor stap vooruit te komen. Na elke sprint leveren ze iets op, al is het een verbeterde werkwijze, een nieuw sjabloon of een helder besluit. Het effect op energie en eigenaarschap is vergelijkbaar met dat van een softwareteam dat ziet dat gebruikers blij zijn met wat ze hebben gebouwd: je merkt dat wat je maakt ertoe doet, en dat motiveert om door te gaan.
Koen ziet hetzelfde in marketing. Je bouwt een prototype van een campagne-uiting, toetst die bij je doelgroep, haalt data op en itereert. Door de klant te betrekken in de co-creatie van je product verkort je de feedbackloop en vergroot je de kans dat wat je oplevert aansluit bij een werkelijke behoefte. Dat is dit principe toegepast buiten software.
We zouden het dan ook als volgt willen herformuleren:
“Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle producten, diensten of uitkomsten.”
Er zijn grenzen aan die brede toepasbaarheid. In sterk gereguleerde omgevingen, denk aan farmaceutische productontwikkeling, zijn lange kwaliteitscycli onvermijdelijk. Het principe gaat dan ook niet over alles sneller doen, maar over het verkorten van de feedbackloop met je klant, binnen de kaders die je context toelaat.
De klant bestaat niet, of wel?
Een veel gehoorde klacht op forums als Reddit en HackerNews: “De klant bestaat niet.” En daar zit iets in. In de praktijk heb je zelden één duidelijke klant.
- Je hebt degene die betaalt, vaak het management;
- Je hebt de gebruiker, een afdeling of eindklant;
- Je hebt stakeholders met eigen belangen, en soms een Product Owner die als tussenpersoon optreedt.
Die partijen hebben lang niet altijd hetzelfde voor ogen, en toch gaan teams er stilzwijgend vanuit dat “de klant” één ding wil, één stem heeft en één richting aangeeft.
Wat wij in de praktijk zien is dat de belangen van stakeholders regelmatig niet op elkaar zijn afgestemd. Marketing wil op 30 maart een nieuwe campagne lanceren, terwijl het ontwikkelteam daar nog lang niet klaar voor is. Niemand heeft dat met elkaar afgestemd. Het probleem is dus niet dat de klant niet bestaat. Het probleem is dat er meerdere stakeholders zijn met uiteenlopende belangen, en dat niemand die bij elkaar brengt.
In Scrum heeft de Product Owner hier een belangrijke rol. De PO is verantwoordelijk voor het maximaliseren van de waarde van het product, wat betekent dat hij stakeholders actief betrekt, hun belangen vertaalt naar prioriteit en daarbinnen keuzes durft te maken. Een goede PO schakelt met het team, vraagt feedback van de architect of lead developer, en durft terug te gaan naar de business met de boodschap: dit is nu niet realistisch.
Tegelijk is klanttevredenheid geen exclusieve PO-verantwoordelijkheid. Cris maakte het punt dat er niet per se een Product Owner hoeft te zijn. In kleinere teams, of in R&D-omgevingen, kan het team direct met de eindgebruiker schakelen. Bij Defensie zat zijn team in de loodsen naast de militairen die de voertuigen gebruikten, en bij TNO werkten ze zij aan zij met de wetenschappers. Er was geen Product Owner, wel directe feedback. Wat telt is dat iemand de interactie met de klant onderhoudt en dat de inzichten terugvloeien naar het team.
Dat brengt ons bij de sprint review. Die is pas waardevol als er echte stakeholders aan tafel zitten: de mensen die daadwerkelijk iets met het opgeleverde werk gaan doen, niet alleen de manager die wil zien dat het team productief is geweest.
Staat bij jou de klant ook op nummer #1?
Meer weten?
We helpen je je bedrijfsvoering zo te organiseren dat je de klant of je stakeholders de beste waarde levert. Dit zorgt voor duurzame relaties en een organisatorische groei.
Geven wat de klant wil, of wat hij nodig heeft?
De vorige secties gingen over wie de klant is en hoe je de feedbackloop met de klant organiseert. Maar er zit nog een diepere spanning in het principe, en die draait om het woord satisfy.
Satisfy klinkt passief. Je doet wat de klant vraagt, de klant zegt “prima”, en iedereen gaat door. Maar tevredenheid op het moment van oplevering is niet hetzelfde als waarde op de lange termijn. Een klant kan tevreden zijn met een feature die zijn directe vraag beantwoordt, terwijl het onderliggende probleem onopgelost blijft. Of een team levert keurig op wat gevraagd is, zonder dat iemand heeft getoetst of die vraag de juiste was.
Het verschil zit in de bereidheid om verder te kijken dan de letterlijke klantvraag. Dat betekent soms nee zeggen, of op z’n minst doorvragen: wat is de reden dat je dit vraagt, wat probeer je op te lossen, en kunnen we dat anders aanpakken?
Cris gaf een voorbeeld uit zijn tijd als engineer bij Defensie. Zijn team bouwde software voor de aansturing van autonome voertuigen, en ze werkten niet vanachter een bureau op basis van requirementsdocumenten. Ze zaten in de loodsen waar militairen aan de voertuigen sleutelden en de software in de praktijk gebruikten. Bij Eurofins ging het team letterlijk naar de boeren toe om zelf monsters te nemen op het veld, zodat ze begrepen hoe de app die ze bouwden daadwerkelijk werd gebruikt.
In Lean-kringen heet dit getting out of the building: je kantoor verlaten en met eigen ogen zien hoe je product wordt gebruikt. Het is een van de meest onderschatte gewoonten in productontwikkeling, omdat het je iets oplevert dat geen user story of requirementsdocument kan vangen. Je ziet workarounds die de gebruiker zelf niet als probleem rapporteert, omdat hij ze normaal is gaan vinden. Pas als je naast iemand staat terwijl hij je software gebruikt, zie je waar het wringt. Die directe ervaring maakt dat je als team beter begrijpt wat het product doet en hoe het wordt gebruikt. En daardoor sta je steviger in je schoenen als je een keer tegen een klantvraag in moet gaan, omdat je vanuit eigen waarneming weet dat er een betere oplossing is.
De DevOps-invalshoek: kwaliteit als proxy voor klanttevredenheid
Tot nu toe ging dit artikel over de vraag wie de klant is en wat hij nodig heeft. Cris bracht vanuit zijn DevOps-achtergrond een aanvullend perspectief in: binnen DevOps draait het gesprek over klantwaarde niet zozeer om de vraag “bouwen we het juiste?” Die vraag hoort thuis aan de productkant, bij het team en de Product Owner. DevOps focust op een andere as: de kwaliteit van het voortbrengingsproces. Hoe snel kun je een wijziging in productie brengen, hoe stabiel draait het daar, en hoe snel herstel je als er iets misgaat?
Die focus komt niet uit het niets. DevOps is sterk geworteld in Lean-denken, en begint altijd bij de klant: wie is je klant, wat verwacht die, en aan welke criteria meet je of je daaraan voldoet? In Lean-termen heet dat de Critical to Quality. DevOps neemt dat uitgangspunt over en vertaalt het naar de technische implementatie. Hoe goed dat lukt, is meetbaar. Het DORA-onderzoeksprogramma hanteert vijf kernmetrics die de prestaties van een delivery pipeline in kaart brengen: hoe snel je kunt deployen, hoe kort de doorlooptijd van een wijziging is, hoe snel je herstelt na een incident, hoe vaak een deployment tot problemen leidt, en hoe betrouwbaar je systeem als geheel draait. Die metrics zijn geen doel op zich. Ze vertellen je hoe goed je voortbrengingsproces functioneert ten dienste van je klant.
Concreet: DevOps kijkt niet naar de vraag of de kleuren op je website kloppen, maar wel naar de vraag of die website blijft draaien als er 20.000 gebruikers tegelijk op komen. Of naar hoe lang een klant last heeft van een storing: een uur, of een dag?
Het lijkt een andere insteek dan Agile/Scrum, maar het einddoel is hetzelfde. Agile stelt de vraag: bouwen we wat de klant nodig heeft, en doen we dat in korte cycli zodat we kunnen bijsturen? DevOps stelt de vraag: komt wat we bouwen snel, stabiel en betrouwbaar bij die klant terecht? De ene richt zich op de wat-vraag en de feedbackloop met de klant, de andere op het hoe van het voortbrengingsproces.
En waar zit Lean in dit plaatje? Lean en Scrum worden soms tegenover elkaar gezet, maar in de praktijk vullen ze elkaar aan. Scrum is empirisch: je werkt in korte cycli omdat je van tevoren niet kunt voorspellen wat het juiste antwoord is, waardoor elke sprint in feite een experiment is. Lean werkt vanuit een stabieler proces en richt zich op het elimineren van verspilling in de waardestroom. Kanban, dat onder de Lean-vlag valt, is een pull-systeem dat goed werkt voor continu, voorspelbaar werk. De keuze tussen Scrum en Kanban hangt af van de complexiteit van je situatie: hoeveel weet je al, en hoe voorspelbaar is wat je moet opleveren?
Het zijn drie perspectieven op dezelfde ambitie: waarde leveren aan je klant. Agile via de samenwerking en het kortcyclisch ontdekken wat de klant nodig heeft. DevOps via de technische kwaliteit van het oplevermechanisme. Lean via het optimaliseren van de waardestroom. In de praktijk bestaan ze naast elkaar, en veel teams combineren elementen uit alle drie.
Ons oordeel: herschrijven
Tijdloos? Verouderd? Klaar voor de prullenbak?
Het principe verdient een herformulering, geen begrafenis.
De kern is in 2026 minstens zo relevant als in 2001. Communicatieproblemen tussen business en ontwikkelteams zijn niet verdwenen, stakeholders worden nog steeds te laat betrokken, en teams leveren nog steeds op wat gevraagd is in plaats van wat nodig is. Bij te veel organisaties is de feedback van de klant iets dat pas na oplevering binnenkomt, in plaats van iets dat het bouwproces stuurt.
Armand vatte het in de opname samen: of je nu in software zit, in marketing of in recruitment, het patroon is hetzelfde. Er is een klant met een behoefte, er is een team dat waarde probeert te leveren, en er is een feedbackloop die het verschil maakt tussen goed genoeg en daadwerkelijk waardevol.
De formulering heeft wel zijn tijd gehad. Software is te specifiek voor een gedachte die universeler blijkt dan de auteurs in 2001 voorzagen. En satisfy dekt niet de lading van wat een goed team doet: niet alleen leveren wat gevraagd wordt, maar doorvragen, adviseren en soms tegengas geven.
Onze (vernieuwde) versie:
“Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend creëren van waarde.”
Dit was de eerste aflevering. Volgende keer pakken we principe #2.
Staat bij jou de klant ook op nummer #1?
Meer weten?
We helpen je je bedrijfsvoering zo te organiseren dat je de klant of je stakeholders de beste waarde levert. 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
- Reddit; r/agile en r/programming threads over “de klant bestaat niet” en technische schuld
- HackerNews discussies over continuous delivery in enterprise-contexten
- Dev.to en LinkedIn over het leeglopen van het woord “waardevol”
- Robert C. Martin; zijn kritiek op technische schuld in snelleverende teams (te vinden in zijn boek Clean Agile, 2019)
- Steve Blank; de term komt uit zijn werk, vastgelegd in The Startup Owner’s Manual (2012) en zijn Stanford-colleges
- Henry Ford: “de bekende, zij het betwiste, uitspraak die aan Ford wordt toegeschreven.”