Gepubliceerd op 22 september 2026
Agile softwareontwikkeling past slecht bij contracten waarin het eindresultaat, de omvang van de opdracht en de opleverdatum vooraf volledig zijn vastgelegd. In een agile traject werken partijen in korte sprints, telkens afgebakende werkperioden, en wordt de inhoud van het product gedurende het project bijgesteld.
Dat biedt flexibiliteit, maar roept ook juridische vragen op. Wie bepaalt de prioriteiten? Wanneer is een sprintresultaat geaccepteerd? En wanneer leidt een gemiste opleverdatum tot verzuim? Dit artikel bespreekt hoe partijen deze vragen contractueel kunnen beantwoorden.
Met een agile-contract bedoelen wij hierna het geheel van afspraken waarmee partijen een agile-samenwerking vastleggen. Die samenwerking krijgt in de praktijk vorm in een raamovereenkomst met daaronder afzonderlijke nadere overeenkomsten per opdracht.
Inhoudsopgave
Agile werken en contracteren
Bij een klassiek IT-project stellen partijen vooraf een functioneel en technisch ontwerp vast. De leverancier verbindt zich vervolgens dat resultaat op een bepaald moment op te leveren. Bij agile ontwikkeling ontbreekt die vaste eindbestemming bewust: het resultaat is een veranderlijk doel.
Elke sprint levert een werkend, bruikbaar deel van de software op. Op basis van demonstraties en gebruikerservaring stuurt de opdrachtgever bij. Waar een klassiek contract vastlegt waar het project eindigt, blijft dat bij agile werken juist open.
Daarom moeten partijen contractueel regelen wat bij een klassiek project vaak al uit het bestek blijkt. Vier onderwerpen springen eruit:
- wie de specificaties bepaalt, oftewel wie de rol van product owner vervult (degene die namens de opdrachtgever prioriteiten stelt);
- hoe wijzigingen worden verwerkt in de backlog (de geprioriteerde lijst met nog te bouwen functionaliteit), de planning en de prijs;
- wanneer een onderdeel als afgerond geldt, aan de hand van een definition of done (de afgesproken criteria voor een afgerond resultaat) en acceptatiecriteria (de eisen waaraan een oplevering wordt getoetst);
- of afgesproken opleverdata fataal zijn of indicatief.
Een praktische consequentie: agile werken laat zich moeilijk combineren met een aanbesteding waarin de omvang van de opdracht vooraf volledig vastligt. Wie aanbestedingsplichtig is maar agile wil laten ontwikkelen, doet er goed aan in de aanbestedingsstukken ruimte te maken voor een raamovereenkomst met flexibel in te vullen nadere opdrachten.
Inspannings- of resultaatsverbintenis?
Bij een inspanningsverbintenis staat de leverancier niet in voor een bepaald resultaat. Hij verbindt zich in te spannen zoals van een redelijk bekwaam en redelijk handelend vakgenoot mag worden verwacht. Bij een resultaatsverbintenis verbindt hij zich juist wel tot een concreet omschreven resultaat.
Het label in het contract is niet doorslaggevend. Ook wanneer een overeenkomst spreekt van een resultaatsverplichting, kan de rechter op grond van de inhoud van de afspraken en de context oordelen dat feitelijk sprake is van een inspanningsverbintenis, en andersom. Hoe partijen feitelijk samenwerken weegt dus minstens zo zwaar als de gekozen bewoordingen.
Het onderscheid is praktisch relevant omdat bij een resultaatsverbintenis het overeengekomen resultaat centraal staat, terwijl bij een inspanningsverbintenis moet worden beoordeeld of de leverancier de vereiste inspanning heeft geleverd. Dat verschil bepaalt waarover partijen in een geschil discussiëren en wat zij moeten aantonen.
Twee wetsartikelen komen hierbij terug. Artikel 6:74 lid 1 BW vormt de grondslag voor schadevergoeding wegens een toerekenbare tekortkoming. De bepaling zegt echter niet wanneer sprake is van een tekortkoming; dat hangt af van de kwalificatie van de verbintenis en de inhoud van de afspraken. Artikel 6:248 BW bepaalt dat een overeenkomst ook de gevolgen heeft die uit redelijkheid en billijkheid voortvloeien. Dat biedt ruimte om de aard van een agile-samenwerking mee te wegen bij de uitleg van de verplichtingen.
De contractuele basis: raamovereenkomst en nadere overeenkomsten
In de praktijk wordt de agile-samenwerking gelaagd vastgelegd. Een raamovereenkomst regelt het algemene kader: toepasselijke voorwaarden, aansprakelijkheid, geheimhouding en de wijze van samenwerken.
Per opdracht sluiten partijen een nadere overeenkomst, ook wel aangeduid als nadere opdracht, waarin de omvang, planning, teamsamenstelling, prijs en acceptatiecriteria voor dat onderdeel staan. Zo blijft de juridische verhouding stabiel terwijl de inhoud per sprint of release kan meebewegen.
Zonder duidelijke acceptatiecriteria is niet vastgelegd waaraan het resultaat moet worden getoetst. Daardoor ontstaat sneller discussie over de vraag of de sprint is geslaagd. Concrete, meetbare acceptatiecriteria per sprint zijn daarom belangrijker dan het label dat partijen aan de verbintenis geven.
Een onderwerp dat bij agile-contracten meer aandacht verdient dan bij klassieke IT-contracten is de tussentijdse beëindiging. Omdat een agile traject een reeks opeenvolgende sprints is zonder vast eindpunt, moet het contract regelen wanneer een partij kan stoppen, wat er gebeurt met reeds opgeleverde onderdelen en broncode, en hoe overdracht aan een andere leverancier verloopt.
Voor de juridische inbedding zijn ook algemene voorwaarden van belang. De NLdigital Voorwaarden 2025 zijn de opvolger van de editie uit 2020, met nieuwe hoofdstukken over onder meer compliance, cybersecurity, datadeling, kunstmatige intelligentie en onlineplatforms. De voorwaarden uit 2020 blijven gelden wanneer partijen die zijn overeengekomen, dus controleer welke versie op uw contract van toepassing is. De specifieke agile-aspecten voorzien zij slechts beperkt; die moeten partijen zelf in de nadere overeenkomst regelen.
Rechtspraak over termijnen en samenwerking
De rechtspraak laat geen algemene regel zien dat een agile-opleverdatum nooit fataal kan zijn. De kwalificatie hangt af van de inhoud van de overeenkomst, de gekozen werkwijze en de feitelijke samenwerking tussen partijen. Drie zaken illustreren dat.
Rechtbank Midden-Nederland 26 juli 2023 (ECLI:NL:RBMNE:2023:5936). Leverancier IPS ontwikkelde volgens scrum software voor weegschalen voor opdrachtgever Synergy. De overeenkomst noemde een doorlooptijd van ongeveer 24 weken. Die werd niet gehaald; een nieuwe deadline werd verschoven en opnieuw gemist. Toen medio december 2020 negen van de tien overeengekomen weekblokken waren opgeleverd, ontbond Synergy de overeenkomst. De rechtbank oordeelde dat de toegezegde totale doorlooptijd wél als fatale termijn gold, zodat verzuim was ingetreden. De ontbinding hield echter geen stand: gelet op de aard van de samenwerking, waarbij bij het niet halen van deadlines nieuwe afspraken worden gemaakt, en op het gegeven dat het project bijna was afgerond, rechtvaardigde dat verzuim de ontbinding niet. Betekenis voor de praktijk: ook binnen een agile-samenwerking kan een toegezegde doorlooptijd fataal zijn, maar verzuim leidt niet automatisch tot een geslaagde ontbinding.
Rechtbank Amsterdam 22 april 2026 (ECLI:NL:RBAMS:2026:3930). Een opdrachtgever verweet ontwikkelaar DTT dat een nieuwe mobiele app te laat was opgeleverd, dat de begrote kosten waren overschreden en dat het onderhoud van bestaande apps ondeugdelijk was. De rechtbank wees alle vorderingen af. Van fatale termijnen was geen sprake: de in de offerte en de communicatie genoemde opleverdatum moest worden gezien als een inspanningsverplichting binnen een agile- of scrum-werkwijze, waarin flexibiliteit en voortschrijdend inzicht centraal staan. Betekenis voor de praktijk: wie zeker wil zijn dat een datum fataal is, moet dat uitdrukkelijk vastleggen; een datum in een offerte is daarvoor niet genoeg.
Gerechtshof Amsterdam, in de zaak tussen On Air en Triple IT. Partijen waren agile of scrum overeengekomen zonder eindresultaten te definiëren. In die context omvat de verplichting weinig meer dan het beschikbaar stellen van bekwame ontwikkelaars die zich inspannen conform het ontwerp en de zorgplicht van een goed opdrachtnemer. Voldoet het opgeleverde niet, dan zijn de inspanningen om dat alsnog te bereiken in beginsel meerwerk. Dat kan anders zijn wanneer de leverancier zich niet aan de afspraken of zijn zorgplicht heeft gehouden, maar de bewijslast daarvoor rust op de opdrachtgever. Het enkele feit dat de prestaties van het eindproduct niet aan de wensen van de opdrachtgever voldoen, is dus onvoldoende voor een tekortkoming. In deze procedure heeft het hof bovendien een IT-deskundige benoemd om begrippen als scrum master, sprint en done toe te lichten. Betekenis voor de praktijk: ontbreken gedefinieerde eindresultaten, dan komt herstelwerk al snel voor rekening van de opdrachtgever.
Bij de beoordeling van een vordering tot ontbinding kan de rechter dus meewegen welke rol beide partijen hebben gespeeld bij de vertraging en de uitvoering van het traject. Wie niet afhankelijk wil zijn van die weging in een individueel geval, moet zelf vastleggen wanneer een termijn fataal is en wanneer tussentijdse beëindiging mogelijk is.
Acht aandachtspunten voor het contract
Loop bij het opstellen van een agile-contract de volgende punten langs. Formuleer per onderwerp het antwoord op de bijbehorende vraag.
- Omvang: welke functionaliteiten vallen binnen de sprint, en wat valt daar uitdrukkelijk buiten?
- Prioritering: wie mag de backlog wijzigen, en heeft die persoon daarvoor mandaat namens de opdrachtgever?
- Acceptatie: binnen welke termijn moet de opdrachtgever testen en reageren, en wat geldt als hij dat niet doet?
- Termijnen: is de genoemde datum indicatief of fataal, en staat dat er met zoveel woorden?
- Prijs: wordt afgerekend per sprint, per functiepunt, per ureninzet of per resultaat?
- Eigendom en gebruik: op welk moment krijgt de opdrachtgever toegang tot broncode en documentatie?
- Beëindiging: wat wordt bij tussentijdse beëindiging overgedragen, en tegen welke vergoeding?
- Continuïteit: kan een andere leverancier het werk voortzetten, en wat is daarvoor nodig aan documentatie en overdraagbaarheid van de code?
Neem daarnaast een definition of done op die niet alleen functioneel is, maar ook eisen stelt aan kwaliteit, documentatie en overdraagbaarheid van de code. Anders ontstaat bij beëindiging alsnog discussie over de vraag of het opgeleverde werk bruikbaar is.
Conclusie
Agile werken biedt flexibiliteit, maar vraagt om een contract dat wezenlijk verschilt van het klassieke model. Het onderscheid tussen inspannings- en resultaatsverbintenis, heldere acceptatiecriteria en een regeling voor tussentijdse beëindiging zijn daarbij bepalend. De besproken uitspraken laten zien dat de uitkomst sterk afhangt van de concrete afspraken en de feitelijke samenwerking. Een contract dat deze punten behandelt, sluit beter aan bij de feitelijke werkwijze en verkleint het risico op geschillen.
Law & More begeleidt IT-leveranciers en opdrachtgevers bij het opstellen, beoordelen en onderhandelen van raamovereenkomsten en nadere overeenkomsten, en adviseert over de kwalificatie van verbintenissen, acceptatiecriteria en exit-regelingen. Loopt u aan tegen discussie over vertraging, resultaat of beëindiging van een agile traject? Neem gerust contact op voor advies op maat.
Veelgestelde vragen
Hieronder beantwoorden wij de vragen die ons over dit onderwerp het vaakst worden gesteld.
Wat is een agile-contract?
Het geheel van afspraken waarmee partijen een agile-samenwerking vastleggen. In de praktijk bestaat dat uit een raamovereenkomst met het algemene kader en daaronder een nadere overeenkomst per opdracht, met de omvang, planning, prijs en acceptatiecriteria voor dat onderdeel.
Is een opleverdatum in een agile traject fataal?
Niet automatisch. Er bestaat geen algemene regel; het hangt af van de overeenkomst, de werkwijze en de feitelijke samenwerking. Wilt u dat een datum fataal is, leg dat dan met zoveel woorden vast. Een datum in een offerte is daarvoor onvoldoende gebleken.
Wat is het verschil tussen een inspannings- en een resultaatsverbintenis?
Bij een resultaatsverbintenis staat het overeengekomen resultaat centraal. Bij een inspanningsverbintenis moet worden beoordeeld of de leverancier de vereiste inspanning heeft geleverd. Dat verschil bepaalt waarover partijen in een geschil discussiëren.
Is het label in het contract doorslaggevend?
Nee. Ook wanneer het contract spreekt van een resultaatsverplichting, kan de rechter op grond van de inhoud van de afspraken en de context oordelen dat feitelijk sprake is van een inspanningsverbintenis, en andersom. De feitelijke werkwijze weegt minstens zo zwaar.
Wie mag de backlog wijzigen?
Degene die de rol van product owner vervult. Leg vast wie dat is en of die persoon daarvoor mandaat heeft namens de opdrachtgever. Zonder die afspraak ontstaat discussie over de vraag wie verantwoordelijk is voor wijzigingen in de prioriteiten.
Waarom zijn acceptatiecriteria zo belangrijk?
Zonder duidelijke acceptatiecriteria is niet vastgelegd waaraan het resultaat moet worden getoetst. Daardoor ontstaat sneller discussie over de vraag of de sprint is geslaagd. Zij zijn in de praktijk belangrijker dan het label dat aan de verbintenis wordt gegeven.
Wie betaalt herstelwerk als het opgeleverde niet voldoet?
Zijn geen eindresultaten gedefinieerd, dan komen de inspanningen om alsnog aan de wensen te voldoen in beginsel als meerwerk voor rekening van de opdrachtgever. Dat is anders wanneer de leverancier zich niet aan de afspraken of zijn zorgplicht heeft gehouden, maar de bewijslast daarvoor ligt bij de opdrachtgever.
Hoe wordt betaling geregeld bij agile werken?
Betaling koppelen aan één vast opleveringsmoment past slecht bij een werkwijze zonder vastgelegd eindresultaat. Gebruikelijke alternatieven zijn afrekenen per sprint, per functiepunt of per ureninzet. Leg de gekozen grondslag expliciet vast.
Kan ik agile werken combineren met een aanbesteding?
Dat vraagt om een aangepaste opzet, omdat een aanbesteding met een volledig vastgelegde omvang uitgaat van een vooraf bekend resultaat. Creëer in de aanbestedingsstukken ruimte voor een raamovereenkomst met flexibel in te vullen nadere opdrachten.
Wat moet ik regelen over tussentijdse beëindiging?
Onder welke voorwaarden een partij kan stoppen, wat er gebeurt met reeds opgeleverde onderdelen en broncode, tegen welke vergoeding overdracht plaatsvindt, en wat een andere leverancier nodig heeft om het werk voort te zetten.
Bieden de NLdigital Voorwaarden 2025 voldoende houvast?
Slechts beperkt. Zij zijn de opvolger van de editie uit 2020 en voegen hoofdstukken toe over onder meer compliance, cybersecurity, datadeling, kunstmatige intelligentie en onlineplatforms, maar voorzien de specifieke agile-aspecten niet. De voorwaarden uit 2020 blijven gelden wanneer die zijn overeengekomen. Die moet u zelf in de nadere overeenkomst regelen.
Heeft u een geschil met een IT-leverancier of wilt u een IT-contract laten toetsen? Onze advocaten IT-recht denken graag met u mee.
