Ooit was de watervalmethode dé methode voor softwareontwikkeling. Wij zijn inmiddels volledig overgestapt op een agile manier van software ontwikkelen. Wat is het, wat is het verschil met de traditionele aanpak en wat zijn de voordelen?
Als we kijken naar de traditionele manier van software ontwikkelen, dan zien we een aantal fases die een voor een doorlopen worden. Eerst worden de wensen en eisen van een klant heel gedetailleerd vastgelegd in de analysefase, daaruit volgt een basisontwerp en een technisch ontwerp, dan komt de daadwerkelijke bouwfase, de testfase, dan wordt de software geïntegreerd, en tenslotte volgt het beheer en onderhoud. Het probleem bij deze aanpak is dat je met een heel lang voortraject te maken hebt, waarin je tot in detail moet bedenken hoe alles eruit komt te zien.
Zie het als het ontwerpen van een huis, daarbij moet je ook vooraf bepalen waar je de ramen wil en of je een schuifpui wil of openslaande deuren. Eén wezenlijk verschil: bij een huis kan iedereen zich wel iets voorstellen, het ontwikkelen van een ERP-applicatie is voor de meeste mensen veel abstracter. Dat houdt in dat je bepaalde beslissingen moet nemen waarvan je de gevolgen nog niet kunt overzien. In de loop van het proces kun je erachter komen dat je samen dingen hebt bedacht die niet nodig zijn of die slimmer kunnen. Maar als de klant ineens dingen anders wil, zorgt dat voor meerwerk en als de ontwikkelende partij ineens bedenkt dat iets slimmer kan, kan dat ook tot moeilijke gesprekken leiden. Kortom: je zit redelijk vastgemetseld.
Onze agile aanpak is veel flexibeler en kent deze nadelen niet. Vooraf kijken we op hoofdlijnen wat de wensen en eisen van een organisatie zijn. Op basis daarvan maken we een calculatie. Bij de traditionele aanpak gaat dat heel nauwkeurig: in eenheden van twee uur. Bij de agile aanpak gebruiken we T-shirt-sizing: elke taak wijzen we een T-shirtmaat toe – van XS tot XXL – om de relatieve inspanning van die taak weer te geven. Soms zal blijken dat een taak een kleinere maat heeft, soms is een taak groter dan gedacht, maar over het totaal genomen kom je uit op het juiste budget terwijl je wel maximale flexibiliteit hebt.
We leggen dus niet vooraf tot in detail vast hoe we iets gaan realiseren, maar werken in korte tijd toe naar een minimaal levensvatbaar product (een Minimum Viable Product ofwel MVP). Daarmee kunnen key-users al aan de slag en in de praktijk ervaren hoe de applicatie werkt. Zo krijgen ze veel sneller een gevoel wat er daadwerkelijk nog nodig is en welke – vooraf bedachte – features overbodig zijn. Dat voorkomt veel rework en geeft niet alleen meer flexibiliteit, maar zorgt ook dat je op een lager budget uitkomt dan bij de traditionele methode.
Een dergelijke aanpak vergt wel iets van je organisatie. Allereerst is het heel belangrijk dat de klant en leverancier elkaar vertrouwen. De klant moet erop vertrouwen dat wij als leverancier de juiste hoeveelheid kennis en ervaring hebben om met de juiste oplossing te komen binnen de geschatte tijd. Daarnaast moeten de key-users een bepaalde mate van flexibiliteit hebben. Een MVP heeft vaak nog niet ieder knopje en iedere functionaliteit die uiteindelijk nodig is, maar biedt voldoende functionaliteiten om mee te kunnen testen en is een basis om op door te ontwikkelen. Tenslotte is het van belang dat de sponsoren van het project – vaak de directie – de key-users op de juiste manier ondersteunen en informeren. Je gaat een veranderproces in en dat kan betekenen dat het werk verandert. De een krijgt misschien iets meer werklast, de ander iets minder, maar de organisatie als geheel gaat erop vooruit. Voorkom silo-denken, maar kijk naar het grote geheel. Samen kom je verder.
