Juristen mogen wel eens wat minder zuur doen over Agile methodieken

Een bijdrage van Walter van Holst, Mitopics.

Onlangs organiseerde de NVvIR een studiemiddag over de juridische aspecten van Agile methodieken, meer in het bijzonder Scrum. Opvallend genoeg reageren veel IT-juristen in het veld uiterst sceptisch op deze (relatief) nieuwe manieren om software te ontwikkelen. Dit was in 2010 (IT 164) al niet
anders, toen zowel tijdens het Europese ITechLaw congres als tijdens het SCL jaarcongres dit onderwerp aan de orde kwam, maar het lijkt soms dat juristen hun dienende rol uit het oog lijken te verliezen.

Agile methodieken kenmerken zich door een iteratief ontwikkelproces zonder dat dit voorafgegaan wordt door een al te uitvoerige specificatiefase. Het zou overigens verkeerd zijn om te suggereren dat er geen andere methodieken dan het klassieke watervalproces van SDM (wikipedia) en de Agile methodieken zouden bestaan. Er zijn nog een waaier aan methodieken die niet klassiek waterval zijn, maar doorgaans wel uitgaan van een hogere mate van specificatie vooraf dan de Agile methodieken doen. Bijvoorbeeld de door Mitopics voorgestane proeftuinen bij pakketimplementaties zijn een voorbeeld van het niet zuiver op de waterval-manier aanpakken van projecten. Juist doordat bij een proeftuin een concrete (en betaalde) mini-implementatie plaatsvindt, wordt het mogelijk om het specificeren vooral te concentreren op de organisatiespecifieke inrichtingskeuzes van het pakket en/of eventueel aanvullend maatwerk in plaats van een tijdrovende gedetailleerde specificatie én worden de verwachtingen van de gebruikers al vroegtijdig bijgesteld.

Een fundamenteel knelpunt bij met name maatwerkontwikkeling dat de Agile methodieken proberen te adresseren is dat met name bij grotere projecten het opstellen van een nauwkeurige specificatie dusdanig tijdrovend is dat de bedrijfsomgeving en –processen alweer veranderd zijn tegen de tijd dat de specificatie geïmplementeerd is. Enigszins karikaturaal gesteld is er een reëel risico dat het project conform specificatie opgeleverd is, maar de specificatie niet langer aan de bedrijfsbehoeften voldoet. Of nog scherper: is er 100% kans dat datgene wat opgeleverd is niet datgene is wat de organisatie wenst.

De Agile methodieken trachten dit te adresseren door in korte iteraties te werken waarbij aan het einde van iedere iteratie concreet prototype wordt opgeleverd aan de gebruikers. Het voordeel hiervan is dat er gedurende het hele project er heel veel bijstuurmomenten waarop eventuele verschillen tussen verwachtingen en realisatie geredresseerd kunnen worden. Dit naast dat de methodiek veel en intensief overleg tussen de teamleden voorschrijft. Nadeel is echter dat er bij een geschil veel minder houvast is voor de afnemer om aan te tonen dat de leverancier tekort is geschoten in de gecontracteerde prestaties. De kans dat de overeenkomst als een inspanningsverbintenis en niet zozeer als een resultaatsverbintenis wordt gekwalificeerd is levensgroot. En dat voelt voor een IT-jurist, zeker een die al wat langer meeloopt, als een terugkeer naar de jaren ’80 van de vorige eeuw waarin er door leveranciers veelal op basis van uurtje-
factuurtje, met alle projectrisico’s voor de afnemer van dien, werd geopereerd.

Dat neemt niet weg dat Agile methodieken wel degelijk zinvol kunnen zijn. Om te beginnen gaan veel van deze methodieken, o.a. Scrum, er van uit dat de opdrachtgever na iedere iteratie de opdracht kan beëindigen, zonder opgaaf van reden. Daarmee wordt iedere iteratie in zekere zin een go/no-go moment, wat een stevige druk op leverancier legt om het vertrouwen van opdrachtgever te behouden.

Daarnaast leert de praktijk dat de gebruikers het eindresultaat wat er komt doorgaans wel als ‘goed genoeg’ ervaren, ook al is het iets anders dan de verwachtingen waar ze het proces mee ingingen. Vanuit onze kernwaarde van pragmatisme zien we dan ook een methode die kennelijk goede resultaten oplevert, ook al zijn die resultaten niet van te voren goed bepaald.

Vanuit de diendende rol van de jurist zien wij dan ook niet dat de moeite die juristen met dit model hebben doorslaggevend zou mogen zijn om een Agile methodiek af te wijzen. Als de risicobeheersing via een ontwikkelmethodiek tot een lager risicoprofiel leidt kan het heel wel verdedigbaar zijn om een hoger juridisch risicoprofiel te accepteren. Het resultaat telt uiteindelijk.

Dat neemt niet weg dat Agile methodieken geen ‘zilveren kogel’ zijn voor de euvels van automatiseringsprojecten. Meer nog anders vereist het een stevig opdrachtgeverschap, met daarbij een nadrukkelijk en duidelijk mandaat voor de betrokkenen vanuit de opdrachtgeversorganisatie, met inbegrip van een mandaat om de doelen van het project vast te stellen. Juist bij middelgrote organisaties waarin het lang niet altijd haalbaar is om mensen langdurig vrij te maken voor een automatiseringsproject, wat toch een randvoorwaarde is voor veel Agile methodieken, moet men zich afvragen of een pakketimplementatie met een proeftuin niet meer haalbaar is. Zeker ook omdat dit vaak organisaties zijn waarin veel maatwerkontwikkeling toch al snel een onevenredig hoge investering voor de organisatie oplevert. Maar voor grotere organisaties of in organisaties met dusdanig unieke eisen dat een substantiële maatwerkinspanning vereist is, zijn deze methodieken zeer zeker interessant om in overweging te nemen.

De conclusie voor IT-juristen is dan ook dat ze zich vooral moeten gaan concentreren op de vraag hoe partijen tot formeel geaccordeerde acceptatiecriteria kunnen komen die bij dergelijke Agile methodieken passen en minder hoe zij aan ontwikkelaars op kunnen leggen dat er toch specificaties vooraf komen.

Een aantal maatregelen die een Agile contract in ieder geval zal moeten bevatten zijn:

• Een proces om tot overeenstemming over de projectdoelen te komen, dat wil zeggen: doelen in termen van (technische) effecten waar de opdrachtnemer zich ook aan kan committeren;
• Formele vastlegging van de beëindigingsbevoegdheid van opdrachtgever na iedere iteratie;
• Consequenties die opdrachtnemer mag verbinden aan een te lage beschikbaarheid van
  medewerkers van opdrachtgever;
• Nadrukkelijke informatie- en signaleringsverplichtingen van opdrachtnemer over de zogenaamde ‘burn down chart’ (wikipedia), juist deze biedt een permanent inzicht over de beheersbaarheid van het project;
• Een helder moment waarop de acceptatiecriteria van de laatste iteratie definitief komen vast te liggen, bijvoorbeeld bij de voorlaatste iteratie.

Hoe dan ook, een ‘klassiek’ automatiseringscontract op een Agile project toepassen gaat niet werken, het is echter wel degelijk mogelijk om ook nog enige juridische zekerheden te scheppen naast de verbeterde commerciële en inhoudelijke zekerheden.