Al in 2013 heb ik op IT en Recht gepubliceerd over hoe contracten voor agile systeemontwikkeling er uit zouden moeten zien. Vandaag de dag is het thema nog net zo actueel als vijf jaar geleden. Dat merk ik, omdat nog steeds regelmatig gevraagd wordt naar het model agile contract, dat ik destijds beschikbaar heb gesteld. Hoewel agile systeemontwikkeling inmiddels een stevige basis heeft in de IT wereld, is het verbazingwekkend hoe veel misverstanden over en slechte implementaties van agile bestaan. Het is daarom zinvol eerst duidelijk te maken waarom agile contracten nu zo anders zou moeten zijn dan hoe we tien jaar geleden alles contracteerden.

 

Verschil tussen Agile en Waterval

De klassieke ontwikkelmethode voor software wordt ook wel ‘waterval’ genoemd. Die naam is afgeleid van het feit dat een project als een geheel diverse ontwikkelfases doorloopt. Fases die typisch voor komen zijn de volgende. Vaak krijgen de fases wel andere namen, maar het komt meestal op hetzelfde neer:

verschil agile en waterval

Hierna is het hele project klaar. De essentie van de aanpak is uit deze fasering af te leiden: het doel is specifieke functionaliteit te ontwikkelen en op te leveren. Het is niet de bedoeling in de softwarebouwfase nog iets aan het strategisch ontwerp te veranderen. De kans dat dit desastreus uitpakt voor het project is namelijk groot: alle tussenliggende fases moeten dan (deels) opnieuw uitgevoerd worden. Omdat projecten als dit soms een lange looptijd hebben, gebeurt het niettemin regelmatig dat inzichten en hoofddoelstellingen gedurende een project op belangrijke punten bijgesteld moeten worden. De doorlooptijd neemt daardoor meestal nog verder toe. Een ander nadeel van langlopende projecten is een late return on investment.

Agile heeft een fundamenteel andere insteek. Waar bij waterval alle functionaliteit als een samenhangend geheel wordt benaderd, gaat men bij agile uit van stapjes in een bepaalde richting. Vaak bestaan er al informatiesystemen die in gebruik zijn. Daaraan worden aanpassingen doorgevoerd die bijdragen aan de strategie maar die tegelijk direct toegevoegde waarde leveren. Zo’n stapje is klein genoeg om direct te kunnen bouwen op basis van algemene technische uitgangspunten en zonder noodzaak ontwerpen te maken. Testen, documentatie maken en ingebruikname maken horen in het afronden van een stap. Voor ontwikkeling van iets heel nieuws kan dezelfde aanpak gekozen worden: maak iets dat al direct gebruikt kan worden en neem dat in gebruik. Ga vervolgens uitbreiden. Meestal worden deze stappen ‘sprints’ genoemd.

Agile contract

Voor agile ontwikkeling leg je dus wel een richting vast waar je naartoe wilt, zowel functioneel als technisch, maar maak je geen detailontwerpen. In plaats daarvan is er een verlanglijstje waar onderwerpen die het meeste waarde direct toevoegen gekozen kunnen worden voor de volgende ontwikkelstap. Dat verlanglijstje kan gedurende een project steeds veranderen en aangepast worden aan de omstandigheden van het moment. Na iedere stap heeft het gebouwde direct toegevoegde waarde en start de return on investment. Die return is relatief hoog, omdat steeds de onderwerpen uit de verlanglijst gekozen worden met de grootste toegevoegde waarde.

Bij het samenstellen en kiezen uit de verlanglijst is de rol van de klant essentieel. Zelfs tijdens het bouwen is de klant steeds in detail betrokken. Dat het vooral de klant is die kan aangeven waarvan hij veel toegevoegde waarde verwacht, is een voor de hand liggende. Betrokkenheid tijdens het bouwen voorkomt dat er iets uit komt dat precies niet de bedoeling was. En zonder ontwerpen is die kans natuurlijk nog wat groter dan zonder, tenzij de relevante mensen direct kunnen ingrijpen als het iets lijkt te worden dat niet de bedoeling was.

 

Contracteren

Contracten voor watervalprojecten volgen het ontwerpproces. In essentie wordt de levering van functionaliteit gecontracteerd. De oplevering van de diverse fases is essentieel: steeds wordt specifieker wat de klant op het eind precies krijgt, dus is acceptatie van iedere processtap van belang.

Bij agile contracten wil je je juist niet vastleggen op de te ontwikkelen functionaliteit. Doe je dat wel, dan is feitelijk geen sprake van agile ontwikkeling: Een functioneel ingestoken contract betekent dat geen sprake is van een agile project. Dit is een fout die veel gemaakt wordt: definiëren van een functionele behoefte die dan uitbesteed wordt met het verzoek het ‘agile’ te ontwikkelen. Zou je dit doen, dan zou je in feite iedere sprint afzonderlijk moeten contracteren. Eigenlijk moet je dan toch met ontwerpen werken, waarmee het hele idee getorpedeerd is. Wil je werkelijk agile gaan werken en het ontwikkelwerk willen uitbesteden, dan moeten er vooral afspraken gemaakt worden over hoe het ontwikkelproces er uit hoort te zien. Welke functionaliteit ontwikkeld gaat worden hoort niet thuis in de overeenkomst. Wat er wel in een agile overeenkomst moet terug komen, zijn onder meer de onderwerpen die ik hieronder bespreek.

 

Rollen

In ieder project is rolverdeling belangrijk, ook in watervalprojecten. Naast de beschrijving van de rollen is het ook van belang te beschrijven hoe de verschillende rollen interacteren. Voor een belangrijk deel kan daarvoor worden teruggevallen op standaard ontwikkelmethodes. De bekendste agile methode is Scrum, maar er kunnen ook andere methodes gebruikt worden.

 

Vergoedingen

Hoe wordt er afgerekend? Je kunt gewoon uurtje-factuurtje afrekenen en dat is wellicht prima als je als klant overal heel dicht op zit, de leverancier kunt vertrouwen en geen gebakkelei wilt over de rekeningen. Het is echter mogelijk dat je als klant meer zekerheid wilt. Je kunt dan bijvoorbeeld werken met functiepunten, of vergelijkbare complexiteitsindicatoren, waaraan je een prijs hangt.

 

Kwaliteit

Het is essentieel afspraken te maken over de opleveringskwaliteit en over de wijze waarop die wordt gemeten. Kwaliteit gaat voornamelijk over toekomstige onderhoudbaarheid van de software. Het gaat over kwaliteit van de code die geleverd wordt, over de documentatie die er bij wordt ontwikkeld en over testmethodes. Dit zijn allemaal prijsverhogende afspraken. Maak je ze echter niet, dan ontstaat al zeer snel een lock-in die nauwelijks meer te overkomen is. Met andere woorden: je zit vast aan de ontwikkelaars die alles gebouwd hebben. Dat is om diverse redenen vaak zeer onwenselijk. Nieuwe mensen toevoegen aan het team is veel makkelijker en goedkoper als de kwaliteit op deze punten hoog is.

Sommige software wordt gebouwd in de wetenschap dat hij na twee jaar bijvoorbeeld al weer overbodig is. In dergelijke gevallen kunnen dit soort kwaliteitsafspraken uiteraard achterwege blijven. Als het echter gaat om business software die in een organisatie gebruikt gaat worden, dan zijn termijnen van 20 jaar of meer gebruikelijker en is onderhoudbaarheid cruciaal.

 

Strategie

Naast de meer technische kwaliteitsaspecten, is de strategische betekenis van het project als geheel belangrijk. Wat moet de afnemer na verloop van tijd strategisch kunnen doen met de software wat hij nog niet kon? En waaraan moet de te ontwikkelen functionaliteit systematisch bijdragen? Bij het formuleren van het verlanglijstje en het waarderen daarvan in termen van toegevoegde waarde, kan dit een belangrijke rol krijgen. Het is zaak dat goed te verankeren in het project. Anders is de kans groot dat er software ontwikkeld wordt die helemaal niet bijdraagt aan de strategie of die zelfs bijdraagt aan ontwikkeling in een tegengestelde richting.

 

Conflictresolutie

Bij agile projecten wil je dat alles snel door loopt. Is er onenigheid over het afrekenen, over de kwaliteit of over rolvervulling, dan moet dat snel en effectief worden opgelost en een agile contract moet daarin expliciet voorzien. Je kunt denken aan een door beide partijen vertrouwde onafhankelijke derde die op de achtergrond het project volgt en bij conflict een mening kan geven die de status van ‘bindend advies’ zal krijgen. Interne escalatie kan ook (binnen beide partijen gelijk op lopend). Als hiervoor wordt gekozen, moet dergelijke escalatie snel kunnen en het senior niveau moet bereid zijn snel tot compromissen te komen. Voordeel van de externe expert is, dat de oplossing geen compromis hoeft te zijn, wat bij interne escalatie meestal wel het geval is. Als een derde in een agile contract wordt aangewezen, dan moeten er ook afspraken gemaakt worden hoe die derde geïnformeerd blijft gedurende het project en hoe de betaling van de expert geregeld wordt. Eén van de partijen laten betalen leidt tot potentiële partijdigheid. Dat moet worden voorkomen.

 

Overige bepalingen

Bovenstaande bepalingen zijn specifiek voor agile contracten. Daarnaast moeten er uiteraard zaken worden geregeld die in alle ontwikkelcontracten voor komen. Denk aan wie het auteursrecht krijgt en wie eventueel (al dan niet) specifieke licenties op de software krijgt, en wat die precies in houden. Ook garantieafspraken, vrijwaringen tegen IP inbreukclaims en aansprakelijkheidsbeperkingen horen er in thuis. Verder vertrouwelijkheid, beëindiging, personeelsbescherming etc. Als de leverancier bij data kan komen, dan is waarschijnlijk een (beknopte) verwerkersovereenkomst nodig. De inhoud van al deze afspraken moet uiteraard aansluiten bij de meer specifieke agile aspecten van een agile contract.

Modelcontract

Het model voor een agile contract is overigens to downloaden via de volgende link:

Meer informatie?

Neem vrijblijvend contact op met onze advocaat

Geef een reactie