Maximizing of work not done!!

Auteur: Rik Marselis ● evenement@testnet.org ● @rikmarselis

Agile is hot
Dat zie je bijvoorbeeld aan de grote belangstelling voor de TestNet thema-avonden over dit thema (bijvoorbeeld op 11 december a.s.). Dat merk je ook buiten TestNet. Vorige week was ik op een conferentie voor Finance managers (uit de business) waar ik aan een volle zaal mocht vertellen over hoe je met agile kunt bijdragen aan verbeteren van het succes van de organisatie. Iedereen lijkt namelijk wel bezig om agile te (gaan) werken.
Een ander teken van het belang van agile is de ontwikkeling van de nieuwe ISTQB Foundation syllabus (naast de al bestaande ISTQB Foundation) over Agile testen, die als het goed is midden 2014 zal worden gelanceerd. Als lid van de BNTQB werkgroep mocht ik een review uitvoeren. Het belooft een boeiend stukje verrijking van onze kennis.
Door deze activiteiten las ik weer eens de agile principles na. En mijn oog viel op het achtste principe ‘Simplicity – the art of maximizing the amount of work not done – is essential’.
Agile gaat dus om eenvoud. En om bewust dingen niet doen, simpel en met een overzichtelijke scope. Hierin is agile, zoals je weet, niet uniek. Bij Lean draait het om het oplossen, of liever voorkomen, van ‘waste’. En ook bij Prince2 en PointZERO gaat het om zorgen dat je precies die dingen doet die nodig zijn en niet meer. Het meeste verlies in de levenscyclus van een informatiesysteem komt door ‘rework’. Amerikaans onderzoek geeft aan dat dertig tot veertig (!!) procent van de inspanning tijdens de levenscyclus hieraan opgaat.
Volgens dit achtste principe van agile moeten we dus enerzijds nastreven dat we onnodige dingen niet maken, en anderzijds dat we de dingen die we doen, in één keer goed doen zodat we ‘rework’ voorkomen.
Hoe kunnen wij als testers daaraan bijdragen? 
Voorkomen van onnodige dingen doen we door vroegtijdig te reviewen, met daarbij vooral aandacht voor de bijdrage die de gevraagde functies gaan bieden aan het vergroten van het succes van de organisatie. Stakeholders schrijven nog wel eens eenvoudig wat ideeën op een bierviltje en verwachten dan dat daarmee een perfect systeem gebouwd zal worden. Als dat dan niet gelukt blijkt te zijn, gaan we met z’n allen lekker aan de gang met verbouwen en herstellen.
Dat kan anders. Wij testers kunnen helpen bij het ‘maximizing of work not done’ door kritische vragen te stellen aan de stakeholders en ze eerst maar eens goed te laten nadenken wat ze nu echt nodig hebben. Iets langer stilstaan bij de requirements win je dubbel en dwars terug in de verdere activiteiten van de applicatielevenscyclus. En het voorkomt dus ‘waste’. Naar mijn mening gaat het principe van ‘simplicity’ vaak verloren in de ambitie van IT’ers om zo mooi mogelijke dingen te maken. We maken de mooiste applicaties met de meest prachtige geinige extra’s. Natuurlijk, creativiteit is goed. Maar ‘te mooi’ is ook ‘te duur’ (in geld en/of tijd) en dus niet ‘fit for purpose’. Juist het niet bouwen van overbodige dingen draagt bij aan ‘maximizing of work not done’.
Bovendien introduceren extra mooie features ook extra risico’s. Wij testers zijn gewend vanuit risico’s te denken, door het uitvoeren van een Product Risico Analyse en het daarbij onderzoeken waar de risico’s niet opwegen tegen de baten (dat wil zeggen het bijdragen aan het succes van de organisatie). Waar de risico’s te groot zijn, moeten we het simpelweg niet doen. Ook dat is ‘maximizing of work not done’!
Het achtste principe van agile is bij uitstek iets waaraan wij als testers kunnen bijdragen. Help mee met het maximaliseren van niet gedane zaken, dan houd je tijd over voor leuke dingen, bijvoorbeeld sinterklaasgedichtjes maken 😉
Veel testplezier!