Agile contracteren: contradictio in terminis?

Helemaal niets contractueel vastleggen is vanuit juridisch oogpunt niet aan te raden. Overigens is dit ook niet wat de opstellers van het Agile Manifesto voor ogen hadden. Het Manifesto vermeldt immers bij de vier uitgangspunten: “Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.” Het opstellen van documentatie en het maken van (schriftelijke) afspraken vormt dus wel degelijk een onderdeel van de Agilemethodiek. Dit blijkt overigens ook uit de praktijk, waarbij afspraken en requirements in onder meer de Product Backlog, epics, user stories en de Definition of Done worden vastgelegd.

De vraag is dus: waar ligt de grens tussen teveel vastleggen (en dus terugkeer naar de oude waterval denkwijze) en te weinig vastleggen (met grote onzekerheid als gevolg)?

Ik zal puntsgewijs enkele belangrijke aandachtspunten in een Agile-contract bespreken:

• In een traditionele ontwikkelovereenkomst wordt de omvang van het project (de ‘scope’) vaak strak omschreven. Op basis van de technische- en functionele specificaties worden veelal de deliverables onderscheiden, welke vervolgens ‘op papier worden gezet’. Hiermee ontstaat een contractuele verplichting voor de opdrachtnemer om deze deliverables ook daadwerkelijk op te leveren. In het kader van de Agile-overeenkomst ligt dit uiteraard gecompliceerder, aangezien de scope van het project aan constante verandering onderhevig is. In de praktijk bevat de Product Backlog min-of-meer de scope van het project. Echter, de Backlog kan steeds aangepast worden, dus kan niet als vaste scope dienen. Ook User Stories, epics, etc. kunnen gedurende het project wijzigen. Kortom, bij veel Agile-projecten is de scope nu eenmaal per definitie flexibel en kan daarom niet voor of bij aanvang van het project worden vastgelegd. Wat vaak wel mogelijk is, is om de scope per sprint/iteratie in een ‘minicontract’ vast te leggen. Verder is het mogelijk om met financiële afspraken de risico’s verbonden met een verandering in scope voor zowel de opdrachtgever als de opdrachtnemer te beperken.
• Het is gebruikelijk om in een ontwikkelovereenkomst concrete afspraken te maken omtrent de totaalprijs van het project. De vorm van deze afspraken kan verschillen; vooral ‘time & material’ en ‘fixed price’ komen zeer regelmatig voor. Aangezien de scope van het project in geval van een Agile-overeenkomst per definitie aan verandering onderhevig kan zijn, lijkt het op het eerste gezicht onmogelijk om op basis van ‘fixed price’ te werken. Dit neemt niet weg dat er weldegelijk creatieve oplossingen mogelijk zijn. Zo kan afgesproken worden dat het project wordt opgebouwd uit een (al dan niet ‘fixed’) aantal sprints, user stories of Product Backlog items. Per eenheid wordt een vastgestelde prijs afgesproken. De opdrachtgever heeft de mogelijkheid om gedurende het project de inhoud van de sprints (deels) zelf in te vullen of om bijvoorbeeld met Product Backlog items te schuiven. Er bestaan echter ook vele andere variaties, zoals ‘Variable-price, fixed-scope’ of ‘time & material’ varianten in combinatie met een ‘shared pain, shared gain model’. Ik verwijs verder naar de literatuur over dit onderwerp, waaronder van Robert Cecil Martin, één van de opstellers van het Agile Manifesto.
• In een traditionele ontwikkelovereenkomst wordt vaak de aansprakelijkheid voor schade bij de opdrachtnemer gelegd. Ook geeft de opdrachtnemer bepaalde garanties af, waarvoor de opdrachtnemer verantwoordelijkheid (lees: aansprakelijkheid) aanvaardt. Aangezien in geval van een Agile-project het eindresultaat door intensieve samenwerking tussen opdrachtgever en opdrachtnemer tot stand komt, is het in voorkomende gevallen niet redelijk (alleen) de opdrachtnemer aansprakelijk te houden voor het eindresultaat. In dit kader is van belang dat in een traditionele ontwikkelingsovereenkomst centraal staat wát uitgevoerd wordt, terwijl in een Agile-overeenkomst minstens zo belangrijk is door wie en hoe de werkzaamheden worden uitgevoerd. De overeenkomst zal om die reden afspraken moeten bevatten omtrent de samenstelling en kwalificaties van de betrokken personen. Gebruikelijk is dat in ieder geval wordt opgenomen dat de betrokkenen 100% beschikbaar zijn voor het project in kwestie; werkzaamheden in het kader van andere projecten zijn ‘verboden’. Ook wordt vaak afgesproken dat alle betrokkenen, of in ieder geval bepaalde sleutelfiguren (met name de Scrum Master en Product Owner), voor de gehele duur van het project volledig beschikbaar moeten zijn. Afgesproken kan worden dat het niet nakomen van dergelijke operationele afspraken tot aansprakelijkheid kan leiden.
• In een traditionele ontwikkelingsovereenkomst is het opstellen en overdragen van documentatie vaak één van de kernverantwoordelijkheden van de opdrachtnemer. Bij een Agile-benadering is het opstellen van documentatie veel minder belangrijk en wordt in plaats daarvan gefocust op het eindresultaat: werkende software. Toch is het van belang dat heldere afspraken worden gemaakt ten aanzien van het opstellen van documentatie, zoals bijvoorbeeld gebruikshandleidingen. Ook het opstellen en bijhouden van overige documentatie blijkt in de praktijk vaak problematisch. Zo worden afspraken (bijvoorbeeld gemaakt tijdens de Daily Scrum) vaak genoteerd op de welbekende gele memoblaadjes in plaats van een vast document. Een leesbare foto van deze aantekeningen zou een deel van de documentatie kunnen vormen, zonder dat de snelheid en effectiviteit van de Daily Scrum wordt aangetast.

Naast de hierboven genoemde punten, zijn uiteraard nog vele andere aandachtspunten te benoemen. Uiteindelijk moet bij het opstellen van een Agile-contract niet uit het oog verloren worden dat de relatie tussen opdrachtgever en leverancier in de eerste plaats beheerst wordt door wederzijds vertrouwen. De nadruk zou dan ook moeten liggen op bepalingen die een goede samenwerking stimuleren, niet juridiseren. Desondanks is het van belang dat aan een goede samenwerking een goede overeenkomst ten grondslag ligt. Immers, uiteindelijk vormt flexibiliteit voor beide partijen een voordeel, maar onzekerheid voor beide partijen een risico…

Indien u vragen heeft naar aanleiding van dit artikel, kunt u contact opnemen met Natascha van Duuren (partner & advocaat IT/Privacy/Cybersecurity).