Agile, sprints en ‘done’ in de rechtszaal: Waarom rechters IT-deskundigen nodig hebben
IT-juristen weten het al jaren: de kloof tussen juridische beoordeling en de realiteit van IT contracten / softwareontwikkeling is diep. Die kloof wordt pijnlijk zichtbaar in een recente rechtszaak tussen On Air B.V. en Triple IT B.V., waarin het gerechtshof Amsterdam zich buigt over de vraag of een front-end tijdig en deugdelijk is opgeleverd in een agile ontwikkeltraject. De procedure is inmiddels ruim drie jaar gaande, met als voorlopig dieptepunt dat het hof zich genoodzaakt ziet een IT-deskundige in te schakelen om fundamentele begrippen uit de IT-praktijk uit te leggen.
De uitdaging: juridisch kaderen van agile/scrum
In deze zaak draait het om de ontwikkeling van een front-end via een agile/scrum-aanpak, met levering in sprints en een “definition of done”. Triple IT factureerde voor haar werkzaamheden, terwijl On Air betaling weigerde, stellende dat niet aan de afgesproken voorwaarden was voldaan. Volgens On Air was geen sprake van deugdelijke oplevering, laat staan acceptatie.
Het hof constateert echter dat het simpelweg ontbreken van een concrete opleverdatum — een typisch kenmerk van agile werken — het juridisch kader bemoeilijkt. Wat betekent ‘oplevering’ binnen agile? Is het label ‘done’ in de procesmanagement software voldoende om aan te nemen dat een (deel)product geaccepteerd is? Wanneer begint de klachttermijn te lopen bij software die iteratief wordt ontwikkeld? Rechters weten het niet en dat is logisch. Het zijn immers geen IT-professionals.
Deskundige moet terminologie en praktijk uitleggen
In het tussenarrest van april 2024[1] besluit het hof dan ook om een IT-deskundige te benoemen. Die krijgt een indrukwekkend takenpakket mee: van het beoordelen van de feitelijke voortgang per sprint, tot het verklaren van begrippen als ‘scrum master’, ‘sprint’, ‘front-end’ en — cruciaal — ‘done’.
De deskundige moet ook uitleggen hoe de branche omgaat met tussentijdse opleveringen in sprints, en in hoeverre die gebruikelijk als formele oplevermomenten worden beschouwd. De kernvraag is dan: heeft een ‘done’ ticket juridische gevolgen, zoals het starten van een klachttermijn of de impliciete acceptatie van het werk? Deze vragen raken het hart van veel IT-geschillen.
Traagheid en kosten van de procedure
De rechtbank deed uitspraak in maart 2022. Pas in april 2024 besluit het hof tot een deskundigenonderzoek. In juli 2025[2] wordt de deskundige officieel benoemd. De verwachting is dat het rapport pas in of na december 2025 beschikbaar komt, waarna partijen mogen reageren. Een einduitspraak? Niet eerder dan medio 2026. Een slepende hoger beroep procedure van vier jaar is dan een feit.
Had dit beter gekund? Ja: arbitrage en duidelijke contracten
Een geschil als dit illustreert waarom partijen in IT-geschillen vaak beter af zijn met arbitrage bij gespecialiseerde instituten als SGOA of TAMI. Daar hebben arbiters wél kennis van agile, scrum, sprints en software ontwikkeling. Soms volstaat al om een materie-deskundige, in het kader van een bindend advies, een oordeel te laten geven. Met zo’n oordeel kunnen partijen daarna weer verder. Dat is met name relevant wanneer partijen met elkaar door willen gaan. Alleen hebben ze dit dispuut waar iemand een oordeel in moet geven. Daarna gaan ze verder met elkaar. Dan kun je gaan jaren wachten op een uitspraak van een gerechtshof. Dan wil je binnen een paar weken duidelijkheid.
Daarnaast onderstreept deze zaak het belang van duidelijke contracten. Definieer wat ‘oplevering’ betekent. Leg vast wat ‘done’ is. Omschrijf acceptatieprocedures per sprint. Beter nog: vermijd vaagheden als “we aim to have a shippable release” of “As a result we don not offer completion dates” of “Final project costs are not projected or guaranteed, a result of the agile software developmentapproach that allows for changing requirements, methods and designs throughout the project.” Deze onduidelijkheden leiden vroeg of laat tot discussies.
Conclusie
Deze zaak laat zien dat juridische systemen nog steeds moeite hebben om wendbare ontwikkelmethoden juridisch te duiden. Een deskundige moet nu de rechter helpen om agile te begrijpen. Maar had dit voorkomen kunnen worden? Absoluut, met duidelijke definities, goede documentatie, betere communicatie met de opdrachtgever en waar nodig een alternatieve geschilbeslechting via arbitrage c.q. bindend advies.
Heb je hier vragen over? Neem dan contact op met Jos van der Wijst.
[1] Gerechtshof Amsterdam, 23 april 2024, ECLI:NL:GHAMS:2024:1070
[2] Gerechtshof Amsterdam, 15 juli 2025, ECLI:NL:GHAMS:2025:1814
