Al sinds jaar en dag houd ik mij bezig met het begrip agile, mijn team en ik schreven bijvoorbeeld de eerste versie van de agile-methodiek Smart al in 1998. In het afgelopen decennium heb ik dan ook talrijke agile-projecten meegemaakt, uitgevoerd door wederom uiteenlopende organisaties, van universiteiten en softwarehuizen, tot overheidsinstellingen, grote banken en verzekeraars.
In de eerste jaren was het vooral zaak het agile-gedachtengoed te evangeliseren, maar op dit moment verlaten meer en meer organisaties hun klassieke aanpakken voor een agile-aanpak, op dit moment meestal Scrum. Daardoor kan ik mijn pijlen inmiddels richten op agile anti-patterns; dingen die misgaan in agile-projecten. Ook erg leuk, want er gaat ook in agile-projecten meer dan genoeg mis. Ook agile is geen silver bullet.
Voorbeelden? Alhoewel je steeds meer mensen hoort zeggen dat ze DE agile-methodiek gebruiken, bestaat er helemaal niet zoiets als DE agile-methodiek. Wel zijn er een heleboel agile-werkwijzen, zoals Scrum, XP, Smart, FDD of Kanban. Elk met hun eigen voorgangers, discipelen en volgelingen, om in de evangelisatie-metafoor te blijven.
Helaas constateer ik dat de agile-comminity toch langzaam wat dogmatischer wordt. Calvinistischer. Populariteit verstart nu eenmaal. Al meerdere malen heb ik discussies meegemaakt dat ik geen smart use cases mag gebruiken in agile-projecten of dat een stand-up meeting geen facilitator mag hebben. Zeggen dat er in de diverse agile-werkwijzen zaken ontbreken die broodnodig zijn in projecten, is dan ook vloeken in de kerk.
De meeste agile-processen focussen namelijk maar op een klein deel van wat er in systeemontwikkelprojecten allemaal gebeurt. Er is tereecht heel veel aandacht voor het schrijven van code, maar er is veel minder aandacht voor analyse, ontwerp en zeker voor testen. Alhoewel de meeste agile-werkwijzen wel over unit testing spreken, onderscheiden ze geen aparte rol voor testers. En unit testing is met name een techniek voor ontwikkelaars, waarbij kort gezegd testcode wordt geschreven voor de eigenlijke code.
Wanneer we echter grote agile-projecten doen voor grote organisaties speelt in mijn optiek de tester een cruciale rol. Er is namelijk veel meer tussen hemel en aarde dan unit testing. Zo coachte ik recent een complex servicegeorienteerd agile-SAP-project. Een unieke aangelegenheid, waarschijnlijk het eerste in zijn soort in Nederland, maar zeker niet het laatste als het aan de projectleden ligt. In dit project speelden onze testers een cruciale rol. Omdat we in korte iteraties software analyseren, ontwerpen, bouwen, testen en opleveren, maken de testers vanaf dag één deel uit van het project. Dat biedt perspectieven.
De unieke kijk op de wereld die testers namelijk aan de dag leggen, onderscheidt ze sterk van ontwikkelaars. Ontwikkelaars bemerken vaak niet of niet snel genoeg de uitzonderingen die testers als het ware vanzelfsprekend wel opmerken. In complexe projecten maken we graag en dankbaar gebruik van dit godgegeven talent. Onze testers zijn dan met de ontwikkelaars medeverantwoordelijk voor het ontwerp van de software. Op deze manier voorkomen we veel fouten in het schrijven van de software nog voordat we ze maken. Eigenlijk is dit een functionele vorm van unit testing.
Helaas focussen veel agile-werkwijzen en -projecten zich (voorlopig) vooral op het schrijven van de juiste code en is er, mede door het ontbreken van de rol tester in de meeste werkwijzen, nog onvoldoende aandacht van de positieve rol die testers in projecten kunnen spelen. En dat is, om in de evangelisatie-metafoor te blijven: zonde. Amen.
Ja, inderdaad. De schrijver van dit artikel komt heel veel projecten tegen waar testers geen deel van uitmaken. Testen is, zowel in traditionele alsook in agile projecten, als professie niet altijd even zichtbaar. En dat is jammer.