Onlangs organiseerde de Nederlandse Vereniging voor Informatietechnologie en Recht (NVvIR) een studiemiddag over de juridische aspecten van Agile methodieken, meer in het bijzonder Scrum. In zijn blog licht Walter van Holst uitgebreid de kijk van Mitopics op Agile toe. De kern hiervan in dit nieuwsbericht.
Agile methodieken kenmerken zich door een iteratief ontwikkelproces zonder dat dit voorafgegaan wordt door een al te uitvoerige specificatiefase. Er zijn nog een waaier aan methodieken die niet klassiek waterval zijn, maar doorgaans wel uitgaan van een hogere mate van specificatie vooraf dan de Agile methodieken doen. Bijvoorbeeld de door Mitopics voorgestane proeftuinen bij pakketimplementaties zijn een voorbeeld van het niet zuiver op de waterval-manier aanpakken van projecten. Juist doordat bij een proeftuin een concrete (en betaalde) mini-implementatie plaatsvindt, wordt het mogelijk om het specificeren vooral te concentreren op de organisatiespecifieke inrichtingskeuzes van het pakket en/of eventueel aanvullend maatwerk in plaats van een tijdrovende gedetailleerde specificatie én worden de verwachtingen van de gebruikers al vroegtijdig bijgesteld.
Een fundamenteel knelpunt bij met name maatwerkontwikkeling dat de Agile methodieken proberen te adresseren is dat met name bij grotere projecten het opstellen van een nauwkeurige specificatie dusdanig tijdrovend is dat de bedrijfsomgeving en –processen alweer veranderd zijn tegen de tijd dat de specificatie geïmplementeerd is. De Agile methodieken trachten dit te adresseren door in korte iteraties te werken waarbij aan het einde van iedere iteratie concreet prototype wordt opgeleverd aan de gebruikers. Het voordeel hiervan is dat er gedurende het hele project er heel veel bijstuurmomenten waarop eventuele verschillen tussen verwachtingen en realisatie geredresseerd kunnen worden. Dit naast dat de methodiek veel en intensief overleg tussen de teamleden voorschrijft. Nadeel is echter dat er bij een geschil veel minder houvast is voor de afnemer om aan te tonen dat de leverancier tekort is geschoten in de gecontracteerde prestaties. Dat neemt niet weg dat Agile methodieken wel degelijk zinvol kunnen zijn. Veel van deze methodieken, onder ander Scrum, gaan er van uit dat de opdrachtgever na iedere iteratie de opdracht kan beëindigen, zonder opgaaf van reden. Daarmee wordt iedere iteratie in zekere zin een go/no-go moment, wat een stevige druk op leverancier legt om het vertrouwen van opdrachtgever te behouden.
Partijen zullen zich dan ook moeten gaan concentreren op de vraag hoe zij tot formeel geaccordeerde acceptatiecriteria kunnen komen die bij dergelijke Agile methodieken passen. Een aantal maatregelen die een Agile contract in ieder geval zal moeten bevatten zijn:
- Een proces om tot overeenstemming over de projectdoelen te komen, dat wil zeggen: doelen in termen van (technische) effecten waar de opdrachtnemer zich ook aan kan committeren;
- Formele vastlegging van de beëindigingsbevoegdheid van opdrachtgever na iedere iteratie;
- Consequenties die opdrachtnemer mag verbinden aan een te lage beschikbaarheid van medewerkers van opdrachtgever;
- Nadrukkelijke informatie- en signaleringsverplichtingen van opdrachtnemer over de zogenaamde ‘burn down chart’ (wikipedia), juist deze biedt een permanent inzicht over de beheersbaarheid van het project;
- Een helder moment waarop de acceptatiecriteria van de laatste iteratie definitief komen vast te liggen, bijvoorbeeld bij de voorlaatste iteratie.
U kunt onze volledige zienswijze hier nalezen.