Agile is geen toestemming voor het opleveren van onbruikbaar materiaal

Agile en Scrum zijn gericht op het snel krijgen van feedback door klanten. Met o.a. het idee dat, als je iets bouwt wat de klant niet wil, je hier in een veel vroeger stadium achter kan komen. Dat klopt. Maar als je in de situatie terecht komt, dat je een tafel hebt gebouwd, terwijl je klant een stoel wil, is het niet slim om te zeggen: "Daarom werken we Agile". En vervolgens door te gaan alsof er niets gebeurd is. Nou OK, je bouwt alsnog de stoel, maar meer is niet nodig. Want je werkt Agile en dan hoort dit er gewoon bij.

Naast het vroeg ontdekken van problemen, zijn zowel Agile als Scrum ook bedoeld om van je fouten te leren. Zie het als een bewaking tegen inbraak. Je beveiligt je huis en als onderdeel installeer je een inbraakalarm. Vervolgens wordt er, ondanks al je maatregelen, toch ingebroken. Dan ben je blij dat je je inbraakalarm hebt, als hierdoor je inbreker uiteindelijk veel minder steelt. Maar ondanks dat je inbraakalarm zijn doel perfect heeft bereikt, ga je toch kijken hoe de dief binnen is gekomen. Is dat door het kelderraam? Dan beveilig je dat raam ook.

Zowel Agile als Scrum hebben delen, die gericht zijn op het in een vroeg stadium ontdekken van problemen. Net als bij een inbraakalarm kan de schade van het probleem hierdoor ingeperkt worden. Maar er is wel een probleem. En dat probleem moet opgelost worden. Het moet je doel zijn om dat inbraakalarm nooit meer nodig te hebben. En zo moet het ook je doel zijn om te begrijpen wat je klant wil, voor je ook maar op enige manier start met development.

Agile, Scrum, handmatig testen, automatisch testen, documenten reviews, demo's aan de klant: het zijn allemaal middelen, die je kunnen helpen om er in een zo vroeg mogelijk stadium achter te komen, dat je product niet geschikt is om aan de klant op te leveren. Maar het allerbelangrijkste is om deze momenten vooral te beschouwen als leermomenten. Momenten om te leren hoe je je proces of je communicatie zo aan kunt passen, dat problemen niet nog een keer gebeuren. Een huis vol met de juiste alarmen, kan je zeker (en terecht) een veiliger gevoel geven. Maar als je een inbraak kan voorkomen met een extra slot op het kelderraam, blijft dat extra slot altijd een terecht streven. Voorkomen is en blijft beter dan genezen. Ook als je werkt volgens Agile en/of Scrum.

Testen in het grote onbekende

De kennis van de applicatie is te vaak niet aanwezig. Wat wel bekend is: het is ingewikkeld. Een voordeel: je test slechts wijzigingen. Bijbehorende nadeel: veel ontwikkelaars kennen ook slechts de wijzigingen. Maar hoe test je berekeningen, processen, imports, enz., als je slechts de wijziging kent?

Het allerbelangrijkste in deze situatie: voer je testen twee keer uit. Normaal bereid je je testen voor en zodra de ontwikkelaar klaar is, voer je ze uit. In deze situatie voer je ze twee keer uit. Een keer voordat de wijziging is opgeleverd. Een keer nadat de wijziging is opgeleverd.

Waarom twee keer? De eerste keer kan je zien als de basismeting. Zodra je weet hoe de applicatie nu werkt en je weet wat er gaan wijzigen, kan je voorspellen hoe de applicatie na de wijziging gaat werken. Bijvoorbeeld als er 20% van het totaalbedrag afgehaald moet worden, kan je van tevoren nagaan wat het totaal bedrag is voor de wijziging. En vervolgens moet het totaalbedrag na de wijziging 20% lager zijn. Als er via een import een persoon moet worden aangemaakt, kan je de gegevens handmatig invoeren en het eindresultaat vastleggen. Tenslotte zal in veel gevallen het resultaat gelijk moeten zijn.

Daarnaast heeft dit nog een ander voordeel: de snelheid. Als je voor de oplevering van de wijziging al precies weet wat de wijziging is, welke gegevens ingevoerd moeten (maar vooral ook kunnen) worden, en wat het eindresultaat moet zijn, kan je zeer snel testen. De kans op onverwachte invoerproblemen of op extra vragen is een stuk kleiner. En hierdoor is de testuitvoering opeens een stuk sneller.

Deze manier van testen is even wennen. Je voorbereiding voelt zeker minder Agile aan, vooral omdat het vraagt om meer documentatie. Maar wat je behoudt is je flexibiliteit. Je bent in staat te testen, ongeacht kennisproblemen. En als het moet, kan je snel testen. En nog een extra: problemen komen eerder naar voren, waardoor je meer tijd hebt om ze op te lossen. Grootste obstakel: jij en je team. De bereidheid te testen op een manier, die werkt. En niet op een manier volgens het boekje.