Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Agile goed contracteren komt te weinig voor

 

Computable Expert

mr.drs. Walter van Holst
IT-jurist, Mitopics. Expert van Computable voor de topics Development en Cloud Computing.

Daar waar Agile ontwikkelmethodieken bij maatwerksoftware vaak verrassend goed werken, is het minder goed gesteld met de contractvorming rondom dergelijke trajecten. Wat vooral een probleem is in die gevallen dat een Agile ontwikkeltraject mislukt.

Als eerste zijn it-contracten die aansluiten bij Agile zeer zeldzaam. In de praktijk wordt vaak naar contractdocumenten gegrepen die ooit bedoeld waren voor meer traditionele ontwikkeltrajecten. Enerzijds omdat standaardcontracten in veel organisaties het beleid zijn en die ooit opgesteld zijn voordat meer iteratieve ontwikkelmethodieken in zwang raakten. Anderzijds omdat veel it-juristen, maar ook inkopers, Agile ontwikkelmethodieken eigenlijk per definitie onjuist vinden. Maar ook omdat het Agile-manifest onder andere het volgende bevat:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Werkende software

Een contract hebben wordt daarbij door ontwikkelaars als  'niet Agile' ervaren. En dat is niet eens zo’n vreemde gedachte, want veel contracten hebben een focus op juist die onderwerpen waar men in het Agile-gedachtengoed vanaf wil. Vooraf gedefinieerde specificaties, uitgebreide planningen en budgetten, focus op processen. Want al die andere zaken zijn lastig te objectiveren. Want wat is 'm 'werkende software' nu eigenlijk?

En dat is een reden, naast gewone menselijke koudwatervrees, waarom veel juristen instinctief een afkeer hebben van Agile methodieken. Ons denken wordt nu eenmaal bepaald door de vraag 'hoe leg ik een rechter uit dat ik niet gekregen heb wat ik mocht verwachten als het project fout gaat?'. Een specificatie vooraf is de meest tastbare vastlegging van de redelijke verwachtingen van de afnemer. Maar één van de grote problemen van traditionele ontwikkelmethoden is nu juist dat de specificaties, die bij aanvang misschien klopten, bij oplevering vaak al niet meer overeengekomen met de veranderde organisatiebehoeften. Wat betekent dat meer klassieke ontwikkelmethoden haast onherroepelijk in iets resulteren wat niet meer aansluit bij de behoeften en er dus onvrede in de relatie sluipt. En Agile methoden worden juist gekenmerkt door het ontbreken van die vergaand uitgewerkte specificatie vooraf.

Ingewikkelde dossiers

In de praktijk komen echte Agile contracten minder vaak voor dan Agile projecten, en worden er vaak 'watervalcontracten' gehanteerd. En ik denk dat bovenstaande factoren daar een rol bij spelen. En voor wie zich afvraagt of dat een probleem is: ja, dat is een probleem. Want als partijen in werkelijkheid heel anders met elkaar omgegaan zijn (want Agile) dan ze gecontracteerd hebben (klassiek), dan zal de rechter in een geschil het hele contract toch anders bezien of zelfs terzijde schuiven, met alle gevolgen van dien. Ik zou zelfs willen stellen dat geen contract beter is bij Agile dan een 'watervalcontract'. Want dan zitten partijen in ieder geval niet schijnafspraken en –zekerheden die bij een uiteindelijke rechtszaak niet overeind blijven, en had men de kosten van het opstellen van het contract zich beter kunnen besparen. Niet dat het niet hebben van een contract nu heel wenselijk is, rechtszaken over mislukte ict-projecten hebben notoir onvoorspelbare uitkomsten omdat het vaak ingewikkelde dossiers zijn en de ontwikkelingen in de ict maar beperkt aansluiten bij de belevingswereld van de rechterlijke macht. Voor wie het ook redelijkerwijze niet mogelijk is om de ontwikkelingen in iedere bedrijfstak, zeker snel veranderende zoals de ict, bij te houden. Een contract is bij ict-geschillen, meer nog dan anders, een belangrijke leidraad voor rechters bij de geschilbeslechting. In de praktijk zijn ict-contracten om die reden dan ook relatief uitgebreid.

Omgekeerd is hanteren van Agile geen vrijbrief voor het afleveren broddelwerk. Of een vrijbrief om geen specificaties te hebben. Juist het vakmanschap van softwareontwikkelaars waar Agile methodieken zich zo op richten vereist het bestaan van specificaties en andere documenten. Alleen misschien als onderdeel van wat opgeleverd moet worden aan het einde van een iteratie en bij sommige methoden wordt dit per iteratie vooraf vastgelegd in de documentatie. Waartegen getest en geaccepteerd kan worden. En toch zie je dat Agile in contracten gebruikt worden als aanleiding om de leverancier te ontslaan van zijn verantwoordelijkheden. Bijvoorbeeld in de algemene voorwaarden van de branchevereniging Nederland ICT waarin gesteld wordt dat bij Agile ontwikkelmethoden de afnemer aanvaardt dat de ontwikkelde software af kan wijken van de specificaties.

Bordje van afnemer

Een andere benadering in een soortgelijke lijn die ik wel eens tegen ben gekomen is om Agile projecten maar weer als uurtje-factuurtje projecten te contracteren. Waarmee we zo’n dertig jaar aan best practices in de ict overboord gooien en het risico volledig op het bordje van de afnemer leggen.

Een goed Agile contract bevat een erkenning dat de afnemende partij niet goed in staat zal zijn de verwachtingen bij aanvang te formuleren en dat een onderdeel van de dienst de zoektocht is naar die verwachtingen (al zal er vaak nog wel een vast te leggen organisatiedoel zijn, maar dat kan wel te abstract zijn om veel baat te bieden). De uitruil van de zekerheid dat iets conform specificatie gebouwd wordt tegen een grotere kans dat wat uiteindelijk geleverd wordt beter aansluit op de organisatiebehoefte kan heel vaak door de commerciële afspraken opgevangen worden. Zo zijn er succesvolle maatwerkbouwers die op basis van Scrum (een veelgebruikte Agile methodiek) werken en hun afnemers de mogelijkheid geven om bij iedere sprint de stekker uit de relatie te trekken. Wat betekent dat het vele malen makkelijker is om ten halve te keren als het gevoel ontstaat dat er ten hele gedwaald gaat worden. Hoe dan ook, met gecombineerde juridische en commerciële creativiteit kan er een contract ontstaan wat juist de gemeenschappelijke doelstelling van werkende software in overzichtelijke stappen reflecteert.

Dit artikel is afkomstig van Channelweb.nl (https://www.channelweb.nl/artikel/5412096). © Jaarbeurs IT Media.

?

 

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.