Agile: de weg naar de ultieme applicatie

Bij het bouwen van een applicatie is het inschatten van de kosten en de benodigde tijd vaak een lastige uitdaging. In de praktijk lopen projecten regelmatig uit of ze gaan over het begrote budget heen. De opdrachtgever heeft voorafgaand aan het project echter een concrete inschatting van de kosten nodig om hiervoor draagvlak te creëren. Hoe kunnen opdrachtgevers dus in een eerder stadium duidelijkheid krijgen over de te maken investering? In deze blogpost geef ik antwoord op die vraag.

Software als LEGO®-kasteel

Software ontwikkelen werkt eigenlijk als het bouwen van een LEGO®-kasteel: je begint met een idee van wat je wilt bouwen en een grote bak vol losse blokjes. Vooraf gezien is het lastig in te schatten hoeveel stukjes je nodig hebt en hoe ingewikkeld het zal zijn om alle bruggen, torens en kerkers met elkaar te verbinden. Er zijn dan twee opties:

1. Je tekent het plan van tevoren gedetailleerd uit en baseert daarop een nauwkeurige inschatting;
2. Je tekent vooraf slechts een werkend increment uit van het totale product en maakt daarmee de complexiteit van het idee snel zichtbaar. Op dit increment baseer je vervolgens een inschatting van de investering die nodig is voor de volgende stap richting het eind doel. Deze cyclus herhaal je regelmatig en wordt ook wel een Agile-aanpak genoemd.

De foutgevoelige traditionele aanpak

Wanneer je, zoals bij de eerste optie, het idee van tevoren gedetailleerd uittekent, lijk je goed voorbereid aan de slag te gaan. Toch kost deze voorbereiding in een vroeg stadium vaak al veel tijd, zonder dat je weet hoe jouw idee in de praktijk uitpakt. Mocht je tijdens de voorbereiding iets over het hoofd zien, een verkeerde aanname doen of de opdracht verandert, dan is het risico groot dat je helemaal opnieuw moet beginnen. Met andere woorden: je bent dan niet ‘lenig’ om je aan te passen aan een veranderende situatie. Dit kan veel tijd en geld kosten.

Het bovenstaande voorbeeld illustreert de foutgevoelige aanpak. De schilder heeft al vanaf stap 1 veel energie gestoken in details. Mocht hij op een later moment iets grootschalig willen aanpassen qua kleur, vorm of ontwerp dan kan het hele werk de prullenbak in.

Agile for the win

In het geval van de tweede optie, de Agile-aanpak, schakel je sneller over op de praktijk. Je neemt je doel voor ogen, bepaalt de eerste haalbare stap en zet deze. Daarna blijf je het project gaandeweg evalueren aan de hand van de volgende vragen:

1. Klopt het gestelde doel nog of moet het worden bijgesteld?
2. Wat is de volgende stap om het doel te behalen?

Deze aanpak houdt je ‘lenig’ om je aan te passen aan veranderende parameters, wat veel tijd en geld kan besparen.

In dit voorbeeld is het uiteindelijke doel van het schilderij al helder bij stap 1. Tegelijkertijd is dit doel bij elke stap makkelijk aan te passen. Deze benadering kenmerkt de Agile-aanpak. Da Vinci’s opdrachtgever lijkt de schilder in het tweede voorbeeld al na de eerste fase te hebben bijgestuurd over het feit dat de handen gekruist moeten zijn, terwijl dat in de eerste aanpak pas bij stap 4 aan bod komt

Samen ontwikkelen naar het ultieme doel

Het Business Team Software-ontwikkeling bij OGD hanteert de Agile-methodiek. Wanneer een nieuwe opdracht bij het team binnenkomt, presenteert zij na korte tijd een werkend prototype dat daar een antwoord op vormt. Zo kan de klant in een veel vroeger stadium - vaak al binnen twee weken - bepalen of de geboden oplossing haalbaar en relevant is en of het plan moet worden aangepast. Nadat overeenstemming is bereikt bouwt het team desgewenst verder aan het ultieme product voor deze klant.

Benieuwd naar de mogelijkheden? Ik en mijn collega's gaan graag met u in gesprek om te bekijken wat voor uw organisatie de ultieme applicatie op maat is.