Software bouwen is moeilijk. Het vereist het nodige vakmanschap.
En dat helemaal wanneer de klant verwacht dat er een product geleverd wordt

• waarmee echt gewerkt kan worden,
• op de afgesproken datum en
• tegen het bedrag dat vooraf afgesproken is.

Mocht tijdens de bouw blijken dat er wijzigingen nodig zijn,
dan wordt er een heldere kosteninschatting gegeven samen met een nieuwe opleverdatum voor het product met het meerwerk.
Zo kan de klant beslissen of de kosten voor het meerwerk opwegen tegen de baten.

Klinkt niet onredelijk, zou je zeggen.

Toch is de praktijk in de ICT vaak anders.
Voor wie ze wil vinden zijn er genoeg artikelen die aangeven dat bovenstaande verwachting in de meeste gevallen niet uitkomt.
Opvallend is dat de problemen, zoals ze nu geschetst worden in de kern niet anders zijn dan 10 jaar geleden.
Hetzelfde geldt voor de voorgestelde oplossingen.
Wat is dan de vooruitgang geweest in het afgelopen decennium?

Er kan betoogd worden dat Agile software ontwikkelen als methode veel meer wordt toegepast dan 10 jaar geleden.
Maar kan Agile software bouwen als methode er werkelijk voor zorgen dat de ICT aan de hierboven geschetste verwachting van de klant kan voldoen?
Grondlegger Allister Cockburn beweert al dat `weinigen écht snappen waar Agile over gaat´.
Is Agile weer een methode waar enkel de ere- en eerstedivisie van de ontwikkelteams successen mee kunnen boeken?

Ja, dat denk ik.

Voor de grote groep gemiddelde ontwikkelteams zal ook Agile software ontwikkeling tot forse budgetoverschrijdingen blijven leiden.
Om een eenvoudige verklaring hiervoor te geven, doe ik eerste een stap terug en kijk waarom de Waterval methode niet voldeed.

Watervalmethode

Bij de Watervalmethode, die tot midden jaren 90 vanzelfsprekend was, werd uitgebreid de tijd genomen om te specificeren wat er gebouwd moest worden.
Hier rolde dan ook een redelijk nauwkeurige planning voor de bouw uit.
Na de specificatie periode mocht de klant weggaan en wachten tot het ontwikkelteam klaar was met bouwen.
Te vaak bleek echter dat het opgeleverde product niet iets was waar de klant zijn werk mee kon doen.
Forse budgetoverschrijdingen waren dan nodig om alsnog iets te maken waar de klant wat mee kon.

Agile ontwikkelmethoden

Als oplossing voor dit probleem werd Agile ontwikkelen aangedragen, met als kenmerken:

• ga niet uitgebreid specificeren, maar
• betrek de klant bij je ontwikkelproces en
• lever regelmatig concrete deelproducten op.

De klant kan zo tijdig aangeven of het deelproduct werkbaar is of niet, opdat er bijgestuurd kan worden.
De kans op een werkbaar eindproduct neemt flink toe.
Nadeel is echter dat je onmogelijk vooraf kan inschatten hoe duur iets gaat worden als je dan nog niet weet wat je gaat bouwen.
Gemiddelde ontwikkelteams zullen daarom óók met Agile ontwikkelmethoden de alleszins redelijke verwachting van de klant niet kunnen gaan waarmaken.

Een nieuwe ontwikkelmethode

Stel dat er een ontwikkelmethode bestaat waarmee software opgeleverd kan worden waarmee de klant:

• echt kan werken,
• het product op de afgesproken opleverdatum krijgt en
• tegen het bedrag dat hij vooraf begroot heeft.

Aan welke uitgangspunten moet zo'n methode dan voldoen?

• De kennis van alle betrokkenen is even belangrijk,
• de methode moet een taal leveren die iedereen kan spreken – van praktische eindgebruiker tot technisch ingestelde ontwikkelaar,
• de methode moet zich aanpassen aan de intuďtieve denkwijze van álle betrokkenen.

Maar dit is niet genoeg.
De nieuwe methode zal ook het specificeren moeten vereenvoudigen van wat de klant nodig heeft.
Wat is er dan mis met de huidige manier van requirements vastleggen?
Dat leg ik uit aan de hand van het Requirements Review Dilemma.
En daarna laat ik zien dat de Black Box Dialog Methode een oplossing is voor het Requirements Review Dilemma,
waarmee bovendien de klantverwachtingen uit de eerste alinea kunnen worden waargemaakt.

Lees verder ...