Dit is de derde 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. Sommige principes houden stand. Andere vertellen je meer over de tijd waarin ze zijn geschreven dan over de uitdagingen van vandaag. Principe #3 is het duidelijkste voorbeeld van het laatste. In 2001 was dat een directe aanval op de gangbare praktijk. Vandaag daagt het geen enkel team meer uit.
Het principe luidt:
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
In het Nederlands: “Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.”
In 2001 was dat een directe aanval op de gangbare praktijk. Vandaag daagt het geen enkel team meer uit.
Waarom dit principe ooit nodig was
Om te begrijpen waarom dit principe überhaupt moest worden geschreven, moet je terug naar de context van watervalontwikkeling. Softwareteams werkten in programma’s van maanden, soms langer dan een jaar. Planningsrondes produceerden dikke specificatiedocumenten die werden bevroren voordat er ook maar één regel code was geschreven. De eerste keer dat een klant iets zag, was de oplevering. En dat was zelden wat hij had bedoeld.
Principe #3 brak frontaal met die werkwijze: lever regelmatig op, en liever vaker dan minder.
Er zit iets merkwaardigs in de verhouding tot principe #1. Dat principe, dat stelt dat de hoogste prioriteit het tevredenstellen van de klant is door het vroegtijdig en voortdurend creëren van waarde, zegt feitelijk hetzelfde, maar dan vanuit de klantrelatie. Principe #3 klinkt als een herhaling, maar dan smaller: minder over waarde, meer over tempo. Koen wees er in het gesprek op dat hij het verschil aanvankelijk niet helder kon benoemen. Als je principe #3 weglaat en principe #1 serieus neemt, mis je dan iets?
Gedeeltelijk wel. Er zit in principe #3 een eigen gedachte die principe #1 niet dekt, en die heeft niets met software te maken. Maar om die gedachte te vinden, moet je eerst voorbij drie problemen die de formulering zelf veroorzaakt.
Drie plaatsen waar het wringt
Werkende software zonder definitie
De eerlijkste kritiek op principe #3 is dat het woord werkend geen definitie krijgt. Het Manifesto geeft de ambitie, de invulling is aan het team. In de praktijk heeft dat een patroon opgeleverd dat inmiddels zijn eigen naam heeft.
Ken Schwaber, een van de grondleggers van Scrum, beschreef in zijn eigen blog hoe teams een façade van vooruitgang ophouden: ieder team toont zijn eigen increment in de sprint review, terwijl de integratie van al die incrementen naar het einde van het project verschuift, in een stabilisatiefase die zo vanzelfsprekend is geworden dat niemand hem meer als probleem beschouwt. In Agile-kringen heet dit demo theater: iets laten zien dat eruitziet alsof het klaar is, terwijl de echte integratieproblemen elders worden doorgeschoven.
Cris herkende het patroon. Bij veel Scrum-teams zijn hardening sprints, waarin een team aan het eind alsnog stabiliseert wat al af heette, eerder regel dan uitzondering geworden. Ze normaliseren een situatie waarin werk feitelijk niet af is. Het principe geeft geen definitie van werkend, en dat gat wordt gevuld met wat het team op dat moment wél kan laten zien.
De sprint-cadans als deadline
Een tweede patroon: de sprint-cadans is in veel organisaties omgebogen van een werkritme naar een deadline. Management gebruikt het tijdvenster om druk te zetten. Het team levert binnen het venster, maar de stories die net niet pasten worden gecut, en kwaliteit is het eerste slachtoffer.
De Scrum Guide is hierover helder: de kwaliteit van het werk mag niet omlaag, en als iets niet past binnen de sprint is het de scope die je heronderhandelt. In de praktijk gebeurt het omgekeerde, en wordt kwaliteit ingeleverd om de scope binnen het venster te halen. Het principe schrijft een cadans voor. Wat een team moet doen wanneer die cadans alleen haalbaar is door kwaliteit te laten zakken, staat er niet bij.
Het principe legt ook niet uit wat regelmatig opleveren van een team vraagt. Om te kunnen opleveren zonder kwaliteit in te leveren, heb je technische infrastructuur nodig. Trunk-based development, het patroon waarbij alle code voortdurend naar één gedeelde hoofdbranch wordt geïntegreerd zodat de codebase op elk moment productieklaar is, is daarvan het bekendste voorbeeld. Daarbij horen geautomatiseerde tests en feature flags, waarmee je een functie kunt bouwen en deployen zonder dat gebruikers haar zien totdat je er klaar voor bent. Het Manifesto noemt niets van dit alles. Het zegt dat je regelmatig moet opleveren en laat aan het team over hoe. In de praktijk vult elke organisatie dat gat in met wat ze kennen, wat zelden voldoende is.
Een achterhaald tijdsvenster
Dan het meest zichtbare probleem: het tijdsvenster van weken tot maanden is in 2026 geen ambitie meer. De benchmarks van DORA, het onderzoeksprogramma achter het boek Accelerate (Forsgren, Humble, Kim), laten al jaren zien dat teams met een volwassen delivery-praktijk meerdere keren per dag deployen. Inmiddels is voor iedereen zichtbaar dat een bedrijf als Anthropic bijna dagelijks updates uitbrengt op zijn productieomgeving.
Bij goed ingerichte teams komt dat neer op meerdere commits per dag naar de trunk, waarbij elke commit productieklaar is, ongeacht of hij ook daadwerkelijk naar productie gaat.
Met AI is dat tempo nog verder opgerekt. Een team dat code laat genereren kan in theorie meerdere keren per dag iets opleveren, wat de bovengrens van iedere paar maanden helemaal achterhaald doet lijken. Maar snelheid zegt niets over waarde. AI produceert net zo makkelijk volume waar niemand iets aan heeft, en meer opleveren is niet hetzelfde als beter opleveren. Op een gegeven moment kan de klant de stroom aan updates niet eens meer verwerken, waardoor de zoveelste release niets toevoegt dat hij merkt.
Het probleem heeft ook een andere kant. Hetzelfde tijdsvenster wordt door trage organisaties gebruikt als rechtvaardiging. Een kwartaalrelease is iedere paar maanden, en het principe laat dat toe. Organisaties die in kwartaalplanningen werken hangen daar een Agile-stempel op, terwijl de onderliggende werkwijze nog steeds waterval is met sprints eromheen. Het tijdsvenster gaat zo beide kanten op werken: snelle teams overstijgen het, trage teams verschuilen zich erachter.
Daaronder ligt een dieper probleem, waar een eigen ervaring naar boven kwam. Het principe meet output en niet outcome: hoeveel je oplevert, niet of de klant er iets aan heeft. Armand haalde een opdracht aan waar velocity, het aantal story points per sprint, de norm was waarop een team werd afgerekend, terwijl niemand mat welke waarde dat opleverde. Een team gaat dan sturen op het getal en niet op het resultaat. Veel opleveren in hoog tempo terwijl klantwaarde stagneert, is wat John Cutler een feature factory noemde. Het principe biedt daar geen bescherming tegen, omdat het niets zegt over de vraag of het opgeleverde iets oplost.
Wat het principe eigenlijk wil zeggen
Halverwege het gesprek formuleerde Armand iets wat een andere richting opende: wat als dit principe niet gaat over de frequentie van opleveringen, maar over de lengte van feedback loops?
Regelmatig opleveren is een uitkomst. Korte feedback loops zijn de reden erachter: zo vaak en zo snel mogelijk toetsen of je hypothese klopt, of dat nu code is die door de pipeline wordt gecontroleerd of een feature die je aan een klant voorlegt. En zodra je het principe vanuit die reden leest, worden de problemen scherper zichtbaar en worden ze ook makkelijker te vertalen naar contexten buiten software.
Korte feedback loops verlagen het risico van een grote fout. Als je pas na zes maanden ontdekt dat je de verkeerde kant op hebt gebouwd, is zes maanden werk deels verspild. Als je dat na twee weken ontdekt, zijn het twee weken. Die logica geldt voor code, maar ook voor een marketingcampagne die drie maanden in ontwikkeling is voordat er iemand van de doelgroep naar heeft gekeken.
DevOps trekt deze logica het consequentst door. In DevOps is het principe van korte feedback loops niet beperkt tot de relatie met de klant, maar verspreid over de gehele waardestroom: in de deployment-pipeline, in de testautomatisering, in de monitoring van productieomgevingen. Je bouwt feedback in op elk punt waar een fout kan ontstaan, zodat de tijd tussen het maken van een fout en het ontdekken ervan zo kort mogelijk is. De vijf DORA-metrics raken hieraan, maar meten de feedback loop niet rechtstreeks. Deployment frequency, lead time for changes en failed deployment recovery time beschrijven hoe snel werk en herstel door de keten bewegen, change failure rate en rework rate hoeveel daarvan achteraf gerepareerd moet worden. Goed scoren op die metrics lukt alleen wanneer de feedback loops in de waardestroom kort zijn. Dit gaat over feedback op het product en de weg ernaartoe. De reflectie op de samenwerking zelf hoort bij een ander principe verderop in het Manifesto.
Cris haalde er een parallel bij van buiten de softwarewereld: in militaire strategie wordt een vergelijkbaar principe gehanteerd. Wie zijn beslissingscyclus sneller doorloopt dan de tegenstander, handelt effectiever. Korte feedback loops zijn geen uitvinding van softwareteams.
Bij communicatieteams in zorgorganisaties ziet Koen dat de bottleneck bij het snel leveren van waarde bijna nooit de uitvoering zelf is, maar de wachttijd op goedkeuring, de context-switch als betrokkenen op meerdere projecten tegelijk worden ingezet, en het gebrek aan een gedeeld werkritme. Iemand die weet dat hij morgen feedback krijgt, werkt anders dan iemand die moet wachten tot alle betrokkenen een gaatje in de agenda hebben. Het mechanisme is hetzelfde als bij een goed ingericht softwareteam, alleen de vorm verschilt.
Dat bredere perspectief komt ook overeen met hoe Lean naar dit probleem kijkt. Lean is ouder dan het Agile Manifesto en kijkt vanuit de waardestroom: elke stap tussen het begin van het werk en het moment dat de klant er waarde aan ontleent, is een stap waarop je kunt verliezen. Wachttijden en batchgroottes zijn in Lean directe maatstaven voor inefficiëntie. Het principe van kleine batches en korte cycli is in Lean een structurele manier om verspilling te elimineren.
Gereguleerde omgevingen: een terechte kanttekening
Er is één punt waarop de verschuiving naar feedback loops te eenvoudig dreigt te worden. Cris benoemde het vanuit zijn achtergrond in defensiesoftware.
Bij omgevingen met zware compliance-vereisten, denk aan medische systemen, defensiesoftware of financieel gereguleerde applicaties, heeft elke release een audit-traject dat niet te versnellen valt. De frequentie van productie-releases ligt dan vast. Juridische en veiligheidsstandaarden bepalen het tempo, en daar valt niet aan te tornen.
Maar dit argument snijdt anders dan het op het eerste gezicht lijkt. De frequentie van een productie-release en de frequentie van een interne feedbackcyclus zijn twee verschillende dingen. Een team bij Defensie dat dagelijks zijn code integreert, geautomatiseerde tests draait en pas na een uitgebreid compliance-traject naar productie gaat, heeft een kortere interne feedback loop dan een team dat drie weken doorontwikkelt voordat het ook maar begint te integreren. Het principe gaat over het eerste, niet uitsluitend over het tweede.
Koen wees op een vergelijkbaar onderscheid in zijn agile coaching: je kunt een concepttekst intern laten reviewen en aanpassen voordat hij naar buiten gaat. Je kunt een campagne eerst testen bij een kleine groep. Die stappen kosten tijd, maar zijn een andere orde van grootte dan wachten tot alles af is. De creatiefste onderdelen van marketingwerk lenen zich minder goed voor micro-incrementele opleveringen dan software, maar dat is geen reden om het principe te laten vallen. Het is een reden om de vertaalslag naar je eigen vakgebied bewuster te maken.
Ons oordeel: herschrijven
Tijdloos? Verouderd? Klaar voor de prullenbak?
Dit is het eerste principe in de reeks waarvan we zeggen: de formulering heeft zijn langste tijd gehad, maar in de kern is dit een waardevol principe.
Het tijdsvenster van weken tot maanden stuurt niemand meer: snelle teams zitten er ver onder, en trage organisaties lezen het als toestemming om traag te blijven. De definitie van werkend is te open gelaten en dat vacuüm heeft demo theater en hardening sprints mogelijk gemaakt. De nadruk op opleveren mist de reden achter het principe, die gaat over het verkleinen van het risico dat je lang de verkeerde kant op bouwt. En het woord software sluit de helft van de teams buiten voor wie het principe minstens zo relevant is.
Bondig samengevat: het gaat om feedbackcycli, niet om oplevercycli. Het zijn verwante begrippen maar de oriëntatie verschilt. Wie denkt in oplevercycli, vraagt wanneer hij iets af heeft. Wie denkt in feedbackcycli, vraagt wanneer hij weet of hij de goede kant op gaat.
Onze herformulering:
“Verkort de cyclus tussen het maken van iets en het moment dat je weet of het klopt. Hoe korter die cyclus, hoe kleiner het risico en hoe sneller je leert.”
De volgende aflevering gaat over principe #4.
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
- Ken Schwaber — blog over demo theater en hardening sprints
- Scrum Guide — over kwaliteit en scope-heronderhandeling
- DORA (Forsgren, Humble, Kim) — Accelerate en de vijf delivery-metrics
- John Cutler / Martin Fowler — feature factory-concept