Agile en contracten

ICT-bedrijven maken bij het ontwikkelen van software vaak gebruik van agile methoden, waarmee ze in iteraties van een aantal weken software ontwikkelen en door eindgebruikers laten testen. Vooraf is er wel een ruw idee van het einddoel, maar de precieze invulling hiervan ontstaat tijdens het proces. Dat proces wordt voortdurend bijgestuurd aan de hand van veranderende wensen, nieuwe inzichten en tussentijdse testresultaten. De keuze voor agile methoden ligt voor de hand, omdat de meeste ICT-projecten te complex zijn om vooraf het eindresultaat precies te kunnen definiëren, wat flexibiliteit tijdens het ontwikkelproces noodzakelijk maakt.

Overheden daarentegen gebruiken vaak nog steeds de watervalmethode, waarbij de specificaties volledig worden vastgelegd voordat men met de bouw van de software start. Ook al blijkt keer op keer dat deze methode niet geschikt is voor ICT-projecten, voornamelijk omdat gedurende het ontwikkelproces niet tegemoet kan worden gekomen aan veranderende wensen en inzichten. Het resultaat is vaak dat de ontwikkelde software niet voldoet aan de wensen van de opdrachtgever en de eindgebruiker en dat de techniek van het product bij de afronding van het project al verouderd is. Volgens ons zou de overheid gebaat zijn bij het vaker inzetten van agile methoden, mits de agile principes op de juiste manier geïmplementeerd worden en de overheid het ontwikkelproces strak regisseert.

Agile

De term agile slaat op een aantal principes voor softwareontwikkeling, waarbij flexibiliteit en het inspelen op veranderende omstandigheden voorop staan. De agile principes zijn neergelegd in het Agile Manifesto en luiden als volgt:

• Mensen en hun onderlinge interactie gaan boven processen en hulpmiddelen
• Werkende software gaat boven allesomvattende documentatie
• Samenwerking met de klant gaat boven contractonderhandelingen
• Inspelen op verandering gaat boven het volgen van een plan

Deze principes zijn uitgewerkt in verschillende methoden en werkwijzen. In dit artikel gebruiken we Scrum als voorbeeld van een agile werkwijze die ook voor overheden geschikt is.

Bij Scrum werkt men aan de hand van begrippen zoals user story, epic, use cases, product backlog, sprint en definition of done. Een user story is een korte omschrijving van wat een gebruiker wil, geformuleerd in een vaste structuur: ‘Als […] wil ik […], zodat […]’. Grotere wensen, epics genoemd, worden behapbaar gemaakt door ze op te delen in user stories. Use cases zijn lijsten met sets van interacties die een systeem moet kunnen aangaan met andere systemen en met gebruikers. De product backlog is een lijst van user stories op volgorde van prioriteit, weergegeven op een bord met post-its of in een digitale omgeving. Vaak wordt per user story een inschatting gemaakt van de verwachte hoeveelheid werk en de waarde die het zal opleveren, op basis waarvan de return on investment (ROI) wordt berekend. Per iteratie oftewel sprint wordt een aparte takenlijst afgewerkt, de sprint backlog. De sprint backlog maakt inzichtelijk welk werk moet worden verricht om de sprint met succes af te ronden. In de definition of done worden de voorwaarden vastgelegd waaraan moet zijn voldaan om een willekeurige user story als afgerond te kunnen aanmerken. Per user story kunnen bovendien specifieke acceptatiecriteria worden opgesteld.

Anders dan men soms denkt, sluiten agile en contracten elkaar niet uit. Het maken van (schriftelijke) afspraken is onderdeel van de agile methodiek. In Scrum worden afspraken vastgelegd in onder meer de product backlog, user stories, epics en de definition of done. Daarnaast is het sowieso essentieel om een agile ontwikkelproces in te kaderen en het einddoel te bewaken. Contracten zijn hier zeer geschikt voor. In vergelijking met de watervalmethode komt het accent bij agile contracten wel ergens anders te liggen, namelijk bij het inrichting van het werkproces in plaats van bij de functionaliteiten van het te ontwikkelen systeem.

Risico’s

Voor agile methoden gelden een aantal specifieke kenmerken en risico’s, waar rekening mee moet worden gehouden bij de inrichting van projecten en het opstellen van contracten.

Het loslaten van specifieke doelen waaraan de opgeleverde software moet voldoen, kan in het slechtste scenario uitmonden in een situatie waarin de leverancier zonder consequenties kan falen. Een gebrek aan oplettendheid in de voorbereiding of latere fases kan leiden tot een onevenredige verdeling van verantwoordelijkheden en risico’s.

Dat dit geen denkbeeldig risico is, blijkt uit de Nederland ICT Voorwaarden van de branchevereniging van de Nederlandse ICT-sector. Het accepteren van deze voorwaarden kan nadelig uitpakken voor afnemers, aangezien de artikelen over agile wel heel duidelijk ten faveure van ICT-leveranciers zijn geschreven. Zo aanvaardt de afnemer op grond van artikel 36.3 het risico dat de opgeleverde werken “niet noodzakelijkerwijs aan alle specificaties zullen beantwoorden”. Artikel 36.4 bepaalt dat de afnemer de software accepteert “in de staat waarin deze zich op het moment van het einde van de laatste ontwikkelfase bevindt (‘as is, where is’)”. Op grond van datzelfde artikel is de leverancier “na de laatste ontwikkelfase niet gehouden tot herstel van fouten, tenzij schriftelijk anders overeengekomen”. Dit onderstreept het belang van heldere afspraken over de precieze inrichting van de agile werkwijze, dus de randvoorwaarden voor het ontwikkelproces.

Bovendien is het zaak om een balans te vinden in de hoeveelheid vast te leggen afspraken. Wanneer contracten te specifiek of te uitgebreid zijn of wanneer er te veel contracten worden afgesloten, gaat dit ten koste van de flexibiliteit waar agile om draait. Aan de andere kant kan het vastleggen van te weinig zaken leiden tot het ontslaan van leveranciers van hun verantwoordelijkheden, zoals hierboven opgemerkt. Dan wordt een agile contract een vrijbrief tot falen.

Ook het verkeerd implementeren van agile principes brengt risico’s met zich mee. Wanneer een te lange lijst met taken (user stories) ontstaat en deze lijst niet wordt ingekort of de taken doelmatig worden gegroepeerd, verliest men het overzicht over het project, verslapt de prioritering en raakt de scope van het project buiten zicht. De voordelen van de agile methodiek zijn dan teniet gedaan.

Een ander risico ligt in het slecht of niet documenteren van IT-systemen. Dit leidt tot problemen met de onderhoudbaarheid van een systeem en tot vendor lock-in. Ook de kwaliteit van de code heeft een grote invloed op de onderhoudbaarheid. Als de code en de documentatie van hoge kwaliteit zijn, kan in beginsel na elke iteratie voor een andere leverancier worden gekozen. Meestal moet de afnemer het initiatief tot afspraken over de omvang en kwaliteit van de documentatie nemen, omdat leveranciers vaak geen duidelijk belang hebben bij het opstellen van goede documentatie.

Agile contracten

Een agile contract is primair gericht op de problemen die moeten worden opgelost, zonder de oplossingen in detail voor te schrijven. Het belangrijkst is dat het proces helder omschreven wordt. In grote lijnen moet duidelijk zijn wat er moet gebeuren, zonder dat van tevoren wordt gespecificeerd hoe dit tot stand moet worden gebracht. In een korte tijd moet er tegen beperkte kosten een werkende eerste versie staan, waarbij vooraf duidelijk moet zijn waar deze minimaal aan moet voldoen. Vervolgens moet er kortcyclisch, in vaststaande termijnen, worden gewerkt aan de doorontwikkeling van het systeem en moeten nieuwe versies worden uitgebracht.

Contracten voor de ontwikkeling van IT-systemen bestaan vaak uit een raamcontract en losse contracten voor alle iteraties. Het project kan vooraf worden opgedeeld in, bijvoorbeeld, tien sprints met ieder een eigen contract, een eigen budget en een vaststaande start- en opleverdatum. Ook kan het wenselijk zijn om de afnemer de mogelijkheid te geven om de scope en prioriteiten van een lopende sprint aan te passen. Dit hoeft het budget niet te beïnvloeden als de nieuwe wensen worden uitgeruild tegen eerdere wensen.

Het is wenselijk om een aantal algemene zaken vast te leggen, waaronder:

• Toelichting op het agile proces, inclusief opdeling van het project in iteraties.
• Scope van het totale project in algemene termen, eventueel met uitsluiting van zaken zoals onderhoud en gebruikerstraining.
• Globale planning per iteratie.
• Start- en opleverdatum van elke iteratie.
• Budget per iteratie.
• Acceptatie van tussenresultaten en het eindresultaat aan de hand van vooraf gedefinieerde criteria.
• Samenstelling van het team en kwalificaties en beschikbaarheid van de teamleden.
• Rollen in het project.
• Manier van communiceren tussen (aangewezen vertegenwoordigers van) afnemer en leverancier, onder andere met betrekking tot besluitvorming en escalatie.
• Afspraken over documentatie.
• Controle op kwaliteit en naleving van afspraken, bijvoorbeeld geautomatiseerd testen van software en audits door derde partijen.
• Betalingsafspraken. Vaak wordt een bedrag per iteratie overeengekomen, maar alternatieven zoals gain & pain sharing-modellen, waarbij het bedrag afhankelijk is van de gezamenlijk geleverde prestatie, zijn ook mogelijk.
• Mogelijkheden tot voortijdige beëindiging, eventueel tegen betaling van een restsom in geval van een kleiner aantal iteraties dan gepland.
• Omgang met geschillen.

In een contract voor een afzonderlijke iteratie staan onder meer de scope van de iteratie, een gedetailleerde uitwerking van de iteratie, use cases, de product backlog, de definition of done en afspraken over de acceptatie van de software, waaronder acceptatiecriteria, (geautomatiseerd) testen en eventueel een vast moment voor acceptatie.

Conclusie

Overheden profiteren nog niet optimaal van de mogelijkheden van agile methoden voor softwareontwikkeling. Overheden zouden er goed aan doen om vaker agile methoden in te zetten, mits zij erin slagen om de agile methode op de juiste manier te implementeren en het proces zelf strak in de hand te houden. Enkele risico’s zijn de verschuiving van macht ten gunste van leveranciers, het teniet doen van de voordelen van agile door te veel of te weinig afspraken vast te leggen en problemen met onderhoudbaarheid van systemen en vendor lock-in als gevolg van een gebrekkige documentatie. Agile en contracten sluiten elkaar niet uit. Wel liggen het zwaartepunt bij agile contracten ergens anders dan bij traditionele contracten, namelijk bij het arrangeren van het werkproces in plaats van bij de specifieke eisen aan het te ontwikkelen systeem.






Bronnen:

• F. van 't Geloof, ‘Agile projecten contracteren’, ITenRecht.nl IT 1343.
• T.J. de Graaf, ‘Nederland ICT-voorwaarden: agile, SaaS, garanties en exoneraties kritisch bekeken en vergeleken’, Computerrecht 2016/2.
• P. Horsten, ‘Agile werken met een contract is meer dan pokeren alleen’, goyello.com.
• scrumguide.nl
• 18f.gsa.gov