Hoe stel je een goed Agile/Scrum contract op?

Een Agile contract bepaalt niet wat het op te leveren resultaat moet inhouden. Juristen hebben dan ook moeite om een Agile contract te duiden en op te stellen. Immers zijn verplichtingen vooraf niet duidelijk te fixeren of bepaalbaar te maken, en dat maakt de afdwingbaarheid lastig. Een Agile contract vraagt een andere manier van denken.

De nadruk ligt bij een Agile contract op een beschrijving van het proces en het voorkomen van problemen tijdens het ontwikkelproces. Belangrijk is dat wordt vastgelegd hoe geldige beslissingen worden genomen, en welke beslissingen een contractuele status hebben. In dit artikel zal ik een aantal belangrijke onderdelen benoemen, die in een Agile contract niet mogen ontbreken.

Projectdoelstelling

Het contract moet een bepaling bevatten over de doelstelling van het project, of een bijlage waarin dat is opgenomen. De projectdoelstelling beschrijft het doel wat de opdrachtgever met de software wenst te bereiken en hoe de functionaliteit kan bijdragen aan de bedrijfsprocessen. De projectdoelstelling is het vertrekpunt voor het samenstellen van de Product Backlog en zal gedurende het project als ijkpunt worden gebruikt. Zorg daarom ook dat de projectdoelstelling zorgvuldig is omschreven. In tegenstelling tot watervalcontracten is een projectdoelstelling niet geformuleerd in vast omlijnde definities, maar wordt de gewenste uitkomst beschreven (outcome over output). De projectdoelstelling biedt aan het einde van het ontwikkeltraject in die zin de mogelijkheid om te toetsen of het ontwikkelingsresultaat voldoet.

De uitwerking van de projectdoelstelling vindt plaats door het ontwikkelen van de Product Backlog. Wijzigingen of aanpassingen van de projectdoelstelling gedurende het ontwikkelproces hebben dan ook direct gevolgen voor de Product Backlog. Het contract moet daarom voorzien wie de projectdoelstelling bindend mag wijzigen en hoe de gevolgen daarvan worden geregeld. Hetzelfde geldt voor de Product Owner, die aanpassingen doet in items van de Product Backlog of de prioritering aanpast. Bepaal contractueel wie dergelijke wijzigingen mag doen en welke gevolgen dat heeft. Mag dit alleen als het aantal benodigde Sprints niet wijzigt? Of alleen als het aantal benodigde tijd uitgedrukt in punten gelijk blijft? Wat zijn de gevolgen voor de prijs? Op al deze vragen moet het contract duidelijkheid geven. Geeft het contract geen duidelijkheid, dan zal de zorgplicht van de softwareleverancier zwaarder gaan drukken.

Proces

De Scrum methodiek voorziet in een verdeling van het werk in Sprints. Het contract moet een regeling bevatten hoe de Sprints worden vormgegeven. Hoelang duren de Sprints? En hoe wordt de inhoud van de Sprints vormgegeven (planning, uitvoering en oplevering). Daarnaast moet het contract de volgende punten bevatten:

  • Bepaal dat de lengte van de Sprint gefixeerd is. Alles wat niet gerealiseerd kan worden, wordt onderdeel van de volgende Sprint en opgenomen in de Product Backlog;
  • Bepaal dat gedurende de Sprint het item uit de Product Backlog niet kan worden aangepast;
  • Hoe wordt vastgesteld hoeveel items er in een Sprint kunnen worden ontwikkeld?
  • Wat zijn de gevolgen van het weigeren van het Sprintresultaat of herstelwerk dat doorgeschoven wordt naar een volgende Sprint?

Als er tijdens een ontwikkelproces wordt gewerkt met een stuurgroep, neem in het contract dan een duidelijke beschrijving op van de projectorganisatie, wie in welke hoedanigheid deelneemt en wat de verantwoordelijkheden en bevoegdheden zijn. Dit is voornamelijk van belang om vast te stellen welke partijen contractueel bindende beslissingen mogen nemen. Is bepaald dat de stuurgroep scopewijzigingen mag doorvoeren ten opzichte van de contractuele scope, dan is de stuurgroep dus bevoegd contractueel bindende beslissingen te nemen.

In het verlengde hiervan ligt de aanbeveling dat in het contract wordt opgenomen hoe de besluitvorming wordt gedocumenteerd en wie zich bezighoudt met contractmanagement. In de praktijk zie ik dat beslissingen onvoldoende gedocumenteerd worden, zodat niet duidelijk is wat de actuele status is van het project.

Project Team

De Scrum methodiek kent globaal drie rollen: De Scrummaster, de Product Owner en het Ontwikkelteam. Van elk van deze rollen moet contractueel worden vastgelegd wat deze inhouden en welke verantwoordelijkheden daarbij horen. Leg vast dat de Product Owner een vertegenwoordiger is van de opdrachtgever en door de opdrachtgever wordt ingezet. Het is belangrijk daarbij op te nemen dat de Product Owner voldoende ervaring heeft met Agile/Scrum en geschikt is voor het project en ook voldoende ingezet kan worden tijdens het project. Ook het takenpakket moet omschreven worden: de verantwoordelijkheid voor het ontwikkelen en prioriteren van de Product Backlog. Van groot belang is dat er een Product Owner wordt ingezet, die voldoende mandaat heeft om beslissingen te nemen over de Product Backlog en de prioritering. Een Product Owner die onvoldoende mandaat heeft, is een risico voor de voortgang van het project.

Elk lid van het Development Team moet voldoende ervaren zijn om de software te kunnen ontwikkelen. Deze garantie moet de leverancier kunnen geven. Uit het oogpunt van de opdrachtgever moet opgenomen worden dat de leden van het Development Team gedurende het project beschikbaar zijn en niet zullen worden verplaatst of elders worden ingezet. Zijn er bepaalde personen van het Project Team onmisbaar, neem dan de garantie op dat zij gedurende het project beschikbaar blijven. Voorzie daarbij ook in een regeling voor de gevolgen als belangrijke teamleden uitvallen of elders worden ingezet.

Budget

In de meeste gevallen valt de budgetbewaking onder de verantwoordelijkheid van de Product Owner, omdat hij de prioritering uitvoert en de inhoud van de Sprints grotendeels bepaald. Zo heeft hij invloed op de inzet van het overeengekomen budget. In de praktijk wordt echter vaak bepaald dat het Project Team gezamenlijk de inhoud van de Sprints vaststelt en verantwoordelijk is voor de Product Backlog. In dat geval worden verantwoordelijkheden van de Product Owner gedragen door het hele Project Team. Dit heeft tot gevolg dat budgetbewaking een verantwoordelijkheid wordt van het Project Team. Rechters kennen in dat geval voor de leverancier hoofdverantwoordelijkheid voor budgetbewaking toe, met de gedachte dat de leverancier het beste zicht heeft op zijn eigen personeel en de gerealiseerde software (lees hierover meer in mijn eerdere artikel). Kortom, wordt budgetverantwoordelijkheid niet duidelijk bij een Scrumrol ondergebracht of vloeit budgetverantwoordelijkheid voort uit gezamenlijke verantwoordelijkheid voor de Sprintplanning en de Product Backlog, dan zal de leverancier hoofdverantwoordelijk zijn voor het budget. Maak hier vooraf dus duidelijke afspraken over.

Rapportage

In het verlengde van budgetverantwoordelijkheid liggen de afspraken over de rapportage van het ontwikkelingsproces. Als de budgetverantwoordelijkheid bij de opdrachtgever ligt, moet deze in staat zijn om daadwerkelijk het budget te kunnen beheersen. Goede rapportage per Sprint is dan essentieel. Lees meer over deze zorgplicht in mijn eerdere artikel. Zo kan een opdrachtgever het project controleren en (bij)sturen. Leg vooraf dus vast hoe er gerapporteerd wordt over elke Sprint en welke onderdelen daarin worden opgenomen. Een aanduiding van het ‘percentage of completion’ in verhouding tot de stand van het budget, is een belangrijk onderdeel. Denk ook aan het signaleren van risico’s bij de ontwikkeling die van invloed zijn op termijnen, budget of functionele mogelijkheden. Maar ook een verslag van het ontwikkelproces is belangrijk. Heeft de opdrachtgever voldoende personeel beschikbaar gesteld? Wat was de bereikbaarheid? Deze onderwerpen zijn van belang om tijdig verstoringen in het proces waar te nemen, zodat de opdrachtgever in staat is tijdig maatregelen te nemen of om nodige resources op te schalen.

Defenition of Done

Elke succesvolle afronding van een Sprint zorgt voor werkende software. De vraag is, wanneer zijn de items tijdens de Sprint succesvol ontwikkeld? Met andere woorden, wat is de Defenition of Done? Het contract moet daarom voorzien in een regeling waarbij wordt bepaald wanneer een item is ontwikkeld en wordt geaccepteerd. Daarin moet onder andere zijn opgenomen:

  • Op welke wijze wordt er getest en wat is de omvang/aard van de testen (functionele testen, niet-functionele testen, gebruikersvriendelijkheid, snelheid). Vergeet hierbij niet dat de gerealiseerde software zelfstandig goed kan werken, maar soms niet kan integreren in het groter geheel;
  • Hoe zijn niet-functionele eisen meetbaar te maken en hoe wordt bepaald waar deze eisen aan moeten voldoen?
  • Of de documentatie is opgesteld en voldoet;
  • Op welke wijze de code wordt gereviewd;
  • Wie zijn er aanwezig bij de Sprintreview en wie kunnen besluiten dat voldaan is aan de Defenition of Done?
  • Wat zijn de gevolgen van het niet accepteren van de Sprint? Hierbij kan een regeling voor geschiloplossing een optie zijn, om een deadlock tijdens het project te voorkomen;
  • Wat betekent het niet accepteren van de Sprint voor eventueel verschuldigde termijnen? Komen de ontwikkelkosten van de betreffende Sprint dan voor rekening van de leverancier? 

Prijstelling

Leverancier en opdrachtgever hebben in de praktijk een tegenovergesteld belang bij prijsstelling. Een opdrachtgever ziet het risico op budgetoverschrijding het liefst afgedekt met een fixed price, terwijl de leverancier daar weinig voor voelt. Bij Scrum contracten zijn er diverse prijsmethodes mogelijk, een vaste prijs per Sprint, item of user story, of een vast budget waarmee een aantal door de opdrachtgever vast te stellen items kunnen worden gerealiseerd. In de praktijk zijn er veel soorten prijsstellingen mogelijk. Het contract moet daarom duidelijk beschrijven welke prijsstelling wordt toegepast en wat deze prijsstelling inhoud. De termijnen en de opeisbaarheid van de verschuldigde prijs, mogen daarbij niet ontbreken.

Als er een fixed price per Sprint is opgenomen, moeten een aantal zaken ook gefixeerd worden. Op welke capaciteit is de fixed price gebaseerd, etc.? Als er onvoldoende elementen worden gefixeerd, is een vaste prijs een bron van conflicten, omdat dan niet duidelijk is wat er voor de vaste prijs geleverd gaat worden. Daarnaast is ook belangrijk op te nemen hoe de vaste prijs zich verhoud tot wijzigingen in de scope of de Product Backlog.

Beëindigingsscenario’s

Het ligt niet altijd voor de hand om aan het begin van een veelbelovende samenwerking na te denken over de beëindigingsscenario’s. Toch is dit een belangrijk onderdeel. Denk vooraf na over de volgende zaken:

  • Onder welke omstandigheden mogen beide partijen het contract beëindigen?
  • Heeft de opdrachtgever het recht om na afronding van elke Sprint het contract te beëindigen?
  • Wat zijn de gevolgen van beëindigen voor de reeds ontwikkelde software? Moet de opdrachtgever het reeds geleverde vernietigen of weer ter beschikking stellen aan de leverancier?
  • Wat zijn de financiële gevolgen van een voortijdige beëindiging?
  • Is er voorzien in een methode van geschilbeslechting? Snelle geschilbeslechting kan ertoe leiden dat een contract niet wordt beëindigd en dat de ontwikkeling door kan gaan. Is dat niet mogelijk, dan is het verstandig vooraf na te denken of er gekozen wordt voor arbitrage of de gewone rechter.

Conclusie

De bovengenoemde punten zijn uiteraard geen uitputtende omschrijving van zaken die in een goed Agile contract moeten worden opgenomen. Ze geven naar mijn mening echter wel de kern van een goed Agile contract weer. Zorg daarom dat het Agile contract ten minste deze onderdelen bevat, zodat discussies en geschillen al in een vroeg stadium opgelost kunnen worden of zelfs helemaal niet aan de orde hoeven te komen.