Het ontwikkelen van software met Agile methodiek, wint veel aan populariteit. Er zijn veel software leveranciers die zich inmiddels alleen maar toeleggen op het Agile ontwikkelen van software en zich niet of nauwelijks meer richten op traditionele ontwikkelmethodes.
Veel softwarecontracten zijn daarentegen gebaseerd op Waterfall-principes. Requirements en specificaties worden in deze contracten vaak tot in detail uitgeschreven, om de leveringsverplichting van de softwareleverancier te vast te stellen.
Veel softwarecontracten zijn daarentegen gebaseerd op Waterfall-principes. Requirements en specificaties worden in deze contracten vaak tot in detail uitgeschreven, om de leveringsverplichting van de softwareleverancier te vast te stellen. Een uitgebreide acceptatieregeling ontbreekt meestal ook niet in het contract. De behoefte om in het contract de verplichtingen en het ‘product’ zoveel mogelijk uit te schrijven en vast te stellen, is een behoefte die veel juristen hebben. Begrijpelijk, want alleen dan is de vraag naar wat, wanneer, afdwingbaar is, goed te beantwoorden.
Hoe anders is de praktijk van Agile softwareontwikkeling, waarbij projecten worden gestart zonder in beton gegoten specificaties en soms zonder een concreet einddoel of tijdspad. De behoefte aan flexibiliteit en wendbaarheid is groot, om zo te komen tot het eindproduct dat voldoet aan de wensen van de opdrachtgever. De sterke focus op het proces in plaats van op het resultaat, vraagt om een andere juridische blik en uitwerking van contracten.
In de komende vier artikelen zal ik stil staan bij de vraag hoe een Agile proces juridisch vormgegeven moet worden. Hoe bepaal je of Agile een geschikte methode is? Welke zorgplichten heb je als softwareleverancier? Wat zijn de risico’s? Hoe vertaal je het ontwikkelproces naar een goed contract? In dit eerste artikel zal ik ingaan op de vraag waarom Agile software ontwikkeling zich moeilijk lijkt te verdragen met het opstellen van een contract. Agile stelt immers samenwerking met de klant boven contractonderhandelingen: “Customer collaboration over contract negotiation”
Het contract
Vanuit een juridische bril bekeken is een contract de weergave van de afspraken die tussen partijen zijn gemaakt. Aan het papier worden de rechten en plichten over en weer toevertrouwd. Dit om enerzijds duidelijkheid te creëren over de relatie tussen partijen en anderzijds om bepaalde rechten en plichten afdwingbaar te maken. Juist bij geschillen is het contract het vertrekpunt om de juridische positie te bepalen en prestaties bij een rechter af te dwingen. In deze zin is een contract dus een belangrijk document.
Bij het opstellen van contracten hebben juristen de neiging om rechten en plichten zoveel mogelijk uit te schrijven en te fixeren. Het contract zou daardoor – idealiter – onder alle omstandigheden duidelijkheid moeten geven over de afdwingbaarheid van verplichtingen. Garanties, specifieke eigenschappen, deugdelijkheid, etc. worden daarom exact omschreven, evenals ‘what if’ situaties. Contracten zijn daarmee een statisch geheel waarbij geen plaats is voor tussentijdse wijzigingen, aanpassingen en scope-veranderingen.
Het is daarom begrijpelijk dat het Agile Manifesto samenwerking met de klant boven contractonderhandelingen stelt. Een goed contract draagt in de Agile-visie niet bij aan het realiseren van software die zoveel mogelijk voldoet aan de wensen van de klant. Maar deze visie brengt het gevaar met zich mee dat er te weinig aandacht wordt besteed aan een goed Agile contract. Juist bij Agile softwareontwikkeling is een passend contract belangrijk.
Een goed Agile contract moet namelijk uitsluitsel geven over de beslissingsbevoegdheid van partijen, de verantwoordelijkheden over en weer, scopewijzigingen, snelheid van ontwikkelen, kwaliteit, meetbaarheid, projectorganisatie, etc. Een Agile contract is anders gezegd een procesbeschrijving van hoe partijen de software zullen gaan ontwikkelen, waarbij de focus op het resultaat een ondergeschikte rol speelt. In de komende artikelen zal ik verder ingaan op de specifieke onderdelen van een Agile contract.
Voortraject
Een goed opgesteld Agile contract kan in de praktijk tot een mislukt softwareontwikkelingstraject leiden en is daarmee geen garantie voor een succesvol project. Het traject voorafgaand aan het ondertekenen van een contract is namelijk minstens net zo belangrijk.
In de rechtspraak heerst de opvatting dat de relatie tussen een opdrachtgever en een softwareleverancier per definitie ongelijk is. Een ongelijke relatie betekent dat de softwareleverancier zorgvuldig moet handelen en een zorgplicht heeft richting de opdrachtgever. Deze zorgplicht is niet alleen van belang tijdens de ontwikkeling, maar juist in het proces daarvoor. Bij het kiezen voor een Agile-methode, moet de softwareleverancier onderzoeken of Agile past bij de opdrachtgever. Kan hij er mee werken? Zijn er voldoende deskundige personen beschikbaar bij de opdrachtgever? Begrijpt de opdrachtgever de verschillende rollen en bij behorende verantwoordelijkheden? De softwareleverancier moet nadenken over deze vragen en de opdrachtgever hierin begeleiden. In het volgende artikel zal ik hierop verder in gaan.
Proces
Een gezegde luidt: “Een contract is al gedateerd als de handtekening wordt gezet”. Tijdens de ontwikkeling is het dus van groot belang dat het contract steeds actueel is en passend bij de huidige samenwerking. Contractmanagement en administratie zijn van essentieel belang. Ook een deugdelijke procesbeschrijving mag in een Agile contract niet ontbreken. Op deze wijze is op verschillende momenten vast te stellen wat de overeengekomen scope is, het ontwikkelingsresultaat en welke bindende beslissingen zijn genomen. Ontbreekt een duidelijk proces, dan ontstaat tijdens het proces onduidelijkheid over wat de overeengekomen scope is. Welke functionaliteit is toegevoegd of juist verwijderd? Wie van de betrokken partijen mag bindende beslissingen nemen? Dergelijke vragen kunnen met een goed Agile contract worden voorkomen.
Geschillen
Als er tijdens het project een patstelling ontstaat die niet te overbruggen is, komt het contract vaak weer naar boven uit het onderste laatje. De vraag is dan of het contract nog actueel is? Is het aangepast gedurende het project? Zijn de afspraken en keuzes goed vastgelegd en gedocumenteerd? De praktijk leert helaas dat dit vaak niet het geval is. Het bepalen van de juridische positie is in een dergelijk geval een lastige kwestie.
Conclusie
Bij een Agile ontwikkelproces is niet alleen het contract van groot belang, maar juist ook het voortraject en de uitvoering van het project. Daarnaast moet de focus van een Agile contract liggen op de beschrijving van het proces en moet het contract steeds actueel zijn. Een softwareontwikkelaar moet daarbij bewust zijn van zijn zorgplichten richting de opdrachtgever. De relatie is niet gelijk, wat in de praktijk anders kan voelen. De ongelijke relatie brengt strenge zorgvuldigheidseisen voor de softwareleverancier met zich mee. Bewustwording daarvan is een belangrijke stap.
Geschreven door onze partner Heijink en Meure