Complexiteit IT-projecten
Voor de complexiteit van IT-projecten zijn allerlei redenen. Denk hierbij aan:
- technische uitdagingen (codekwaliteit, datakwaliteit, interoperabiliteit);
- organisatorische uitdagingen (inpassen in een bestaande organisatie, mensen meekrijgen, is de organisatie of het systeem leidend);
- financiële uitdagingen (de business case rondkrijgen, een goede balans tussen prijs en kwaliteit);
- planningsissues;
- Etc.
Ook de enorme mogelijkheden van software leiden tot complexiteit. Flexibiliteit lijkt immers prachtig (alles is mogelijk), doch daar schuilt juist ook de valkuil in: voor je het weet ontstaat een maatwerkproject dat op termijn niet meer te onderhouden is.
Beheersbaar houden van projecten
In de loop der tijd zijn er dan ook allerlei verschillende methoden ontstaan om softwareprojecten beheersbaar te houden.
Een klassieke methode is wat veelal ‘waterval’ wordt genoemd: vooraf alles uitdenken en uitwerken en het daarna (als een waterval) over de organisatie uitstorten bij de implementatie. Een lange voorbereiding dus en vervolgens alleen nog uitvoeren.
Tegenwoordig wordt er veel met agile/scrum (-achtige) methodes gewerkt, die juist niet uitgaan van alles vooraf uitdenken, maar juist in korte intervallen software ontwikkelen of inrichten en daarbij voortdurend bijsturen. In deze methode is het eindresultaat vooraf niet altijd bekend. Het is zelfs goed denkbaar dat het eindresultaat van een ‘sprint’ (een ontwikkelinterval) nog bij lange na niet af is en dat na het testen van een sprint de eisen voor de volgende sprint weer worden gewijzigd. In extremo doorgevoerd is dit dus een totaal flexibele methode.
Wat koop je bij agile?
De agile-/scrummethodes zijn als gezegd populair. In plaats van te werken met uitgebreide programma’s van eisen (PvE’s) waar iedereen wat van moet vinden, werk je bij agile veel ‘korter op de bal’ en is het vaak overzichtelijker wat er nu precies gebeurt.
Bij die agile-/scrum-methodes is echter wel de vraag: wat koop je nu precies? Koop je slechts een werkwijze in, of mag je toch ook wel (in enige mate) het beoogde eindproduct verwachten? En als je slechts een proces inkoopt, waar kun je dan de leverancier op aanspreken?
Wat betekent het bijvoorbeeld dat er in het proces zit ingebakken dat je eigenlijk voortdurend weer met nieuwe sprints het resultaat bijstelt? Als je van te voren als afnemer aanvaardt dat een bug in de software geen tekortkoming is, maar hooguit een aanleiding om de takenlijst (backlog) weer aan te vullen, heb je dan wel een spreekwoordelijke stok om mee te slaan als het niet lekker loopt?
Wisselend beeld in de rechtspraak
Dat roept de vraag op hoe hierover in rechte wordt geoordeeld.
Ondertussen hebben we een paar kwesties over agile voor de rechter gehad. De eerste die ik kon vinden stamt alweer uit 2014, de meest recente van dit jaar. Onderaan deze blog vat ik de kwestie kort samen.
In grote lijnen valt het volgende op:
- Veel wordt aangenomen dat er slechts een werkwijze is aangekocht en dat de leverancier (dus) niet op een eindproduct is aan te spreken;
- Wel wordt in sommige kwesties aangenomen dat aangezien het proces beoogt om per sprint iets op te leveren, dat de levering wel kan worden aangesproken op nakoming daarvan.
- In sommige kwesties wordt aangenomen dat de agile werkwijze meebrengt dat de klant kan meekijken en dus ook zelf kan ingrijpen.
- In wat meer kwesties wordt echter aangenomen dat de agile werkwijze niets af doet aan de zorgplicht van de leverancier en dat van de leverancier dus bijv. verwacht mag worden dat de sprintplanning realistisch is, dat de leverancier waarschuwt bij wensen van de klant die verkeerd kunnen uitpakken of dat de leverancier rekening houdt met de beoogde verlangde einddatum.
Het beeld is al met al nog best wisselend; een eenduidige lijn valt nog niet echt te ontdekken.
Aandachtspunten
Het is voor de praktijk dus van belang vooraf goed na te denken over wat nu eigenlijk de bedoeling is en om dat helder vast te leggen. In een paar bullets:
- Wat: wil je een bepaald resultaat, of is het resultaat nog onvoldoende bepaald en is het beter een proces in te kopen? Bedenk goed dat deze wat-vraag heel bepalend is voor wat er is af te dwingen.
- Hoe: afhankelijk van het antwoord op de wat-vraag ligt het antwoord op de hoe-vraag vaak ook wel voor de hand (doch zeker niet altijd): in de regel is een waterval-achtig proces logischer als de scope toch al helder is en een meer flexibele benadering passend voor een open einde project.
- Wanneer: deadlines verenigen zich in de regel lastig met flexibiliteit. Overdenk hier dus goed wat nu precies wenselijk en haalbaar is.
- Waarborgen: bij allerlei vormen ligt het voor de hand allerlei waarborgen in te bouwen. De optie tussentijds te stoppen kan altijd verstandig zijn, ongeacht methode (maar wellicht niet commercieel haalbaar). Weet dat het bij meer flexibele methodes soms de enige optie is om echt eenvoudig van het contract af te komen (want wijs maar eens een tekortkoming aan als je slechts een proces inkoopt). Bij meer resultaatgerichte afspraken ligt tussentijds stoppen minder voor de hand (maar pas op dat je moet wachten tot de trein die je al ziet ontsporen ook daadwerkelijk ontspoort; afhankelijk van de juridische kaders kan het zijn dat preventief afbreken is weggecontracteerd).
- Kosten: vaste prijzen verenigen zich in de regel lastig met flexibiliteit. Overdenk hier dus goed wat nu precies wenselijk en haalbaar is. Kostenbewaking kan wel bij alle methodes iets zijn om afspraken over te maken.
Conclusie
Agile en scrum zijn populair. Uit de rechtspraak rijst echter ook wel een beeld op dat menig afnemer bij agile-/scrumprojecten niet altijd doorheeft wat er nu precies gecontracteerd is en wat dit ook van hem als afnemer vergt. Bedenk dus goed vooraf wat er precies benodigd is en welke kaders het best passen bij het voorliggende project. Dit zodat een wendbaar project niet een ongrijpbaar project wordt, dan wel een waterval project niet iets om in te verzuipen. Neem gerust contact op bij vragen.
Ten slotte: samenvatting Agile rechtspraak
In de rechtspraak zien we verschillende oordelen terugkomen
Rechtbank Midden-Nederland in de kwestie Netrom / Flexservice
Er is afgesproken agile/scrum te werken en er werden geen eindresultaten gedefinieerd. In die context omvat de verplichting weinig meer dan het ter beschikking stellen van bekwame ontwikkelaars die zich inspannen om conform het ontwerp en met inachtneming van de zorgplicht van een goed opdrachtnemer software te ontwikkelen. Uitgangspunt is dan ook dat indien het opgeleverde niet voldoet, dat dan de inspanningen om het alsnog te laten voldoen gewoon meerwerk zijn. Dit kan anders zijn indien de leverancier zich niet gehouden heeft aan de afspraken of de zorgplicht niet heeft nageleefd. De bewijslast voor dit verweer berust bij opdrachtgever. Het enkele feit dat het eindproduct qua performance niet voldoet aan de wensen van de opdrachtgever is (dus) onvoldoende om te kunnen spreken van een tekortkoming. ECLI:NL:RBMNE:2014:5516, Rechtbank Midden-Nederland, C-16-341704 - HA ZA 13-258
Rechtbank Midden-Nederland in de kwestie Eage Support / Hinttecht
De bedoeling van een sprint in de agile/scrum methode is dat er aan het einde van de sprint een deelproduct wordt opgeleverd. In casu blijkt dat er geen enkel deelproduct is opgeleverd. Dat er niet meer betaald werd leidt dus niet tot schuldeisersverzuim, want de facturen zijn nooit opeisbaar geworden. De leverancier had na sprint 0 behoren te weten hoeveel resterend werk er (ongeveer) vereist zou zijn. Dat vervolgens de kosten ruim verdubbelen zonder tussentijdse waarschuwing is dan ook onaanvaardbaar. ECLI:NL:RBMNE:2017:1429, Rechtbank Midden-Nederland, C/16/418108 / HA ZA 16-460
Rechtbank Noord-Holland in de kwestie Betty Blocks / VGB
Het behoort tot de zorgplicht een ondeskundige afnemer te begeleiden in het testen. En ook op te treden als er kennelijk miscommunicatie ontstaat bij het testen. Tegelijkertijd is de ontbinding niet gerechtvaardigd over de periode waarin de afnemer zelf onvoldoende medewerking verleent om tot afronding van het project te komen. ECLI:NL:RBNHO:2018:10021, Rechtbank Noord-Holland, C/15/268092 / HA ZA 17-892
Gerechtshof Amsterdam in de kwestie Vancis / ROC Noord Kennemerland
In de aanbesteding en de overeenkomst is uitdrukkelijk gevraagd om een gedetailleerd projectplan. In de aanbesteding is ontkennend geantwoord op de vraag of het projectplan op een ander framework mocht worden gebaseerd. Gelet hierop is het enkele feit dat leverancier inschrijft met de mededeling agile te werken dan ook op zichzelf niet al voldoende om daaruit een afwijking van de gestelde eisen te mogen afleiden. ECLI:NL:GHAMS:2020:46, Gerechtshof Amsterdam, 200.240.712/01
Rechtbank Noord-Holland in de kwestie Vloerkledenwinkel / Pixelindustries
Er is onvoldoende onderbouwd dat de einddatum als fatale datum bedoeld was. Dat wordt nog eens versterkt door de gekozen agile werkwijze, waarbij fatale einddata minder voor de hand liggen. https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBNHO:2021:11291
Rechtbank Noord-Holland in de kwestie Trive
Gelet op de agile werkwijze waarbij de werkzaamheden werden geadministreerd in een voor iedereen toegankelijk programma, had de klant kunnen en moeten ingrijpen indien het werk ondermaats was. Verweren die erop gebaseerd zijn dat iets anders was afgesproken zijn onvoldoende onderbouwd. ECLI:NL:RBNHO:2021:6513, Rechtbank Noord-Holland, 8957864
Hof Arnhem-Leeuwarden in de kwestie XO Investment / Media Artist
Sprints en betalingen zijn in nadere afspraak zo specifiek aan elkaar gekoppeld dat er resultaatsafspraken zijn gemaakt. Het niet tijdig opleveren van een overeengekomen sprint leidt zodoende tot verzuim. ECLI:NL:GHARL:2021:11398, Gerechtshof Arnhem-Leeuwarden, 200.283.251
Rechtbank Rotterdam in de kwestie Dream Bid / DPDK
Een agile/scrum methodiek doet aan de waarschuwingsplicht (zorgplicht) van de leverancier niets af. Wanneer de leverancier redelijkerwijs kan zien aankomen dat de door de klant gewenste wijzigingen niet haalbaar zijn, dan moet zij waarschuwen. ECLI:NL:RBROT:2022:1641, Rechtbank Rotterdam, C/10/617519 / HA ZA 21-387 en ECLI:NL:RBROT:2022:8322, Rechtbank Rotterdam, C/10/617519 / HA ZA 21-387
Rechtbank Noord-Nederland in de kwestie Trivento / Unimeld
De agile werkwijze doet aan de zorgplicht niets af. Een deskundige zal dan ook moeten beoordelen of het opgeleverde werk voldoet aan hetgeen je van een bekwaam leverancier in de gegeven omstandigheden mag verwachten. https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBNNE:2022:2581
Rechtbank Midden-Nederland in de kwestie Synergy Systems / IPS
De toegezegde totale doorlooptijd van het project is te zien als een (fatale) termijn die niet gehaald is, zodat verzuim is ontstaan. Gelet op de aard van de samenwerking (scrum) waaruit volgt dat bij niet halen deadlines er nieuwe afspraken worden gemaakt en het gegeven dat het project bijna is afgerond, rechtvaardigt dit verzuim echter nog niet de ontbinding. ECLI:NL:RBMNE:2023:5936, Rechtbank Midden-Nederland, C/16/519101 / HA ZA 21-213
Rechtbank Overijssel in de kwestie Heigo / Webstores
Gelet op de context van contractering is geen eindproduct gecontracteerd, maar ontwikkelcapaciteit. Dat is een inspanningsverbintenis, geen resultaatsverbintenis. Ten aanzien van het gebruik van vermeend verouderde (hulp)software heeft de opdrachtnemer voldoende gewaarschuwd. ECLI:NL:RBOVE:2023:2138, Rechtbank Overijssel, C/08/288374 / HA ZA 22-401
Gerechtshof Amsterdam in de kwestie On Air / Triple IT
In deze kwestie moest er voor 30 juni 2021 een alternatieve front-end zijn ontwikkeld. De agile werkwijze brengt dat er niet op voorhand harde afspraken zijn over eindproduct en einddatum, maar dat laat onverlet dat partijen wel (in abstracto) een bepaald eindresultaat beoogden (namelijk die front-end). Vandaar dat een deskundige moet beoordelen of het redelijkerwijs nog mogelijk was geweest die datum te halen en zo nee, wat daarvan dan de primaire oorzaak is. https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:GHAMS:2024:1070
Rechtbank Amsterdam in de kwestie gemeente Amsterdam / ARS Traffic & Transport Technology
Het project loopt niet lekker. De overeengekomen agile werkwijze wordt op een gegeven moment losgelaten en er wordt een concrete planning voor oplevering voorgesteld. Aangezien die planning niet wordt gehaald en ook na ingebrekestelling nog steeds niet gehaald, mocht de gemeente ontbinden. De gemeente heeft echter onvoldoende onderbouwd welk deel van de facturen ziet op de agile ontwikkeling van de applicatie. De rechtbank kan daarmee ook niet beoordelen wat er (vermeend) te veel betaald is, dus die vordering wordt afgewezen. Evengoed heeft de leverancier onvoldoende onderbouwd om tot bijbetaling te komen. ECLI:NL:RBAMS:2025:507, Rechtbank Amsterdam, C/13/741517
Rechtbank Amsterdam in de kwestie over e-commerce platform
Na een eerste overeenkomst die zag op een eindproduct voor een vaste prijs, sluiten partijen een nieuwe overeenkomst waarbij agile/scrum wordt gewerkt. Uit het verloop blijkt dat de eerste overeenkomst niet meer relevant was en louter de tweede overeenkomst nog gold. Duidelijk is ook dat die tweede vorm van samenwerking (agile/scrum) veel meer van beide partijen verlangt. Of er gelet op die partijverhouding sprake is van een tekortkoming kan de rechtbank nu niet beoordelen, daar is een deskundigenbericht voor nodig. ECLI:NL:RBAMS:2025:365, Rechtbank Amsterdam, C/13/744940 / HA ZA 24-48
