Een les van een Agile tester: waarom een simpele vraag een grote reactie veroorzaakte

Kernpunten

• De overstap van Waterfall naar Agile verandert meer dan alleen het proces, het verandert hoe, en hoe vaak, mensen worden verwacht te communiceren.
• Een vraag van een tester kan bedreigend aanvoelen voor een developer die nog vanuit een Waterfall-mindset werkt, waarin taken één keer worden vastgelegd en zelden opnieuw ter discussie staan.
• De wrijving is niet persoonlijk. Het is een voorspelbaar symptoom van teams die tijdens een Agile transformatie hun comfortzone verlaten.
• Agile testen vraagt om dagelijkse zichtbaarheid: je werk, én je vragen, liggen open voor iedereen.
• Sterk Agile leiderschap herkent deze overgang en begeleidt het team erdoorheen, in plaats van wrijving te laten escaleren.

Het verhaal: de eerste Agile-ervaring van een nieuwe tester

Vroeg in mijn carrière als Agile Test Engineer werkte ik op een project waar de klant overstapte van Waterfall naar Agile development. Veel van mijn collega’s waren nog gewend aan de oude manier van werken, waarbij requirements één keer werden vastgelegd, testen pas later in het proces gebeurde, en bezwaren terug in een document belandden in plaats van in een gesprek.

Ik pakte een ticket op om te testen en stapte meteen naar de developer om een paar dingen te verduidelijken die me niet logisch voorkwamen, of misschien was ik gewoon nog te nieuw om het ticket volledig te begrijpen. Ik kreeg antwoord en ging verder. Iets later kwam ik terug met een vervolgvraag.

Wat er toen gebeurde, verraste me. De developer verhief haar stem, duidelijk gefrustreerd dat ik opnieuw iets vroeg. Voor mij voelde dit als een normale, logische manier van werken: als iets onduidelijk is, vraag je het na. Ik dacht dat ik iets fout had gedaan en legde het voor aan mijn Test Manager.

Mijn Test Manager, die wél Agile-ervaring had, stelde me gerust: ik had het precies goed aangepakt en mijn vragen waren terecht. Het was een opluchting te weten dat de situatie begrepen werd, en dat er stappen zouden worden genomen zodat het niet verder zou escaleren.

Waarom de developer zo reageerde: een Waterfall-mindset botst met een Agile proces

Het duurde jaren voor ik echt begreep wat er was gebeurd. Goede communicatievaardigheden helpen, maar dat was hier niet de kern van het probleem. De kern was verandering.

Mijn collega was gewend om een taak te krijgen, deze binnen de afgesproken tijd af te ronden, en met rust gelaten te worden, zonder dagelijks haar redenering te moeten toelichten of bevraagd te worden. In haar ervaring was er weinig reden om een taak “hardop te bespreken”. Alles stond op papier en werd als op zich duidelijk beschouwd. Testen gebeurde later in het traject, en eventuele bezwaren gingen opnieuw in een document, niet in een live gesprek.

Agile testen werkt bewust anders: vragen komen vroeg, vaak, en hardop naar boven, soms dagelijks, omdat dat is hoe het team op elkaar afgestemd blijft.

De echte les: Agile betekent zichtbaarheid, niet enkel een nieuw proces

De overstap naar Agile wordt vaak omschreven als een procesverandering, maar de grootste verschuiving is persoonlijk. Agile development betekent je comfortzone verlaten:

• Je werk wordt zichtbaar voor het hele team, niet pas beoordeeld aan het einde.
• Je wordt verwacht je redenering in real time toe te lichten, niet enkel eenmalig vast te leggen.
• Je wordt regelmatig bevraagd over wat je wel en niet hebt gedaan.

Niets hiervan is een persoonlijke aanval. Het is simpelweg hoe Agile zichtbaarheid er in de praktijk uitziet, en het vraagt aanpassing aan beide kanten: testers die leren wanneer en hoe ze vragen stellen, en developers die leren dat vragen geen kritiek zijn.

Wat dit betekent voor Agile testers en teams

Een paar praktische lessen uit deze ervaring, voor iedereen die test of leiding geeft in een Agile team:

• Verwacht wrijving tijdens een overstap van Waterfall naar Agile. Het is een voorspelbare fase, geen teken dat er iets stuk is.
• Testers: je vragen zijn onderdeel van het proces, geen onderbreking ervan. Om verduidelijking vragen is je werk goed doen.
• Developers: dagelijkse zichtbaarheid is geen persoonlijke controle. Het is hoe Agile teams misverstanden vroeg opvangen.
• Leads en Test Managers: benoem de wrijving en ondersteun beide kanten. Een korte geruststelling kan voorkomen dat een eenmalige botsing een patroon wordt.

Veelgestelde vragen

Waarom reageren developers soms sterk op vragen van testers in Agile teams? Meestal gaat het niet om de vraag zelf, maar om de overgang van Waterfall’s “eenmalig vastleggen, later toelichten” naar Agile’s verwachting van continue, real-time communicatie. Developers die nieuw zijn met Agile kunnen herhaalde vragen ervaren als controle in plaats van samenwerking.

Wat is het grootste communicatieverschil tussen Waterfall en Agile? Bij Waterfall worden requirements en bezwaren doorgaans gedocumenteerd en besproken op vaste mijlpalen. Bij Agile is communicatie continu, vragen, verduidelijkingen en uitdagingen gebeuren gedurende de hele sprint, vaak dagelijks, en in de open.

Hoe kunnen teams de overstap van Waterfall naar Agile vergemakkelijken? Door de verschuiving expliciet te benoemen: erkennen dat dagelijkse zichtbaarheid en frequente vragen bij Agile horen, en geen kritiek zijn op een individu. Ondersteuning van een Test Manager of Scrum Master op het moment zelf, in plaats van pas na escalatie, maakt een meetbaar verschil.

Darko is Agile Test Engineer bij M2Q, waar hij werkt aan teststrategie binnen Agile development teams.