Agile en IT-contracten: als water en vuur?
De agile projectmanagementmethode vindt zijn oorsprong in de IT-branche. De weg naar het einddoel bij IT-projecten bleek in de praktijk erg onzeker. Om hier wat aan te doen zijn projectmanagementmethoden ontwikkeld waarbij sneller ingespeeld kan worden op veranderende omstandigheden en een veranderende klantwens. In deze methoden wordt uitgegaan van het bereiken van het doel in een aantal korte (iteratieve) cycli. Bij agile IT-projecten staat verandering centraal en is er geen vaste uitgestippelde route om tot het resultaat te komen. Hierdoor wordt contracteren in een agile IT-project vaak beschouwd als een uitdaging, onder meer omdat standaard (model-) IT-contracten veelal (nog) zijn gebaseerd op de ‘klassieke’ waterval-methode.
Agile en waterval
Agile is een overkoepelend gedachtegoed voor methoden voor (met name) softwareontwikkeling. Hieronder vallen, onder meer, Dynamic Systems Development Method (DSDM), eXtreme Programming (XP) en Scrum. Hoewel deze projectmanagementmethoden op aspecten van elkaar verschillen, komen ze in essentie overeen. Bij deze methoden wordt gewerkt met doorlopende cycli (elke cyclus is een iteratie) van meestal een paar weken, waarin kleine aanpassingen/toevoegingen op het softwareproject worden gedaan en veel momenten zijn waarop alles kan worden herzien, van ontwerp tot technologieën tot mankracht.
De hoofdregels van agile zijn vervat in het Agile Manifesto. Dit is een manifest dat in 2001 is opgesteld door zeventien onafhankelijke softwareontwikkelaars. De vier hoofdregels zijn:
- Mensen en hun onderlinge interactie boven processen en tools.
- Werkende software boven allesomvattende documentatie.
- Samenwerking met de klant boven contractonderhandelingen.
- Inspelen op verandering boven het volgen van een plan
Dit verschilt van de ‘klassieke’ manier waarop softwareprojecten worden benaderd. Volgens de klassieke methode wordt alles éérst in een keer ontworpen, daarna in één keer gebouwd, dan alles in één keer geïntegreerd en dan alles als geheel onderhouden. Dit noemt men de waterval-methode.
Bij de waterval-methode wordt ervan uitgegaan dat er bepaalde tools volgens een vooropgesteld vast plan worden geleverd, dat dit plan gedocumenteerd is en dat er van tevoren is onderhandeld door softwareontwikkelaar en opdrachtgever. Hier wordt dus gewerkt met vooraf gedefinieerde specificaties, uitgebreide planningen en budgetten en een focus op processen en een vast resultaat. Standaard (of model-) IT contracten zijn veelal (nog) gebaseerd op deze ‘klassieke’ waterval-methode.
Bij de agile methode ligt de focus echter op lastig(er) te objectiveren punten. De focus ligt niet op de processen, maar op interactie tussen mensen. Niet op vooropgestelde plannen, resultaten en documentatie, maar op werkende software. Niet op vaste afspraken, maar samenwerking en inspelen op veranderingen. Op het eerste gezicht lijkt dit bijna tegenstrijdig te zijn aan het überhaupt hebben van een IT-contract tussen softwareontwikkelaar en opdrachtgever. Toch is een agile IT-contract essentieel voor beide partijen. Het contract moet dan echter wel matchen met de gekozen methodiek.
Een agile IT-contract
Allereerst is van belang dat men duidelijk afspreekt welke methode er precies zal worden gehanteerd, zodat partijen weten wat er van hen wordt verlang. Zoals hierboven al is vermeld, is agile een verzamelbegrip en het is dus goed dit te specificeren. In Nederland wordt vaak gekozen voor scrum.
De doelen van het project en de eisen aan het systeem zullen tussen partijen afgesproken moeten worden. Voorkomen moet worden dat het (eind)doel tijdens de verschillende korte ontwikkelcycli uit het oog wordt verloren en men op een zijspoor belandt. Deze (eind)doelen en eisen kunnen gaandeweg het project zo nodig aangepast worden.
Tevens horen in een agile IT-contract goede afspraken over de processen en de rollen van de (verschillende medewerkers van de) partijen in het project. Het agile IT-project staat of valt bij de juiste rolverdeling en kwalitatieve bemensing van de rollen. Over en weer mogen – beter nog: moeten – hier eisen aan worden gesteld.
Voor de opdrachtgever is het verder van groot belang dat in het agile IT-contract specifieke eisen aan het niveau en de kwaliteit van de documentatie en de source code worden gesteld. Met betrekking tot de kwaliteit en begrijpbaarheid van de documentatie kan zelfs nog een voordeel behaald worden ten opzichte van klassieke projecten. Bij die projecten is de documentatie vaak beperkt tot wijzigingsdocumentatie, omdat vooraf wordt gedocumenteerd. Deze documentatie is vaak lastig te relateren aan hoe de software werkt, omdat je daarvoor ook moet weten wat er gewijzigd wordt. Bij agile IT-project wordt pas achteraf gedocumenteerd. Hierdoor kan ervoor gezorgd worden dat de laatste status wordt beschreven, zodat de documentatie wel goed is te relateren aan hoe de software werkt.
Het prijsberekeningsmodel dient ook goed vastgelegd te worden in het contract. Hieronder valt de prijsberekeningsmethode (bijvoorbeeld een vaste prijs voor het afronden van een cyclus), wanneer er mag worden gefactureerd (bijvoorbeeld vooraf of na succesvol afronden van een cyclus), wat er gebeurt als een cyclus voortijdig wordt afgebroken of niet het gewenste resultaat wordt bereikt en wat er gebeurd als een verandering van het (sub)doel/de scope plaatsvindt (dus in geval van ‘meer- of minderwerk’).
Conclusie
Binnen een relatief informele projectmanagementmethode als agile, is formele en tegelijk actieve bewaking van het proces en het einddoel een noodzaak. Juist een contract leent zich bij uitstek om dat einddoel en het proces ernaartoe te verankeren.
Voor meer informatie, do’s & don’ts en tips & tricks voor het opstellen van (agile) IT-contracten, kunt u contact opnemen met
Robbert Sjoerdsma.
