Op een Agile wijze een oplossing ontwikkelen voor een klant op basis van een contract dat geaccepteerd is door juristen lijkt schier onmogelijk. De traditionele manier van inkoop en contracteren past gewoonweg niet bij Agile principes. Als een project beperkt is in omvang lukt het nog wel om samen een manier te vinden om dingen vast te leggen, maar als het een groot en risicovol project betreft is de situatie anders. De klant wil immers graag weten wat hij krijgt voor het geld dat hij investeert, terwijl eigenlijk al bekend is dat zijn eisen en wensen zelden volledig gedefinieerd zijn. Binnen Goyello hebben we jaren geleden Agile al omarmd en op een gegeven moment moesten we de geschetste uitdaging dus gewoonweg een keer onder ogen zien. En achteraf kunnen we constateren dat het eigenlijk was zoals Nelson Mandela ooit heeft gezegd: “Het is altijd onmogelijk, totdat het klaar is”. 

Dit artikel is een vertaling van een eerder gepubliceerd artikel op InfoQ.

Het was een ongebruikelijke situatie

Een verzekeraar was voornemens een nieuwe ziektekostenverzekering aan te bieden, bij voorkeur binnen 6 maanden om de concurrentie voor te blijven. De reclamezendtijd was al ingekocht. De ondersteunende workflow- en communicatiesystemen voor de ondersteunende processen moesten op maat ontwikkeld worden en integratie met de bestaande polisadministratie was een must. Ondanks vele maanden werk die verricht waren door een tweetal business consultants, waren de specificaties erg onduidelijk en op diverse terreinen eigenlijk ook al weer achterhaald. 

Al met al was het hierdoor een erg ambitieus en risicovol project. 

Diverse softwareproviders brachten een offerte uit, maar de klant vertrouwde geen van hen, het prijsverschil was gewoonweg te groot. En ook was onduidelijk of de deadline echt wel gehaald zou worden. Men realiseerde dat een andere, meer Agile, aanpak gewenst was.

En dat was eigenlijk een geluk voor ons, want deze klant hoefden we dus niet van onze voorkeursaanpak te overtuigen. 

RFPs bieden veel informatie, maar beschrijven zelfden wat echt gewenst is

De klant benaderde Goyello na de initiële offertefase. De RFP bestond uit een groot aantal pagina’s technische en functionele eisen, waarbij het ons direct duidelijk was waarom er zulke diverse aanbiedingen waren opgesteld door de andere aanbieders. Te veel zaken in de RFP waren onvolledig. Essentiele functionaliteit en een gedetailleerde beschrijving van vereiste integraties met andere systemen ontbraken volledig.  

Om die hiaten in te vullen, stelden wij voor om een aantal brainstorms te organiseren met de business consultants en domeinexperts, inclusief eindgebruikers. Dit voorstel werd geaccepteerd en een aantal weken later was veel duidelijker wat de klant (en dan vooral de eindgebruikers) nu ECHT nodig hadden.

Samen bespraken we de diverse functies en taken en definieerden we gebruikersrollen, de scope van het project. Onze discussies werden samengevat in de vorm van “epics” en waar mogelijk “user stories” om op zeer begrijpelijke wijze aan de klant te laten zien hoe wij hun wensen hadden begrepen.

Door deze aanpak begreep ook de klant nu de complexiteit van hun eigen processen beter dan voor de workshops.

Pokeren om tot een projectvoorstel te komen

Is het realistisch om met elkaar een opleverdatum en een budget af te spreken als je (nog) niet precies weet wat je samen precies wilt realiseren? Het antwoord is volmondig “Ja”, maar wel alleen als je een projectaanpak overeenkomt die hierbij past en je elkaar vertrouwt.

Een Agile aanpak maakt het mogelijk.

Maar hoewel we het eens waren over de projectafbakening, keken we nog aan tegen een paar forse uitdagingen: we moesten een contract overeenkomen. Inmiddels is een framework voor Agile contracten beschikbaar, maar destijds moesten we grotendeels zelf bedenken hoe een Agile contract er uit zou moeten zien, inclusief het vastleggen van de verwachte investering.

Om heel eerlijk te zijn was dit voor ons destijds het grootste Agile project (qua financiële omvang en risico) dat we moesten gaan contracteren. Daarom besloten we op diverse manieren te begroten. Op basis van de gesprekken die we hadden gevoerd en de user stories die waren opgesteld, maakten we een inschatting van het team dat we op fulltime basis nodig zouden hebben om dit project succesvol uit te voeren. Voor de nodige onzekerheden namen we een forse buffer op. Daarnaast speelde het team ” planning poker”. Alle projectleden bepaalden samen de complexiteit van de epics en user stories door ze onderling te vergelijken. Op basis van ervaringscijfers uit andere projecten wisten we min of meer wat de ontwikkelsnelheid, de “velocity” (aantal ontwikkeluren per story point) we zouden realiseren.

Natuurlijk resulteerde beide methoden in verschillende begrotingen, maar het stelde ons in staat om beter vast te stellen welk budget echt nodig zou zijn. En eigenlijk lagen beide begrotingen na een nadere evaluatie eigenlijk niet eens heel ver uit elkaar. 

En toen begonnen de onvermijdelijke prijsonderhandelingen

Voor de klant was het door ons gepresenteerde bedrag te hoog (zoals altijd zou je kunnen zeggen). Dankzij onze volledig transparante calculatie wist de klant exact hoeveel tijd wij voor een bepaald onderdeel benodigd dachten te hebben. Dit gaf de klant het vertrouwen dat we hem niet zo maar een begroting hadden voorgelegd.

Mede door deze aanpak konden we de klant ervan overtuigen dat hun budget echt verhoogd moest worden om te realiseren wat er echt nodig was. We kwamen overeen dat het budget van de klant het zogenaamde “target budget” zou worden. Daar voegden we 40% aan toe en dat werd het maximum budget, het “cap budget”. Zodra het project (binnen de afgesproken scope) boven het target budget uit zou komen, dan zou de klant 50% van het gebruikelijke tarief in rekening worden gebracht. Ook kwamen we overeen dat we eventuele besparingen (dus onder het target budget) samen zouden delen. Boven het cap budget zouden wij gratis werken.

Vanzelfsprekend kon het budget niet gebruikt worden voor niet eerder overeengekomen eisen of wensen, tenzij de klant andere wilde laten vallen. Voor nieuwe wensen kwamen we een eenvoudig change proces overeen, zodat wensen, tegen additioneel budget direct konden worden uitgevoerd binnen het project. Deze Target-Cost-With-Cap aanpak is gebaseerd op John Rask’s article “Target Cost Contracts”.

Na dit mondeling te zijn overeengekomen startte de projectuitvoering omwille van de tijd. Het formaliseren van de samenwerking zou nog enkele maanden vergen.

Juristen heb je nodig ……

Een contract opstellen is vaak al ingewikkeld, maar een Agile project op een dusdanige wijze beschrijven dat het past binnen bestaande bureaucratische administratieve processen is een verhaal apart. Op ons verzoek stuurde de klant hun gebruikelijke inkoopvoorwaarden; we hadden beter moeten weten.

Onze huisjurist hadden we al aangeleerd om Agile te denken en ook begreep hij op hoofdlijnen onze projectaanpak. Enthousiast stelde hij een tegenvoorstel op. Na een review door de jurist van onze klant bleek dat al onze voorstellen geweigerd waren.

We concludeerden dat deze juridische itteraties tot niets zouden leiden. Daarom organiseerden wij een ontmoeting tussen de juristen van beide partijen met de businessvertegenwoordigers. De jurist van de klant werd in dit gesprek de intentie van het hele project uitgelegd en hoe we dit in het contract wilden laten terugkomen.

Dat hielp!

Opstellen van het contract

We besloten om een raamovereenkomst af te sluiten, waarbinnen we projectcontracten zouden benutten voor de diverse onderdelen van het te ontwikkelen system. Het raamcontract omvatte behalve de algemene inkoop/verkoopvoorwaarden regels als:

  • De scope van het project, zijnde het ontwikkelen van een software-oplossing, waarbij zaken als onderhoud, beheer, gebruikersdocumentatie & -training, etc. werden uitgezonderd.
  • Opdeling van het project in releases (sub-projecten).
  • Globale release planning.
  • Uitleg van het Agile proces, inclusief de verdeling in iteraties, het gebruik maken van user stories om de release scope te definiëren.
  • Het release acceptatieproces op basis van de klanttevredenheid (gemeten door het % van acceptatie van alle user stories) en acceptatie criteria die vooraf werden vastgesteld. Ook de finale systeemacceptatie na de oplevering van de laatste release was beschreven.
  • Wijze van afhandelen van problemen.
  • Communicatie tussen klant en leverancier en het besluitvormings- en escalatieproces met benoemde sleutelfiguren.
  • Templates en documenten die tijdens het proces gebruikt zouden worden.
  • Betalingsvoorwaarden op basis van de projectaanpak.

Om administratieve redenen vereiste de klant nogal wat formele documentatie. Aangezien wij ook graag onze betalingen op tijd ontvingen, kwamen we het volgende proces overeen.

Opdeling van het project in kleine brokken

Het te ontwikkelen systeem werd opgedeeld in 10 releases. Op deze wijze waren we beter in staat om het werk goed af te bakenen en de details te definiëren. Iedere release had zijn eigen budget, gebaseerd op de initiële begroting op basis van de epics en user stories. Dankzij het werken met “story points” en het spelen van “planning poker” konden we de benodigde ontwikkeltijd per release goed bepalen.

Naast het raamwerkcontract sloten we per release ook een contract af. Iedere release werd geaccepteerd middels een acceptatiedocument.

Iedere release wordt door een team van analisten en consultants in detail gedefinieerd met als resultaat een “Release Product Backlog”. De Release Product Backlog bevatte alle use cases die moesten worden geïmplementeerd. In aanvulling daarop werden de acceptatie criteria en de Definition of Done vastgelegd. Op deze wijze wist het ontwikkelteam exact wat er gerealiseerd moest worden. Deze documentatie tezamen vormde de “Release definition”.

Aansluitend deelde het ontwikkelteam de use cases op in veel gedetailleerdere user stories. Samen met de Product Owner werden de prioriteiten vastgesteld, wat resulteerde in een planning van de volgende iteratie. Deze afspraken werden geformaliseerd in de “Iteration agreement”. Ook stelde het team de verwachte velocity voor de release vast, welke indicator werd gebruikt als een van de indicatoren om het succes van een iteratie te meten.

Tijdens de ontwikkeling werd de Product Owner frequent (vrijwel dagelijks) geïnformeerd over de voortgang van het project. Wellicht nog belangrijker was de betrokkenheid van diverse domeinexperts. Die hebben namelijk heel veel bijgedragen aan het succes van het project, omdat zij exact wisten wat in de praktijk wel/niet zou werken.

Iedere release, of zelfs tussenresultaten, werden getest door de klant op basis van de eerder overeengekomen acceptatiecriteria. Als de klantbeoordeling hoger was dan 85% “done”, dan kon het project worden voortgezet, moest de klant de release betalen en werd de detailplanning van de volgende release gestart. Verbeterpunten werden meegenomen in de planning van de volgende release. De ondertekening door de klant van het acceptatieprotocol resulteerde in een trigger voor de financiele administratie.

Dankzij de geweldige samenwerking bleken alle releases een acceptatieniveau ver boven 85% te hebben.

In de raamovereenkomst stonden de start- en opleverdatum van iedere release vermeld. Alle partijen waren verplicht om zich aan deze planning te houden. Het verplaatsen van een deadline was niet toegestaan. Hetzelfde was van toepassing op het overeengekomen releasebudget. De enige variabele was de release scope. Gedurende de ontwikkeling van de release kon er voor gekozen worden om bepaalde functionaliteiten uit te stellen of zelfs helemaal te vervangen door andere wensen.

De werking van het contract in de praktijk

Toen de klant ons benaderde voor dit project, voelden we ons daar erg ongemakkelijk bij. Het risico vonden we gewoonweg te groot. Dankzij de hierboven beschreven aanpak, werd het project beheersbaar. In feite werd het grote project opgedeeld in kleinere. Een belangrijk voordeel was ook dat de belangrijkste betrokkenen elkaar frequent ontmoetten om de projectstatus te bespreken en om de aanpak aan te passen indien nodig. De klanttevredenheid werd continue gecontroleerd. Dit alles maakte het proces iets bureaucratischer, maar wel veel voorspelbaarder. Het reduceerde het project risico aanzienlijk.

Ook de klant merkte deze voordelen op. Ze waren zich er van bewust dat ze een Agile aanpak moesten volgen om hun doel te realiseren en ondertussen bureaucratie te voorkomen in het geval ze aanvullende wensen zouden hebben. En toch verschafte dit proces hen alle noodzakelijke documenten voor hun interne administratieve processen.

De juristen hadden hun werk goed gedaan, want het raamcontract bleef verder ongewijzigd gedurende het proces. Kleine aanpassingen werden aangebracht aan de diverse ondersteunende documenten om de behoeften van zowel de klant als Goyello beter te dienen.

Het contract gaf duidelijk richting aan het project en het speelveld was hiermee goed afgebakend. Zo bood het contract ons bijvoorbeeld ook de mogelijkheid om de product owner te dwingen tijdig de juiste informatie op te leveren, waaronder een tijdige aanlevering van de acceptatiecriteria. Frequent moesten we de klant aan de gemaakte afspraken herinneren zodat het projectteam zo efficient mogelijk kon werken aan het tijdig realiseren van de oplossing.

Flexibiliteit en continue de kosten beheersen – kan dat?

Veel interactie tussen alle betrokkenen en het regelmatig testen van nieuwe elementen van het systeem bleek een goede basis voor het bespreken van aanpassingen. Bij een traditionele aanpak zouden nieuwe wensen vermoedelijk pas mogelijk zijn geweest aan het eind van het project en ook zouden ze leiden tot een additionele budgetbehoefte.

In de wetenschap dat de gedachten over het optimale systeem tijdens de ontwikkeling zouden wijzigen (en dat doen ze altijd!), kon de klant er voor kiezen om de scope en prioriteiten van een release/sprint aan te passen. Dit was budget neutraal als er een uitruil plaatsvond met eerder overeengekomen wensen.

Dankzij voortschrijdend inzicht ontstonden nieuwe wensen die leidden tot een scope uitbreiding. De klant accepteerde de budgetuitbreiding. Het leidde gelukkig niet tot een aanpassing van de deadline, omdat wij in staat bleken toch op tijd op te leveren.

Een tijdige maatwerk oplossing

Door de iteratieve en incrementele aanpak, konden wij al na zo’n 2 weken de eerste resultaten tonen. Binnen 2 maanden werd de eerste systeemmodule al in gebruik genomen, waardoor de klant een tijdrovend backoffice proces vervroegd kon starten. Het contract was op dat moment echter nog steeds niet getekend.

Vroegtijdig kon de klant het systeem dus module per module in de praktijk inzetten. Men hoefde niet te wachten tot de oplevering van het gehele systeem. Voor hun business planning betekende dit een grote opluchting. Ook konden de gebruikers direct verbetervoorstellen doen, waardoor het systeem nog beter werd aangepast op hun dagelijkse behoeften. Ook voor hen betrof het een geheel nieuw proces, waarvan ze op voorhand niet alle details konden voorspellen.

Tijdens iedere release werden andere deelnemers (van de klantzijde) aan het project toegevoegd. Domeinexperts gaven antwoorden op resterende detailvragen en konden de dagelijkse processen zeer goed beschrijven. Eindgebruikers beoordeelden het systeem en zij leverden zeer bruikbare feedback.

Dankzij deze aanpak ware wij in staat om een stabiel, goed getest, optimaal werkend systeem opleveren dat de hoogst mogelijke business waarde leverde.

Door de incrementele oplevering werd het systeem zeer frequent getest. Ook werd het aantal potentiele fouten en problemen drastisch verlaagd door het toepassen van geautomatiseerde tests. Iedere iteratie toonden automatische test de juiste werking van het systeem aan.

De eindacceptatie van het gehele systeem werd op deze wijze niet veel meer dan een formaliteit. Alle deelopleveringen waren immers al geaccepteerd.

Tips voor Agile contracteren

Afhankelijk van het type samenwerking is het mogelijk dat een erg formeel of zelfs bureaucratisch, contract wordt vereist door de klant. Wij zijn er inmiddels van overtuigd dat dit een Agile werkwijze niet in de weg hoeft te staan. Neem de tijd om een aanpak overeen te komen en zorg dat alle neuzen dezelfde kant op staan. Besteed veel aandacht aan het goed begrijpen van eisen/wensen, project afbakening, werkaanpak, etc. Definieer de eisen/wensen in de vorm van user stories, want dit stimuleert alle betrokkenen om de eisen/wensen te beschrijven op een begrijpelijke manier.

Het kan het nodige missionarissen werk betekenen om bepaalde vertegenwoordigers van de klant te overtuigen. Val ze niet aan, bedenk dat ze mogelijk niet eens weten wat een Agile aanpak is. De klant wil graag controle hebben over het proces en het is onze taak om uit te leggen dat zij bij een Agile aanpak mogelijk meer controle op het proces uit kunnen oefenen.

Door nauw met elkaar samen te werken zal het wederzijdse vertrouwen stap voor stap toenemen. Beide partijen zullen hier uiteindelijk profijt van hebben.

Samen met onze klant stonden we een beetje bureaucratie toe als onderdeel van ons Agile project. Het lukte om het papierwerk tot het noodzakelijke minimum te beperken, zodat onze projectmanager het makkelijk aankon. Het ondersteunde de project governance op een meer traditionele manier, die voor de interne organisatie voor onze klant benodigd was om vertrouwen voor het project te winnen. De ontwikkelteams hebben hier geen moment last van gehad, zij werkten dagelijks aan het project volgens de Scrum methode.

Uiteindelijk was zo’n 75% van het cap budget benodigd. Voor ons was dat niet echt een verrassing, dat was ingecalculeerd. Dankzij een significant additioneel budget voor nieuwe wensen en een lange termijn onderhoudscontract was het de investering waard.

Onze klant was erg content dat een goed werkend systeem voor de afgesproken datum en binnen het overeengekomen budget werd opgeleverd.

Knip een groot project in kleine stukjes

Naar aanleiding van dit project concluderen wij dat ook grote projecten op een Agile manier kunnen worden uitgevoerd. Je moet ze dan wel onderverdelen in een aantal kleinere. Het kostte wat tijd om deze kleinere projecten goed te definiëren en er een bijpassend contract voor te maken, maar het was meer dan de moeite waard. Door aan het begin van het project veel tijd samen door te brengen ontstond er veel wederzijds begrip tussen de klant en ons als leverancier. Dit begrip werd wederzijds vertrouwen toen duidelijk werd hoe succesvol de samenwerking was.

Achteraf is het natuurlijk makkelijk oordelen. Maar nu kunnen we constateren dat Mandela inderdaad gelijk had.

Mocht u vragen, opmerkingen en/of suggesties hebben, laat dan hieronder a.u.b. een bericht achter of neem contact met ons op via het contactformulier.

Entrepreneur, co-founder & Managing Director of Goyello and Webmerce. Sociologist and electrotechnical engineer, a great combination that stimulates him to look for working solutions. Passionate about converting great ideas into new solutions. He is married and a proud father of 3 great sons. Participating in (and training for) triathlons to stay fit.