Werkt uw onderneming volgens de agile-methode? Houdt er dan rekening mee dat u als IT-provider in zekere mate wél verantwoordelijk bent voor de eindprestatie. Daarbij heeft u ook een waarschuwingsplicht als die eindprestatie in gevaar komt door allerhande wijzigingen tijdens in het ontwikkelproces.
Werkt uw onderneming volgens de agile-methode? Houdt er dan rekening mee dat u als IT-provider in zekere mate wél verantwoordelijk bent voor de eindprestatie. Daarbij heeft u ook een waarschuwingsplicht als die eindprestatie in gevaar komt door allerhande wijzigingen tijdens in het ontwikkelproces. Dat oordeel gaf een rechter recent over een IT-project.
Voordat ik tot de bespreking van de uitspraak kom, eerst kort de definitie van agile. Want wat is dat ook alweer? Agile is in de kern een methode waarbij flexibel wordt gewerkt en waarbij de grenzen worden bepaald door een aantal principes. Het doel is om binnen korte processen iets gedaan te krijgen als team. De details worden gedurende die processen vaak pas duidelijk.
De agile-methode wordt in het bijzonder gebruikt door IT-bedrijven. Over de voordelen en nadelen van deze werkwijze is al het nodige geschreven, en bijna standaard wordt ervoor gewaarschuwd dat gedurende het ontwikkelproces onduidelijkheid kan ontstaan over het doel en het eindproduct.
Dan nu de zaak waarin de rechter onlangs moest beslissen. Het bedrijf Dream Bid schakelt DPDK in om een goed werkend digitaal veilingplatform en een daaraan gekoppelde app te creëren. De overeenkomst bepaalt dat de ontwikkeling van het platform volgens de agile-methode zal plaatsvinden. Aan de start van elke sprint zal een termijn betaald worden door Dream Bid. Er zijn in totaal oorspronkelijk zes termijnen.
Gedurende het project verzoekt Dream Bid aan DPDK verschillende keren om wijzigingen aan het platform aan te brengen. Voor deze werkzaamheden moet DPDK extra werkzaamheden verrichten die ook steeds worden gefactureerd en door Dream Bid worden betaald.
Helaas zijn er steeds complicaties rondom de lancering en na herhaaldelijk uitstel van de lancering komt het uiteindelijk tot afstel. Het platform blijkt namelijk zodanige gebreken kennen dat het niet operationeel kan draaien. Als dat duidelijk is, komt DPDK eerst pas met de mededeling dat de huidige architectuur van het platform door alle wijzigingen – die op verzoek van Dream Bid zijn doorgevoerd – niet meer geschikt is om het biedingsproces van de veiling goed te ondersteunen. Dit kan ook niet meer worden hersteld. DPDK biedt om die reden twee opties aan Dream Bid: 1) de bouw van het platform wordt volledig opnieuw gestart. Dit kost Dream Bid dan € 130.000 extra en duurt nog weer vier maanden; en 2) partijen stoppen de samenwerking waarbij nog nadere afspraken gemaakt moeten worden over een vergoeding voor de overdracht van de geschreven software.
Dream Bid laat het daar niet bij zitten en deelt via haar advocaat mee dat zij recht heeft op een goed werkend platform tegen de al betaalde gelden en dat de twee opties dus onacceptabel zijn. Ze eist dus nakoming. Aan die sommatie wordt door DPDK geen gehoor gegeven en het komt vervolgens tot een procedure waarin zij schadevergoeding vordert van € 769.000,- vanwege het gebrekkige platform.
Het meest inhoudelijke verweer van DPDK is dat vanwege agile-methode en op grond van de overeenkomst niet al op voorhand duidelijk is geweest wat het eindproduct was dat zij op diende te leveren. Verder zijn op verzoek van Dream Bid steeds wijzigingen doorgevoerd, waardoor nu achteraf blijkt dat het platform daardoor niet deugdelijk functioneert. Daarmee komt het feit dat het platform dus niet goed werkt dus voor haar rekening maar voor die van Dream Bid.
De rechtbank overweegt vervolgens dat van DPDK als redelijk zorgvuldig handelend IT-provider mag worden verwacht dat het platform bij de lancering van zodanige kwaliteit is dat het een acceptabele prestatie kan leveren, en in ieder geval niet dat pas bij de lancering wordt meegedeeld dat het platform niet operationeel kan en dat een complete rebuild nodig is. Dit geldt ook als de wijzigingen tot gevolg hebben dat het platform niet meer deugdelijk werkt. In dat geval had DPDK al veel eerder daarvoor moeten waarschuwen, en wel direct toen duidelijk werd dat implementatie van de verzochte wijzigingen zou leiden tot een gebrekkig platform. Dit heeft zij niet gedaan.
Het feit dat een agile -werkwijze is gevolgd en dat dus onduidelijkheid bestond over het eindresultaat maakt dat niet anders. Weliswaar is dan nog niet alles van begin af aan uitgekristalliseerd, maar dat laat de waarschuwingsplicht van DPDK volgens de rechtbank onverlet. Daarbij laat de rechtbank – mijns inziens terecht – zwaar wegen dat DPDK als IT-bedrijf de deskundige partij is en moet kunnen zien aankomen bepaalde wijzigingen mogelijk leiden tot aantasting van de functionaliteit van het platform.
De uitspraak illustreert goed dat het gebruik van de agile-methode op zichzelf niet betekent dat er geen goed functionerend eindproduct opgeleverd hoeft te worden. Daarbij valt op dat van de IT-provider wordt verwacht dat deze de klant echt bij de hand neemt tijdens het ontwikkelproces. De waarschuwingsplicht betekent immers dat de IT-provider voortdurend op haar hoede moet zijn van de gevolgen van verzochte wijzigingen. Dit kan zelfs betekenen dat de IT-provider de ontwikkeling moet stopzetten als bepaalde wijzigingen de functionaliteit van het uiteindelijke product in gevaar brengt. Tot slot laat de zaak daarmee eveneens de kwetsbaarheid van de agile-methode zien.
