Een standaard juridische overeenkomst gebruiken voor een Agile-samenwerking is “niet oké”. Dat is ongeveer net zo’n grote mismatch als pizza en ananas.
De term Agile verwijst naar een aantal beginselen voor software-development, waarbij een flexibele houding en het inspelen op veranderingen voorop staan. Het Manifesto for Agile Software Development verwoordt dit het duidelijkst:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Alhoewel Agile vooral in de ICT-sector gebruikt wordt, zien we dat men ook ook steeds vaker in andere sectoren (bijvoorbeeld in marketing!) geïnteresseerd is in deze manier van werken. Helaas vergeet men nog wel eens dat een Agile manier van werken, ook Agile contracten nodig heeft. Zo dient het contract ruimte te bieden aan het iteratieve (“tussentijds opleveren”) karakter van Agile en ervoor te zorgen dat – zonder dat elke keer een nieuwe handtekening nodig is – partijen makkelijk kunnen inspelen op veranderingen of nieuwe inzichten.
Tegelijkertijd moet je natuurlijk wel het scenario voorkomen dat de opdrachtnemer zonder enige nadelige gevolgen kan falen. Een eerlijke verdeling tussen risico’s en verantwoordelijkheden is geen overbodige luxe.
Kanttekening: sommige developers beschouwen contracten per definitie als “non-Agile”. Gezien het stelselmatige gebruik van traditionele contracten bij Agile-samenwerkingen, is deze weerstand best te verklaren. Traditionele contracten zien immers vaak juist op die elementen (vooraf gedefinieerde functionaliteiten, e.d.) die niet bij Agile passen. Agile wordt namelijk juist gekenmerkt door een flexibele aanpak en het ontbreken van dergelijke specificaties. Een goed Agile-contract biedt ruimte aan deze flexibele aanpak.
Check eerst of Agile wel bij jullie past
Misschien een beetje flauw maar toch geen overbodige luxe om nog eens te herhalen: Agile is geen wondermiddel en is zeker niet voor elk IT-project de juiste methode. Het gevaar van de “Agile-hype” is dat er te pas en te onpas de Agile-methode wordt toegepast, terwijl het project wellicht beter af was geweest met de “ouderwetse” Waterfall. Voordat je enthousiasme de overhand neemt, loont het dan ook om jezelf eerst de volgende vragen te stellen:
- Hoe goed is de communicatie? Agile vereist een open dialoog en de ruimte om ook tegenslagen en / of veranderingen in inzicht “op te biechten”. Binnen het team zullen de drie 3 “key roles” (opdrachtgever, ontwikkelaars en ScrumMaster) dagelijks met elkaar moeten communiceren.
- Is het een simpel, recht-toe-recht-aan IT-project? Dan is Waterfall waarschijnlijk de betere optie. De Agile-methode is veeleisend en daarom niet altijd voordelig wanneer het een relatief simpele project betreft.
- Heeft de opdrachtgever (klant) de expertise en tijd om actief deel te nemen aan het ontwikkelingsproces (“hands on”)? Agile-ontwikkeling vraagt om een actieve houding van alle key roles. Indien de opdrachtgever nauwelijks kennis heeft van software ontwikkeling of simpelweg niet de tijd heeft om actief betrokken te zijn bij het project, is Agile waarschijnlijk niet geschikt.
Enige kennis van Agile is trouwens überhaupt geen overbodige luxe voordat je jezelf in het Agile-diepe gooit. In de praktijk zien wij vaak dat opdrachtgevers veelal wel een vaag begrip hebben van wat Agile betekent, maar echte kennis ontbreekt. Om misverstanden te voorkomen, is het nodig om vooraf een training te organiseren waarin alle “ins en outs” van Agile worden besproken. Schakelen jullie juristen in die geen tot nauwelijks kennis hebben van Agile? Laat die dan ook vooral even aanschuiven.
Leg vast hoe jullie samenwerking eruit ziet
In Waterfall-contracten wordt er veelal maar weinig aandacht besteed aan het beschrijven van de wijze waarop partijen – dagelijks – gaan samenwerken. Bij Agile staat een intensieve samenwerking juist voorop. De meeste Agile-modellen hebben daarom gedetailleerde “rules of engagement”, die de dagelijkse samenwerking in goede banen zou moeten leiden.
Beknopt: hoe gaan we samenwerken? Uitgebreid:
Afspraken over de belangrijkste rollen
Een goede – intensieve – samenwerking staat bij Agile voorop. Er zijn in totaal 3 verschillende hoofdrollen die vervuld moeten worden: de Product Owner, het Development Team en de ScrumMaster. Iedere rol heeft zijn eigen verantwoordelijkheden en (contractuele) aandachtspunten.
De Product Owner: de Product Owner vertegenwoordigt de belangen van de opdrachtgever (klant). Het is de Product Owner die de eigenaar wordt van het product en dus ook het meeste belang heeft bij een goede prijs-kwaliteitverhouding. De Product Owner neemt ook de primaire verantwoordelijkheid voor de Backlog op zich (hierover later meer). Hij bepaalt dus welke taken prioriteit hebben (en dus het eerste opgepakt moeten worden door het Development Team) en welke volgorde er moet worden aangehouden. De Product Owner houdt tegelijkertijd de voortgang van het project in de gaten en neemt deel aan meetings van het Development Team. In het licht van het bovenstaande, hoort een goed Agile-contract in ieder geval:
- duidelijk aan te geven dat de Product Owner door de opdrachtgever wordt benoemd / aangesteld. Gezien het intensieve karakter van de samenwerking tussen alle “key roles”, wilt de opdrachtnemer er wellicht zeker van zijn dat de Product Owner de juiste skills en ervaring heeft om een Agile-project te leiden. Maak hier afspraken over!
- aan te geven dat de Product Owner niet plotseling – zonder gegronde reden – mag worden vervangen door de opdrachtgever.
- duidelijke vast te leggen wat men mag verwachten van de Product Owner. Voor een succesvolle Agile-samenwerking is het immers essentieel dat de Product Owner zich echt actief inzet. Neem bijvoorbeeld afspraken op omtrent de verwachte beschikbaarheid van de Product Owner, wanneer de Product Owner op vragen van het Development Team dient te reageren, etc.
- de belangrijkste verantwoordelijkheden van de Product Owner uiteen te zetten:
- de ontwikkeling en het beheer van de Product Backlog.
- deelname aan relevante meetings met het Development Team.
- Het Development Team: Het Development Team is verantwoordelijk voor de daadwerkelijke ontwikkeling van het product. In andere woorden: het team doet het echte werk. Het team bestaat uit verschillende professionals en is zelforganiserend. Het team bepaalt dus zelf hoe – binnen elke Sprint – de geselecteerde items uit de Product Backlog worden ontwikkeld. In het licht van het bovenstaande, hoort een goed Agile-contract in ieder geval:
- de leden van het Team te benoemen en uiteen te zetten welke skills en ervaring deze leden – minimaal – dienen te hebben. Indien de leden nog niet kunnen worden benoemd, moet er in ieder geval worden opgenomen dat de opdrachtnemer de opdrachtgever – kort nadat het team compleet is – hiervan op de hoogte stelt.
- vast te leggen dat de opdrachtnemer met de samenstelling van het Development Team akkoord dient te gaan. Uiteraard moet het contract ook een oplossing bieden voor de situatie dat de opdrachtnemer geen akkoord geeft.
- vast te leggen dat de opdrachtnemer ervoor zorgt dat de professionals in het team hun volledige aandacht en toewijding aan het project kunnen geven (beschikbaar zijn).
- De ScrumMaster: de ScrumMaster kan wellicht het best nog worden omschreven als een “mentor” die ervoor zorgt dat de samenwerking goed verloopt en in overeenstemming met de Agile-methode. Zo houdt hij in de gaten of iedereen op de hoogte is van wat er moet worden gedaan, of er belemmeringen zijn die wellicht uit de weg moeten worden geholpen, e.d. In het licht van het bovenstaande, hoort een goed Agile-contract in ieder geval:
- de ScrumMaster te benoemen. Indien de ScrumMaster nog niet bij tekening van het contract is benoemd, dient het contract de wijze aan te geven waarop deze benoemd zal worden en welke skills en ervaring hij dient te hebben.
- uit een te zetten wat de verantwoordelijkheden zijn van de ScrumMaster en welke inzet er van hem wordt verwacht (beschikbaarheid, exclusiviteit, et cetera).
Afspraken over jullie planning
Leg vast hoe het “Sprint-proces” eruit gaat zien. Denk hierbij aan: hoe lang duurt elke Sprint, wanneer wordt er overlegd, et cetera. Let wel, de duur van een Sprint dient in beginsel niet te worden veranderd, zelfs indien men achterloopt op schema.
Afspraken over de documentatie
Maak in ieder geval duidelijke afspraken over de Product Backlog en de Sprint Backlog. Zoals:
- Afspraken over wanneer de – eerste versie van de – Product Backlog wordt ontwikkeld. Het Development Team dient vervolgens – per item – een schatting te maken van de vereiste inzet / inspanning die het kost om het item te ontwikkelen.
- Afspraken over de prioritisering van de verschillende items. De Product Owner moet per item aangeven hoeveel prioriteit deze heeft en moet de vrijheid hebben om de Backlog – op ieder gewenst moment – aan te passen. Deze vrijheid dient wel enigszins beperkt te worden in die zin dat er dient te worden vastgelegd dat de Product Owner niet “in z’n eentje” de schatting omtrent de vereiste inspanning mag wijzigen (welke reeds is vastgesteld door het Development Team) en dat de volgorde van de items niet veranderd kan worden op het moment dat het desbetreffende item al in ontwikkeling is als onderdeel van een Sprint.
Agile wordt dus gekenmerkt door een intensieve samenwerking tussen de 3 key roles. Het voordeel van deze aanpak is dat de focus ligt op het bevorderen van de “real time” controle over het project, in plaats van dat er pas wordt ingegrepen als er al iets verkeerd is gegaan (in andere woorden: wanneer het project al is mislukt).
Geef ruimte aan veranderingen
Een van de belangrijkste principes van de Agile-methode is dat veranderingen moeten worden toegejuicht, ook als die pas laat in het ontwikkelingsproces naar voren komen. Het contract dient daarom ruimte te bieden aan veranderingen en nieuwe inzichten. Dit doe je o.a. door:
- een te strakke vooraf afgebakende en – in detail – omschreven omvang van de te ontwikkelen software (ook wel “scope” genoemd), te vermijden. Waar er bij Waterfall-projecten met “deliverables” wordt gewerkt, is dat bij Agile niet mogelijk omdat de scope van het project juist aan continue verandering onderhevig is. Er wordt dus niet naar een specifiek eindresultaat toegewerkt. Alhoewel de Product Backlog in zekere mate de omvang van het project bevat, wordt deze – gedurende het project – steeds gewijzigd. In andere woorden: Agile heeft vrijheid nodig. Dit betekent dat een te gedetailleerde omschrijving van de scope onwenselijk is.
- Vast te leggen “hoe” er mag worden veranderd (en wat de gevolgen zijn van een dergelijke verandering, bijvoorbeeld m.b.t. de vergoeding van de opdrachtnemer).
Creëer een duidelijke definitie van Done
Agile wordt gekenmerkt door het kortcyclisch opleveren van software. In Sprints wordt er telkens een kleine stap gezet richting het einddoel (“goed werkende software”). Aan het einde van de Sprint is het resultaat van die Sprint “done”. Wanneer iets “done” is (bijvoorbeeld na het doorlopen van een geautomatiseerde test en de software aan bepaalde kwaliteitsstandaarden voldoet) en wat er gebeurt als iets niet klaar is, dient duidelijk te worden omschreven. Je kan hierbij zelfs denken aan het opnemen van een checklist in het contract. Het kan natuurlijk alsnog voorkomen dat er verschil in inzicht bestaat over of iets “done” is of niet. Het contract dient ook hiervoor een oplossing te geven.
Zorg ervoor dat jullie kunnen stoppen
We vallen wellicht een beetje in herhaling, maar voor de laatste keer: Agile draait om het stapsgewijs opleveren van resultaten. Omdat er niet een duidelijk eindpunt is vastgesteld, is het belangrijk om duidelijk in het contract op te nemen wanneer partijen de samenwerking mogen stopzetten. Mag iedere partij na elke voltooide Sprint weglopen of is dit – gezien de omvang van het project – niet realistisch? Hierbij moet rekening worden gehouden met het feit dat de opdrachtnemer wellicht veel tijd en moeite heeft gestoken in het samenstellen van het Development Team en het zodoende niet eerlijk vindt als er per Sprint kan worden opgezegd. Tegelijkertijd is een van de voordelen van Agile – voor de opdrachtgever – dat hij niet gebonden is aan langere ontwikkelingscycli. Indien er wordt afgesproken dat opdrachtgever niet per Sprint mag opzeggen, wordt dit voordeel – voor een groot deel – tenietgedaan. Er is hier dus sprake van een belangenafweging, die zorgvuldig moet worden gemaakt zodat beide partijen “tevreden” kunnen weglopen.
Opstellen agile contract door gespecialiseerde IT-juristen
Hulp nodig bij het opstellen van een agile-overeenkomst? Neem dan gerust contact met ons op of vraag direct een offerte aan.
