Column: De agile review driehoek

Reviews en Inspecties staan al jaren bovenaan de lijst van meest effectieve kwaliteitsmaatregelen. Toch zijn er veel organisaties die stoeien met het goed toepassen ervan. Binnen waterval projecten, vragen formele reviews een discipline die in de dagelijkse praktijk vaak moeilijk is op te brengen. Hoe zit dat met projecten die Agile ontwikkelen? Binnen deze projecten worden de specificaties en testgevallen gedurende de sprint door teamleden van verschillende disciplines uitgewerkt. Omdat het team zelf de oplossingsrichting bepaald, worden de details soms pas laat in de sprint ingevuld. Hierdoor verdwijnt het vertrouwde reviewmoment dat we kennen uit de traditionele ontwikkeling en ontstaat de vraag of en wanneer er gereviewd moet worden.

Om duidelijkheid te krijgen heb ik de agile-test-driehoek gedefinieerd. De Agile testdriehoek onderscheid drie redenen waarom we zouden willen reviewen. Deze zijn Foutdetectie, Efficiëntie & Borging en Acceptatie.

Foutdetectie
Binnen veel SCRUM projecten worden de technische details gedurende de sprint ingevuld door het team. Gedachtenfouten in de specificaties worden dus on the fly ontdekt, en besproken. Maar hoe borg je volledigheid? Hoe dwing je af dat er met verschillende brillen naar de specificaties gekeken wordt. Omdat er bij de aanvang de sprint geen definitieve specificaties zijn ontbreekt het traditionele review moment. Dit stelt ons voor vragen. Moeten we de review dan maar loslaten? Review is juist een zeer effectieve manier van foutdetectie. We kunnen mini-reviews houden, op momenten dat de back log items uitgewerkt zijn. Hierbij kunnen we elementen van de formele inspectie overnemen, zodat we wel met elkaar afstemmen waarop de verschillende reviewers letten (perspective based review), en we checklisten gebruiken. In de Definition of Done (DoD) nemen we in ieder geval op dat elk van de onderdelen gereviewed moet zijn.

Acceptatie
Het is een veel voorkomend probleem dat gerealiseerde oplossingen niet aansluiten bij initiële wens. De old-school oplossing van formele review werkt niet omdat er geen formeel review moment is, maar de business betrekken kan ook op andere manieren. Bijvoorbeeld met de demo- of knoppensessie. Dit werkt het beste als de business bij al bij aanvang van de sprint benaderd wordt; “Als we over twee weken een demo geven, willen we graag na afloop dat je de oplossing accepteert. Wat wil je gezien hebben voordat je je goedkeuring geeft?” Deze aanpak borgt dat er tijdens de demo, maar ook tijdens de sprint een focus is op het uitvoeren de juiste testen.
Naast de standaard testen, kunnen er extra testen worden gepland die de demo scenario’s testen en dus ervoor zorgen dat de demo soepel verloopt. Ervaring leert dat niet alle acceptatie criteria zich laten demonstreren. Aan de extra testen kan het team bewijslast tonen dat ook aan die acceptatiecriteria is voldaan. Het team plant zijn contactmomenten met business en bepaald wat hij de eerste, tweede en derde sprint week kan laten zien.
Bijvoorbeeld door een walkthrough te houden aan de hand van een specificatie, message flow of screenlay-out kan het team toetsen of de oplossing aansluit bij wensen en alvast deelacceptatie krijgen.

Efficiëntie
Reviews worden ook gebruikt om vast te stellen of producten sprint-ready zijn. Bijvoorbeeld dat of de risico’s benoemd zijn, foutafhandelingen omschreven zijn, er bekend is welke systeem onderdelen de wijziging raakt, en of de requirements of acceptatie criteria smart genoeg zijn. Doel van deze controle is het besef dat als deze zaken niet goed zijn ingevuld, de ontwikkeling onnodige vertraging oplevert omdat er extra uitzoek werk nodig is, of omdat de kans groot is dat er fouten gemaakt worden. Door checklisten te gebruiken kan de traditionele review vervangen worden door effectieve to-the-point controles op noodzakelijke producten. Bijvoorbeeld door een Definition of Ready (DoR) af te spreken.

Er zijn een groot aantal review en andere tools tot onze beschikking. Deze kunnen we allemaal kunnen inzetten om bovenstaande doelen te bereiken. De verschillende tools zijn echter niet allemaal even geschikt voor elk van de doelen, dus we moeten ze slim inzetten en de juiste keuzes maken. Onderstaande agile review driehoek kan hierbij helpen. Het geeft de verschillende tools weer in relatie tot het doel waaraan ze een bijdrage leveren.

Door de agile review driehoek toe te passen (en aan te passen aan de situatie en ervaringen), ontstaat er een review strategie die dynamischer is dan de traditionele, die dichter tegen het de doel aanligt en goed past binnen agile ontwikkeling. Wel is er nog steeds discipline nodig om de acties goed uit te voeren. Agile betekent immers niet, dat we maar wat aanrommelen, maar geeft ons de vrijheid om te laten zien dat we professionals zijn. Met bovenstaande aanpak is dit goed mogelijk. Het stelt het team immers in staat duidelijk uit te leggen welke keuzes het heeft gemaakt en dit helpt bij het vertrouwen dat de stakeholders hebben in het team.

———————
Derk-Jan de Grood werkt als testexpert bij Valori. Hij adviseert organisaties bij het inrichten en verbeteren van hun testactiviteiten. Als productmanager werkt hij aan innovaties in het Valori dienstaanbod. Daarnaast spreekt en publiceert hij met groot enthousiasme over ontwikkelingen in het testvak.