Agile, Trendsz, Tooling

Een nieuwe blog in de reeks: Hoe houd je als team een goede review? In de eerste blog lieten we je kennis maken met het onderwerp én vertelden we over de noodzaak van een review. In deel 2 gaan we onder andere dieper in op de vragen: Voor wie is de review? Wat kenmerkt alle betrokkenen? Wanneer houd je een review? En, wat bespreek je tijdens een review?

De doelgroep van een review

Het doel en de doelgroep van een review zijn onlosmakelijk met elkaar verbonden. Om te bepalen voor wie je de review precies houdt, kijk je allereerste naar wat je ermee wilt bereiken. Dat kan een review zijn van een sprint of resultaten van een release train en alles daartussen. Afhankelijk van je doelstelling en bijbehorende insteek, stel je de doelgroep vast. Vaak is de doelgroep divers en bestaat deze uit vele betrokkenen, onder andere:

  • Scrum team
    • Product Owner
    • Scrum master
    • Developers
  • Suppliers en/of teams die leveren
  • Consumers en/of teams die van onze applicatie gebruikmaken
  • Eindgebruikers

Alle stakeholders zijn belangrijk, omdat zij uiteindelijk bepalen of de functionaliteit de lading dekt.

Een review voor het omgaan met software ‘changes’

In de vorige blog vertelden we dat het doel van een review het verkrijgen van feedback is van diegenen die de applicatie uiteindelijk in gebruik nemen. Wanneer er een aanpassing wordt gedaan aan de applicatie, heeft dit consequenties voor de werkzaamheden van de verschillende stakeholders. Van belang is dan ook om zowel de suppliers, consumers en gebruikers te betrekken bij dit proces. Als een applicatie verandert, dan moeten de suppliers daarop anticiperen. Wat moeten zij bijvoorbeeld aanpassen om nog data te kunnen leveren? Hetzelfde geldt voor de consumers; zij zullen aanpassingen moeten doen om de data te kunnen ontvangen. De gebruikers zullen op hun beurt iets zeggen over de usability van de verandering. Belangrijk is dus om goed na te denken wie je voor de review uitnodigt om te informeren over de te verwachtte veranderingen. Van wie heb je feedback nodig om te controleren of je op de juiste weg bent?

"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.

Illustratie 2:4 SOCIAL

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?

Bekijk resultaten

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

werkenbij overall

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz