Gisteren schreven ze bij Computable een stukje over de mogelijke oorzaak van het falen van het Wia-project bij de uitkeringsinstantie UWV. Dit Wia-project werd geannuleerd na een investering van 87 miljoen euro. De conclusie van het Computable-artikel is dat een andere ontwerpmethodiek, nl. agile i.p.v. de traditionele waterval, dit falen had kunnen voorkomen. Michael Franken wijst in zijn blog bij Agile Holland er echter op dat met het huidige systeem van aanbestedingsprocedures zoals deze zijn opgelegd door de EU het eigenlijk niet mogelijk is om nog echt agile te werken; aanbestedingen vereisen nl. al uitvoerige uiteenzetting van hoe het eindproduct er uit moet komen te zien:
Ten eerste zijn de eisen van een aanbesteding echt funest voor een project aangezien alle parameters van de Iron Triangle (tijd, resources, scope) worden dichtgetimmerd.
Agile development maakt het, met zijn iteratieve karakter, goed mogelijk om aanpassingen op een later moment door te voeren. Dat het mogelijk is om een ontwerp te maken wat vervolgens geïmplementeerd kan worden en dan bij oplevering naar wens is van de gebruikers is een illusie.
Als (industrieel/interactie/grafisch)-ontwerper wordt je al vanaf begin af aan ingestampt dat een gebruiker (en vaak ook klant) niet weet wat hij of zij wil: het is simpelweg te lastig om een complexe samenhang te bevatten wanneer het alleen maar bestaat in een abstracte beschrijving.
Vandaar dat ontwerpers schetsen en prototypes maken: ze zoeken naar de juiste vorm door vorm te geven. Dergelijke prototypes kunnen weer worden besproken met klanten, die er mee kunnen experimenteren en testen, hetgeen weer als input geldt voor een volgende ronde. Gaandeweg evolueert zo een ontwerp dat uiteindelijk in massa kan worden geproduceerd.
Het is eigenlijk vreemd dat dit idee in de IT-wereld nog maar langzaam zijn intrede doet. Helemaal omdat aanpassen in het digitale domein veel gemakkelijker zou moeten zijn wanneer het wordt vergeleken met het fysieke domein. Bitjes kun je gemakkelijk kopiëren en verander je immers gemakkelijker dan mallen. Toch lijken er altijd direct digitale mallen te worden gemaakt, waarbij het aanpassen vervolgens kostbaar is. In het digitale domein zouden fouten zo weggepoets moeten kunnen worden - mits het project daartoe is ingericht…
Wat ik mij echter af vraag is, met betrekking op de quote hierboven van Michael Franken: Wie timmert een aanbesteding vast? Is het de overheid, of de aannemer? De overheid blijkt vaak nog met aanpassingen te komen, terwijl, zoals MF later ook al aangeeft, het de aannemers zijn die vervolgens iedere aanpassing als een wijziging van eerdere afspraken beschouwd. Is een wijziging altijd ingewikkelder om te implementeren? Een iteratief proces staat het ook toe om eerder op te houden, omdat het simpelweg af is (of iig naar wens). Lang niet alle vooraf bedachte ‘features’ hoeven noodzakelijk te zijn. De kans op weggegooid geld is met een iteratief proces waarbij eerst de belangrijkste functionaliteit wordt geimplementeerd in een bruikbaar product dus veel kleiner. De dikke specificatie, die volgens Michael Franken als obstakel ziet, hoeft daarbij geen obstakel te zijn: het zou ook gebruikt kunnen worden als ‘inspiratie’ voor een eerste opzet. Vanuitgaande dat een specificatie niet een ontwikkelmethode specifiek dicteert, en de klant bereidt is tot frequent overleg over de gang van zaken (waarbij duidelijk de voortgang kan worden getoond (en welke klant wil dit nou niet zien?)), zou een agile methode zoals SCRUM toch zeker moeten kunnen werken?
Lees ook:
Opmerking: Ik ben bewust niet ingegaan op het tweede probleem dat genoemd wordt door Michael Franken, nl. dat externe partijen veelal de leiding hebben over het werk. Wanneer zij niet exact de wens van de klant/gebruiker weten te communiceren naar onderaannemers, en/of ook geen direct contact met de klant of gebruiker toestaan, dan is er inderdaad iets onbegrijpbaar mis.
Update (31-07): Bij 37signals wezen ze gisteren ook nog bewust op de rol van de aannemer:
Enkel door continue, over alles te blijven communiceren, is het mogelijk om tot een gezamelijke visie te komen voor een goed eindproduct.
Deze post verscheen eerder op The Bean Blog
Vond je dit leuk, volg me op Mastodon, voeg die RSS, euh ATOM feed toe aan je feedreader, of schrijf je hieronder in op mijn nieuwsbrief.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .