11 okt Agile-zorgplichten van ICT-dienstverlener

1        Inleiding

Softwareontwikkeling is zelden een rechtlijnig proces, zelfs niet als volgens de ontwikkelmethodiek een rechtlijnige aanpak zou zijn voorgeschreven. Bij Agile- en Scrummethode wordt een rechtlijnige aanpak zelfs bewust verlaten. Deze methoden gaan uit van een nauwe samenwerking tussen de ICT-dienstverlener en opdrachtgever c.q. gebruiker van de software. In een dergelijke samenwerking wordt op basis van initiële specificaties bepaalde voorbeeldprogrammatuur ontwikkeld, die vervolgens tijdens het project in een of meer sprints met de opdrachtgever wordt getoetst en vervolgens aan de hand van nadere of verfijnde wensen en eisen wordt bijgesteld. Men spreekt daarbij van evolutionair ontwikkelen. Dikwijls heeft het proces van softwareontwikkeling een sterk iteratief karakter.

Als gevolg daarvan kunnen de ontwikkelingsstadia niet altijd even duidelijk worden onderscheiden, en is niet altijd eenvoudig te beoordelen of en in welke mate de resultaten van een bepaalde ontwikkelingsfase te zien zijn als een bewerking of vertaling van een document uit een daaraan voorafgaande fase. De grenzen tussen het ontwerp en de programmatuur zijn in die gevallen vloeiend. Een tussenversie van een computerprogramma in ontwikkeling geldt, kan men zeggen, tevens als voorbereidend ontwerpmateriaal voor het verdere ontwikkeltraject.

In deze blog beschrijf ik welke bijzondere zorgplichten er gelden voor een ICT-dienstverlener bij het hanteren van de Agile-scrummethodiek (hierna: Agile).

2        Inhoud

1       Inleiding. 1

2       Inhoud. 2

3       Agile afgesproken?. 2

4       Speelveld Agile: balans tussen samenwerken en zorgplicht 3

5       Algemene zorgplicht ICT-dienstverlener 6

6       Agile-zorgplicht(en) ICT-dienstverlener 6

7       Schuldeisersverzuim bij Agile. 11

3        Agile afgesproken?

Bij de beantwoording van de vraag of ICT-dienstverlener de op haar rustende zorgplicht heeft geschonden, is in de eerste plaats van belang te bepalen of partijen in de overeenkomsten de Agile-methodiek hebben afgesproken voor de door te realiseren software oplossing. Partijen moeten het erover eens zijn dat overeenkomsten een agile karakter hebben. Dit betekent onder andere dat zij niet van tevoren hebben afgesproken dat er een nauwkeurig omschreven eindproduct zou worden geleverd tegen een vooraf afgesproken prijs. Bij Agile is in de regel het streven van partijen om een bepaald eindresultaat te behalen: een goed werkende oplossing.

Kort samengevat wordt dus bij de Agile-methode, anders dan softwareontwikkeling volgens de klassieke Waterfall-methode, niet vooraf contractueel volledig vastgelegd wat er op detailniveau precies gebouwd gaat worden, maar wordt gaandeweg aan de hand van de test-feedback van de opdrachtgever verder afgestemd wat precies gebouwd gaat worden. Wel worden vanuit de bedrijfsactiviteiten van de opdrachtgever vooraf de wensen/eisen (“requirements”) geïnventariseerd en neergelegd in een totale Userstory. Vervolgens wordt het project opgesplitst in miniatuurprojectjes, sprints genaamd. Per sprint wordt een stukje uit de totale Userstory gehaald en een voor die sprint specifieke userstory opgemaakt, waarna die sprint wordt gemaakt. Per sprint worden de fasen van planning, afstemming, goedkeuring, bouw, testen, feedback en acceptatie doorlopen. Naar aanleiding van het verloop van een sprint wordt in overleg bepaald wat er in de volgende sprint wordt gebouwd.

Onderdeel van de agile scrummethode is dus ook dat bij aanvang van de werkzaamheden een zogenoemd product backlog (hierna: de backlog) wordt opgesteld, waarin alle gewenste specificaties van de te bouwen functionaliteit zijn weergegeven, met vermelding van de prioriteit daarvan. De backlog wordt gedurende alle sprints bijgewerkt. Specificaties kunnen eruit worden verwijderd en nieuwe wensen van de klant kunnen worden toegevoegd, terwijl de prioritering kan worden aangepast.

4        Speelveld Agile: balans tussen samenwerken en zorgplicht

Indien partijen met elkaar zijn overeengekomen dat volgens de Agile-methodiek ontwikkeld gaat worden, dan hebben partijen met elkaar een bepaald speelveld geaccepteerd en daarbij dus ingestemd met bepaalde spelregels die inherent zijn aan de Agile-methodiek. Aan de ene kant betekent dit voor opdrachtgever dat hij aan ICT-dienstverlener een bepaalde ruimte moet gunnen, met dien verstande dat minder snel sprake is van klassieke verbintenisrechtelijke concepten zoals fatale termijn en tekortkomingen. Aan de andere kant betekent dit voor de ICT-dienstverlener dat doordat hem een bepaalde ruimte wordt gegund op hem ook bepaalde bijzondere zorgplichten, of zoals ik ze noem: Agile-zorgplichten, rusten. Hieronder schets ik het Agile-speelveld en daarbij behorende spelregels zoals die in jurisprudentie zijn geschetst.

Inlenen capaciteit: inspanningsverbintenis en manuren

Bij Agile is het uitgangspunt het inlenen van het door ICT-dienstverlener ter beschikking gestelde capaciteit tegen vergoeding per tijdseenheid (time & material): het periodiek inkopen van een bepaald aantal uren voor (door)ontwikkeling van applicaties en eventueel doorlopend onderhoud en ondersteuning. Op basis van dit uitgangspunt behelzen de Agile-overeenkomsten een inspanningsverbintenis en geen resultaatsverbintenis.[1] Dit betekent overigens niet dat ICT-dienstverlener ongestoord haar gang kan gaan. Er dient wel aantoonbaar gewerkt te worden aan de gewenste oplossing. Dat er bijvoorbeeld gaandeweg in de ogen van opdrachtgever het nodige valt aan te merken op de werkzaamheden van ICT-dienstverlener, maakt niet dat er zonder meer sprake is van bijvoorbeeld toerekenbare tekortkomingen of onvoorziene omstandigheden. Ook hoeft een hoge besteding manuren bij Agile niet per definitie onredelijk te zijn.[2] Wel geldt het uitgangspunt dat de uren wel in redelijkheid zijn gemaakt, de zogenaamde redelijkheidstoets bij Agile. Deze redelijkheidstoets behelst de beoordeling van wat de stand van het project is op een bepaald moment, zo mogelijk uitgedrukt in een percentage van het op 100% te stellen eindresultaat. Bijvoorbeeld: Indien klopt dat een project op het moment van beëindiging voor 90% is afgerond dan is er in beginsel geen reden te twijfelen aan de redelijkheid van de tot dat moment geïnvesteerde manuren (zeg: 88%). Deze duidelijkheid en uitsluitsel kan in de praktijk meestal enkel door een te benoemen deskundige worden geven.

(On)ervarenheid opdrachtgever

Bij Agile-project speelt de onervarenheid van opdrachtgever een grote rol bij de bepaling en beoordeling van elkaars verantwoordelijkheden en taken bij Agile en in hoeverre de Agile-zorgplichten reikt voor ICT-dienstverlener. Dikwijls is het zo dat de opdrachtgever een bepaalde mate van onervarenheid heeft op het gebied van ICT en om die reden ICT-dienstverlener de opdracht gunt op basis van Agile. Daarom is samenwerken voor partijen een plicht: ICT-dienstverlener dient opdrachtgever te betrekken bij het project en opdrachtgever de vereist actieve medewerking te verlenen.

Wijzigingen inherent aan Agile

Bij de ontwikkeling van een project met de agile/scrum-methode staat de op te leveren functionaliteit niet op voorhand vaststaat. Het is bij deze methode (juist) de bedoeling dat de functionaliteit tijdens het ontwikkeltraject wijzigt. Hoewel wijzigingen inherent zijn aan de Agile-methodiek, laat dit het bestaan van een waarschuwingsplicht van ICT-dienstverlener onverlet.

Wanneer in een verhouding tussen ICT-dienstverlener en opdrachtgever opleveringen plaatsvinden of anderszins resultaten worden gepresenteerd die niet naar de zin van de opdrachtgever zijn, moet uitgangspunt zijn dat ICT-dienstverlener het geleverde werk moet aanpassen conform de (nadere) instructies van de opdrachtgever, maar laatstgenoemde zal daarvoor dan gewoon weer conform de overeengekomen tarieven moeten (bij)betalen. Dit uitgangspunt kan uitzondering leiden indien de aanvullende werkzaamheden, voor zover die eerder waren overeengekomen, zouden meebrengen dat overeengekomen deadlines zouden worden overschreden, dat de ICT-dienstverlener afspraken niet is nagekomen, of (anderszins) niet de zorg heeft betracht die een goed opdrachtnemer betaamt, met inbegrip bijvoorbeeld van inefficiënt werken, het niet (adequaat) (laten) testen van resultaten, het niet programmeren volgens wat objectief als professionele standaard kan worden aangemerkt, of bijvoorbeeld het niet waarschuwen van de opdrachtgever voor (kennelijk door de opdrachtgever niet voorziene, maar voor de opdrachtnemer wel voorziene of voorzienbare) nadelige gevolgen van door de opdrachtgever gegeven instructies. Indien de opdrachtgever van mening is dat een dergelijke uitzonderingssituatie zich voordoet, is het aan deze om dit te stellen en, in geval van gemotiveerde betwisting, te bewijzen.[3]

Overigens blijkt uit de jurisprudentie dat de Agile-werkwijze de eisen in de overeenkomst onverlet laat. Indien in de overeenkomst eisen staan dan brengt een gunning aan een Agile-dienstverlener niet met zich mee dat opdrachtgever heeft ingestemd met een afwijking van de in de overeenkomst gestelde eisen.

Termijnen streefdata

Termijnen zijn bij een Agile-overeenkomst in beginsel als streefdata en richtlijnen aan te merken, tenzij uit de overeenkomst(en) of omstandigheden blijkt dat een termijn echt als ‘harde termijn’ en aldus als fataal te gelden heeft. Voor de kwalificatie van een fatale termijn in de zin van artikel 6:83 sub a BW moet sprake zijn van een voor voldoening vastgestelde termijn in het contract en dat deze ook voldoende bepaald moet zijn. De tijdsplanning is bij Agile daartoe meestal onvoldoende, met name gelet op het feit dat bij Agile sprake is van een inspanningsverbintenis en het inlenen van capaciteit.[4] Bij de Agile-werkmethode ligt het dus minder voor de hand dat partijen een fatale datum overeenkomen waarop een project moet zijn opgeleverd.[5] Het kan evenwel voorkomen dat de omstandigheden met zich meebrengt dat partijen een harde termijn c.q. fatale termijn overeengekomen zijn. Zie hiervoor de zaak HG/Cordys waarin de omstandigheden een rol speelde bij de kwalificatie van fatale termijn: opdrachtgever kritisch vragen stelde over de oplevertermijnen en ICT-dienstverlener mededelingen deed over de te behalen termijn.[6] Uit die mededelingen zijdens ICT-dienstverlener alsmede uit het feit dat in de leveringsovereenkomst sancties zijn gesteld op het niet tijdig leveren van de programmatuur volgt dat de voor oplevering overeengekomen data moeten worden aangemerkt als harde termijnen en niet als ‘richtdeadline’, zoals ICT-dienstverlener stelde.

Klachtplicht opdrachtgever

Indien op een gegeven moment opdrachtgever meent dat de kwaliteit van het te leveren en/of geleverde onvoldoende is en dat er te veel uren worden gedeclareerd dan moet ze klagen en ingrijpen. Indien een ICT-dienstverlener op enig punt jegens opdrachtgever niet aan haar verplichtingen voldoet of buiten de opdracht werkt, dan moet opdrachtgever ingrijpen. Hoe intensiever de opdrachtgever bij de werkzaamheden betrokken is, des te meer hij in een eerder stadium moeten aangeven dat niet wordt voldaan aan zijn wensen.[7] Echter, mag de opstelling niet zodanig zijn dat opdrachtgever zelf aan bijdraagt dat de te verrichte werkzaamheden niet alsnog tot enig resultaat kunnen leiden en tot enige vorm van afronding kun komen.

Samenwerken en testen

Kenmerkend voor de Agile-methodiek in softwareontwikkeling dat opdrachtnemer en opdrachtgever als team moeten samenwerken. Het testen wordt in het algemeen gedaan door de opdrachtgever en ook als zodanig overeengekomen. Juist doordat de opdrachtgever de sprints test, wordt aan de hand van de test-feedback door verfijning duidelijk wat de ICT-dienstverlener als opdrachtnemer precies moet maken. Het goed uitvoeren van de testwerkzaamheden door opdrachtgever is voor de voortgang en het welslagen van het project dus van groot belang.

5        Algemene zorgplicht ICT-dienstverlener

De overeenkomsten tussen partijen bij een ICT-project kunnen hoofdzakelijk worden gekwalificeerd als een overeenkomst van opdracht (artikel 7:400 BW). Voor de vraag of een ICT-dienstverlener is tekortgeschoten in de nakoming van de overeenkomsten dient te worden nagegaan of zij de zorg van een goed opdrachtnemer in acht heeft genomen (artikel 7:401 BW). Daartoe is maatgevend of ICT-dienstverlener gehandeld heeft met een mate van zorgvuldigheid en deskundigheid die van een redelijk handelend en redelijk bekwaam vakgenoot (automatiseringsdeskundige) geëist mag worden. Wat dit concreet inhoudt, is afhankelijk van de omstandigheden van het geval (HR 7 maart 2003, ECLI:NL:HR:2003:AF1304).

6        Agile-zorgplichten ICT-dienstverlener

Wat is de reikwijdte van de zorgplicht(en) van ICT-dienstverlener bij Agile-methodiek? Op basis van de tot nu toe beschikbare jurisprudentie tracht ik het kader van de Agile-zorgplichten te schetsen die de rechtspraak tot nu toe heeft gegeven. De Agile-zorgplicht valt in te delen in twee fasen, te weten de fase voor het sluiten van de overeenkomst en de fase tijdens de uitvoering van een project.

Voor de fase voor het sluiten van de overeenkomst heeft ICT-dienstverlener de zorgplicht om opdrachtgever voldoende te informeren dat met de Agile-methodiek gewerkt wordt en wat dat inhoudt.

Voor de fase gedurende het project heeft ICT-dienstverlener de zorgplicht om opdrachtgever voldoende te betrekken als haar klant, goed te communiceren met opdrachtgever en het project goed te managen.

Uit de jurisprudentie zijn een aantal bijzondere zorgplichten van ICT-dienstverlener te destilleren die ik kwalificeer als Agile-zorgplichten. Hieronder een chronologisch overzicht van de bijzondere Agile-zorgplichten van de ICT-dienstverlener die tot nu in de rechtspraak te vinden zijn.

7        Schuldeisersverzuim bij Agile

Een Agile-project kan ook niet slagen als een opdrachtgever niet voldoende medewerking verleent. In dat geval kan er sprake zijn van een schuldeiserverzuim. Echter, voor schuldeisersverzuim dient ICT-dienstverlener voldoende te onderbouwen dat het eigen handelen van opdrachtgever heeft belemmerd dat ICT-dienstverlener kon nakomen of haar tekortschieten kon herstellen en dat om die reden sprake zou zijn van schuldeisersverzuim als bedoeld in artikel 3:58 van het Burgerlijk Wetboek. ICT-dienstverlener dient voldoende aan te voeren om de conclusie te rechtvaardigen dat opdrachtgever aan het project onvoldoende medewerking heeft verleend, ook dient voldoende toegelicht te worden dat het gestelde nalaten aan de kant van opdrachtgever van wezenlijke invloed is op het welslagen van het project.

[1] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBOVE:2019:159 r.o. 4.5 Kanttekening: In deze zaak lijkt de rechter niet zo goed te weten hoe de algemene leerstukken toe te passen op Agile-methodiek, waardoor de conclusies met de bril van nu ietwat verwarrend overkomen als je kijkt naar de onderstaande bijzondere zorgplichten uit de recente jurisprudentie. De rechter komt niet toe aan de vraag over zorgplicht ICT-dienstverlener.

[2] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBLIM:2017:6767 r.o. 2.3

[3] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBMNE:2014:5516 r.o. 4.28

[4] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBOVE:2019:159 r.o. 4.13

[5] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBNHO:2021:11291 r.o. 4.11

[6] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBGEL:2013:BZ9618 In deze zaak speelde ook de verzekeringsvraag: Valt Agile onder de dekking beroepsaansprakelijkheid. Het overschrijden van termijn wat bijna inherent is aan Agile werd door de verzekeraar gezien als ondernemersrisico die niet onder de dekking valt. Maar thans speelt dit denk ik minder omdat Agile wijdverbreid is en bekend is. Je kunt mijns inziens niet meer zeggen dat het een ondernemersrisico is.

[7] https://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBNHO:2021:6513 r.o. 5.4