Het Agile manifest en de miserable praktijk van grote IT-projecten

English readers: I apologize for the inconvenience, but this post is in Dutch because it relates to a workshop that I will be giving soon. My next (and future) posts will be in English again.

“Overheid verspilt miljarden euro’s aan mislukte ICT-projecten” kopte Elsevier recent naar aanleiding van een rapport van de ICT-commissie van de Tweede Kamer. Dat grote IT-projecten meestal falen is geen geheim, maar de praktijk blijkt wel heel dramatisch. Uit onderzoek van de commissie blijkt dat slechts 7% van de IT-projecten bij de overheid als ‘geslaagd’ beschouwd kan worden, terwijl 36% geen resultaat oplevert en 57% ergens in het midden uitkomt. Volgens een onderzoek van Marktet Cap in 2010 bleek dat de budgetoverschrijding gemiddeld 67% bedraagt. In de particuliere sector is het niet anders. Uit de periodieke monitor van de Standish Groep blijkt bijvoorbeeld dat 10% van de grote IT-projecten slaagt, 38% ronduit mislukt en 52% in elk geval (ruim) uit de planning en/of het budget loopt.

Kortom, geen goed vooruitzicht als je als programma- of projectmanager bent aangewezen om een groot IT-project te trekken. Maar waarom is het laten slagen van een groot IT-project zo moeilijk? Volgens de commissie zit het vooral in de complexiteit. Hoe meer partijen, hoe meer requirements, hoe ingewikkelder de materie en hoe langer het project, hoe onoverzichtelijker en onvoorspelbaarder het projectverloop. Het aantal factoren dat je project beinvloedt groeit immers exponentieel.

Een eerste reactie op deze onvoorspelbaarheid zou kunnen zijn om de teugels strakker aan te trekken. Meer controle. Meer planning. Meer nadenken voordat we gaan bouwen. Meer richtlijnen en procedures. Maar los je hiermee de kern van het probleem op? De praktijk leert ons dat het meestal vooral mis gaat in de aannames die we doen in de voorbereidende fases van een project. Is ‘dit’ in te bouwen in een maand? Zitten eindgebruikers hier op te wachten? Kunnen we deze systemen koppelen? Is er voldoende steun bij alle betrokken partijen? Is de oplossing die we nu bedenken over een half jaar nog steeds de beste oplossing? Naarmate de complexiteit van je project groeit, groeit ook het aantal aannames en voorspellingen. Maar hoe meer aannames je maakt, hoe meer er fout zullen blijken te zijn. En deze fouten zijn bijzonder kostbaar als je dit pas halverwege, of zelfs aan het eind, van je project ontdekt.

We kunnen dus proberen om de toekomst beter te voorspellen, want daar komt het dan in de kern op neer. Dat is inderdaad hoe dit probleem in het verleden vaak is aangepakt. Een wezenlijk resultaat op de succeskans van projecten heeft dit echter niet gehad, getuige de cijfers uit de eerste paragraaf.

Wellicht is er een andere manier om met deze complexiteit om te gaan. We zouden haar ook kunnen accepteren als de realiteit van een (groot) IT-project. In plaats van het bezweren van onvoorspelbaarheid met regels, procedures en plannen, kunnen we de onvoorspelbaarheid juist onderdeel maken van onze aanpak. In plaats van uitgebreide planningen en plannen, kunnen we ons beter richten op datgene wat op de kortere termijn zeker waarde oplevert. We doen er ook goed aan om onze aannames zo vaak en snel mogelijk te toetsen. In plaats van een oplevertijd van maanden of zelfs jaren, moeten we er naar streven om zo vaak mogelijk werkende software op te leveren. Het liefst elke maand, elke twee weken of zelfs elke week. Werkende software is immers de beste manier om te toetsen of je op de goede weg zit, of je eindgebruikers het begrijpen, of de techniek toereikend is en of je het probleem eigenlijk nog wel aan het oplossen bent. Deze manier van werken biedt geen controle door planningen en procedures, maar door zeer regelmatige inspectie van de voortgang. Met de mogelijkheid om regelmatig bij te sturen. En als we daarbij ook nog eens het proces regelmatig inspecteren (hoe werken we samen? wat werkt? wat niet?) kunnen we ook als team steeds beter worden.

In een notendop is dit het ‘Agile manifest’, zoals opgesteld in 2001 door een groep experts die de miserable resultaten van IT-projecten zat waren. De beginselen uit dit manifest vinden we terug in onder andere Scrum, extreme programming en Kanban. Het is een radicaal andere manier om software te ontwikkelen. Maar is het ook succesvoller? In het jaarlijkse rapport van de Standish Groep blijkt de succeskans bij ‘Agile’ projecten te stijgen naar 42%. Niet perfect, maar wel een stuk hoger dan de schamele 7%. De kracht lijkt daarbij vooral te zitten in de mogelijkheid om grote projecten op te breken in kleine, overzichtelijke brokjes die individueel toch waarde opleveren. 

En laat dat nou precies het advies zijn van de ICT-commissie van de tweede kamer ....

Wil je als programmamanager of projectleider meer weten over het ‘Agile manifest’ en de  ‘Agile mindset’? Kom dan naar de workshop die Leontien Wagenaar (adviseur Scrum / coach) en Christiaan Verwijs (Scrum trainer / projectmanager) geven tijdens de Train-de-Trainer dag van de Gemeente den Haag. (bij externe publicatie). Deze vindt plaats op donderdag 9 oktober van 15:00-17:00 in het Stadhuis aan het Spui te Den Haag. Programmamanagers en projectleiders zijn welkom, opgeven via leontien.wagenaar@denhaag.nl.

Christiaan Verwijs
Christiaan Verwijs

Scrum Master, Trainer, Developer & founder of Agilistic