Skip to main content

In een geschil over mislukte automatisering wordt de prestatie van de automatiseerder door de rechter vaak beoordeeld aan de hand van zijn zorgplicht. Wat houdt die zorgplicht in en wat kan dit betekenen voor Agile softwareontwikkeling? Dat is het onderwerp van dit blog.

Aanleiding is een uitspraak van de rechtbank Noord-Holland van 14 november 2018. De feiten van de zaak waren als volgt. Betty Blocks zou in 19 weken en vijf sprints een administratiesysteem voor een vastgoedbeheerder bouwen. In plaats daarvan liep het project vrij snel vast. Het lukte het vastgoedbedrijf, volgens haar bij gebreke aan begeleiding, niet om de software te beoordelen en testen. Het schortte daarop de betaling van de rekeningen van Betty Blocks op en de overeenkomst werd ontbonden. In de procedure die volgde vorderde Betty Block betaling van de achterstallige facturen en de vastgoedbeheerder schadevergoeding.

De rechtbank beoordeelde de prestatie van Betty Blocks naar de mate waarin deze aan haar zorgplicht had voldaan.

Zorgplicht IT dienstverleners

Wat houdt die zorgplicht in? De algemene wettelijke norm voor een opdrachtnemer is “minimaal handelen conform de inspanningen die van een redelijk handelend vakgenoot geëist kunnen worden”. Vertaald naar de IT dienstverlener: “de redelijk bekwaam en redelijk handelend IT-deskundige”.

De zorgplicht is een “open norm” en kan daardoor tot verantwoordelijkheden leiden die niet letterlijk in de opdracht staan beschreven. De basis van de zorgplicht is professioneel en met voldoende inzet de opdracht uitvoeren. Maar de zorgplicht kan ook een waarschuwingsplicht inhouden. Bijvoorbeeld als de wensen van de klant niet gerealiseerd kunnen worden, deze grote risico’s in zich dragen of naar verwachting tot bijkomende kosten leiden.

In januari 2017 oordeelde de rechtbank Amsterdam in een andere zaak zelfs dat de zorgplicht er toe kan leiden dat de IT dienstverlener de klant moet adviseren de overeenkomst te beëindigen of op te schorten.

Het interessante aan de zaak die voor de rechtbank Noord-Holland diende is dat er sprake was van software ontwikkeling volgens de Agile methode. Die methode beoogt te voorkomen dat automatiseringsprojecten ontsporen, onder meer doordat klant en leverancier nauw samenwerken en in korte iteraties werkende software wordt opgeleverd. Waarom voorkwam de methode hier de mislukking niet?

Agile werken: meer dan sprints doorlopen

Om de “nauwe samenwerking” mogelijk te maken is het bij Agile werken de bedoeling dat er een Product Owner wordt aangesteld. Hij of zij moet ervoor zorgen dat er waarde voor de klant wordt gecreëerd en onderhoudt contact met de stakeholders van de opdrachtgever. Aan het eind van een sprint zorgt de Product Owner ervoor dat er een ‘sprint review meeting’ plaatsvindt waarin het ontwikkelteam laat zien wat er is gemaakt en waarin items worden goed- of afgekeurd.

De rechtbank Noord-Holland stelde in de Betty Blocks zaak vast dat de zorgplicht van een IT leverancier inhoudt dat deze de klant adequaat begeleidt bij het testen. Dit gold volgens de rechtbank te meer omdat “procesmanagement tot de taken van de IT leverancier behoorde”.

Ook het begeleiden van de klant bij het testen van de software behoort normaal gesproken tot de taken van de Product Owner. Kennelijk was die in het Betty Blocks project niet aangewezen. Het was hier immers juist de leverancier die het procesmanagement op zich had genomen. Daarmee heeft Betty Blocks waarschijnlijk meer verantwoordelijkheid naar zich toe getrokken dan volgens de Agile methode de bedoeling is.

Ze had er waarschijnlijk goed aan gedaan voor de start van het project aan te dringen op de betrokkenheid van een voldoende ervaren Product Owner. In de praktijk zie ik dit bij softwareprojecten voor het MKB wel vaker achterwege blijven. Begrijpelijk, een softwarebedrijf wil opdrachten binnenhalen en mensen aan het werk houden. De betrokkenheid van een (freelance) Product Owner als (kostenverhogende) voorwaarde stellen is in dat licht geen handige zet.

Dat is het wel in het licht van de zorgplicht van de IT dienstverlener. Die dijt langzaam uit als je de jurisprudentie hierover beschouwt. Het risico dat de rekening van een mislukte automatisering bij de IT-dienstverlener komt te liggen wordt steeds groter. Met dit in het achterhoofd, is voorwaarden stellen bij het aannemen van opdrachten misschien toch niet zo’n gekke gedachte.

Wilt u na lezing van dit blog meer weten of contracteren over agile ontwikkeling of het innemen van een standpunt bij een mislukte automatisering? Ik help u graag.

Deel dit artikel op social media

[social_buttons twitter=”true” linkedin=”true”]

Contact

met Legista

Stuur mij een bericht en ik neem zo spoedig mogelijk contact met u op.




    Voor informatie over verwerking van uw gegevens verwijs ik u naar mijn Privacyverklaring