"Wanneer er een aanpassing wordt gedaan aan de applicatie, heeft dit consequenties voor de werkzaamheden van de verschillende stakeholders."
Interne betrokkenen
Naast stakeholders zijn vanzelfsprekend ook teamleden betrokken. Daarbij kijken we naar de zogeheten in- en output. Wie leidt de review en wat zijn de ontvangende partijen? De in- en output kan voor diegene die de review houdt iets anders betekenen dan voor de personen die aan de review deelnemen. De Product Owner (PO) is verantwoordelijk voor de review. Deze verantwoordelijkheid kan echter ook gedeeld worden, of worden toegewezen aan een ander lid van het team. Dat hangt af van het onderwerp in het demogedeelte van de totale review. Als het bijvoorbeeld gaat om een technisch aspect, dan kan een technisch specialist de demo van dat gedeelte op zich nemen.
Frequentie en reviewmomenten
Wanneer je een review houdt is afhankelijk van de situatie. Kijken we naar sprints in een release of kijken we naar een scaled agile framework proces? Dit kan één keer per 14 dagen tot eens per maand zijn of één keer per kwartaal in geval van een SAFe PI-event. Het is verstandig om de review op vaste, reguliere momenten te houden. Zo kunnen stakeholders wennen aan een vast patroon waarop zij een software change of ander nieuws kunnen verwachten.
Een andere mogelijkheid is de organisatie van een review op uitnodiging. In dat geval moet je je stakeholders tijdig laten weten wanneer iets nieuws gepresenteerd of besproken wordt. Communiceer bij voorkeur ook wat de inhoud van de review gaat zijn. Op deze manier kan de klant zelf beslissen of hij of zij aanwezig wil zijn. Time management is dus van cruciaal belang om duidelijkheid te schetsen en verwachtingen te kunnen managen.
Inhoud per doelgroep
De inhoud van de review hangt af van de doelgroep: Voor wie is de review precies bedoeld? Het management kijkt wellicht naar besparingen of toevoegde waarde, terwijl gebruikers misschien meer geïnteresseerd zijn in de uiteindelijke werking ervan. Kortom, je laat het product zien waaraan gewerkt is. Zijn er meerdere doelgroepen of stakeholders aanwezig? Dan toon je de werking in de breedste zin van het woord.
Tijdens de review geef je inzicht in wat er gaat veranderen. Wat houdt de verandering precies in en waar draagt het toe bij? Dat kan voor een eindgebruiker een opgelost defect zijn, of een functionaliteit die het werk gemakkelijker maakt. Een goede verandering om te tonen aan het management is bijvoorbeeld een productiviteitsverbetering of kostenbesparing.
Afwisseling in vorm
De inhoud van je review hangt ook af van datgene wat er getoond wordt. Gaat het om een functionele verbetering in een applicatie of om een release van een compleet nieuw product? Voor beide situaties ziet de presentatie er – als het goed is – compleet anders uit. Een release van een geheel nieuw product zou met meer exposure gepresenteerd kunnen worden, om het de aandacht te geven die het verdient.
What’s next?
In deel 3 van deze blogreeks bespreken we hoe je precies een goede review houdt. Daarbij komen vragen om de hoek kijken als: Waar vindt de review plaats? En, op welke manier wordt de review gehouden? Welke presentatievorm kies je nou eigenlijk voor welk doel? Wordt het online of fysiek en kies je voor statisch, dynamisch of interactief? In de volgende blog praten we je hierover bij.
Deze blogreeks is tot stand gekomen in samenwerking met: Ruben van der Vloot (Bartosz), Ernst Korpershoek (Bartosz), Stephan Dammers (Bartosz) en Martin Visser (KLM).
Poll
Geef jij weleens een review?