Tagcloud

Magere Sprint Reviews

Geschreven door: gertjan oude vrielink

Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen naar wat er bereikt is in de afgelopen Sprint.  De informele presentatie en bespreking van tastbare resultaten heeft als doel feedback te verzamelen en samenwerking te bevorderen. Het resultaat van de Sprint Review is een herziend perspectief van het product en de oplevertermijn. In praktijk komt een effectieve Spint Review niet altijd goed van de grond.

Deelnemers
De Sprint Review biedt een belangrijke kans voor het Scrum Team om feedback te krijgen van hen die niet op een dagelijkse basis betrokken zijn bij uitvoering van de sprint. Voor hen is dit de eerste gelegenheid om de resultaten van de Sprint te bekijken. Om waardevolle feedback te krijgen, is het belangrijk om de juiste belanghebbenden uit te nodigen voor Sprint Review. Denk bijvoorbeeld aan een domein expert, de operationele manager, de product development manager, sales, marketing, support, etc . Eigenlijk iedereen die waardevolle feedback kan leveren en/of belang heeft op de hoogte te zijn van de resultaten en de voortgang. In praktijk zie je startende teams worstelen met het aan boord krijgen van belanghebbenden. Niet alleen weten ze niet welke belanghebbenden er zijn, ze weten zich vaak moeilijk te verplaatsen in hun belang. Dat wordt natuurlijk lastig overtuigen.

Demonstreren
De Sprint Review wordt vaak onterecht ‘sprint demo’ genoemd. Hoewel een demonstratie heel nuttig is, vormt dit niet het primaire doel van de spint review. Review betekent letterlijk herzien. En dat is dan ook de kern van de zaak; het herzien van het product dat in ontwikkeling is. Door middel van een uitvoerig gesprek over de resultaten komen er zinvolle suggesties boven tafel, die de moeite waard zijn om te verkennen, op te nemen of te schrappen. De demonstratie van tastbare sprintresultaten en een concreet gesprek daarover, faciliteren de Sprint Review. Niets biedt zoveel focus als het daadwerkelijk zien hoe iets werkt. Let wel; de Sprint Review is niet de plek voor diepgaande discussies over de oplossing van problemen. Het gaat over het wat en waarom, niet over het hoe.

Als demonstratie discussie faciliteert, wat doen we dan als er niets te demonstreren valt? Wat als er niets af is? De focus zal dan waarschijnlijk verschuiven naar waarom het werk niet afgerond is en welke invloed dit heeft op de afronding van toekomstige sprints. Als het team moeite heeft datgene wat afgerond is te demonstreren, dan hebben we een heel ander probleem. Wat bijvoorbeeld als het team de nodige architecturale wijzigingen heeft doorgevoerd? Teams zullen al snel zeggen dat dit niet te demonstreren is. Dit is vaak niet het geval. Als het team de Product Owner overtuigd heeft van het belang om voorrang te geven aan dit soort werk, dan zullen ze tegelijkertijd ook het één en ander moeten begroten en een concreet doel voor ogen hebben waaraan de gewijzigde architectuur moet voldoen. Hoe weet je anders wat je in een sprint kunt aanpassen? En hoe weet je anders wanneer het voldoet aan de doelstellingen? Het gaat er dus om dat je inzichtelijk maakt dat je invulling hebt gegeven aan de doelstellingen waaraan je gewerkt hebt. Minimaal zou je als team kunnen laten zien dat de (unit) testen na aanpassing van de broncode nog steeds slagen. Maar vaak kan het team ook wel wat meer inzichtelijk maken. Het feit dat iets moeilijk te demonstreren is, is nog geen excuus om het niet te demonstreren.

Voorbereiding
Hoewel de Sprint Review een informele activiteit is, heeft het Scrum Team minimaal wat voorbereidend werk te verrichten. Wie moet er uitgenodigd worden voor de review? Welk werk is er afgerond? Wie gaat de meeting leiden? Wie gaat de demonstratie geven? Hebben we de demo opstelling getest?

Wie moeten er uitgenodigd worden? Aangezien het soms lastig is de verschillende belanghebbenden op een bepaald tijdstip bij elkaar te krijgen is zinnig dit op tijd te regelen. Een periodieke afspraak in de agenda is dan ook aan te raden. Sommige startende teams nemen de beschikbaarheid van de verschillende belanghebbenden als vertrekpunt om de verschillende overige sprintactiviteiten daar omheen te plannen. Dat gaat wat mij betreft wat ver. Het belang van de deelname van belanghebbenden moet centraal staan. De Product Owner verzorgt doorgaans de uitnodigingen naar de belanghebbenden.

Welk werk hebben we afgerond in de sprint? Zorg dat je vóór de Sprint Review helder krijgt. Het team is natuurlijk als geen ander in staat dit te beoordelen, maar de Product Owner keurt het werk formeel goed. Het is niet de bedoeling dat de Product Owner pas in de Sprint Review de resultaten te zien krijgt. Anticipeer hierop richting de Product Owner. En Product Owner; besteed tijd aan je team.

Wie leidt de sessie en wie demonstreert de resultaten? Het is aan te raden dat het team dit rouleert. Het resultaat is immers de inspanning van het hele team. Waarom zou steeds dezelfde persoon in het spotlicht moeten staat? Allerlei flitsende presentaties zijn overbodig en zelfs af te raden; het gaat om de tastbare resultaten van de sprint. Een demo voorbereiden zou dan ook niet meer dan 30 minuten in beslag moeten nemen. Zorg dat je de demo opstelling voorafgaand controleert.

User stories vormen de gemeenschappelijke taal van de betrokkenen. Maak bij de demonstratie duidelijk aan welke user stories er gewerkt is gegeven het doel van de huidige sprint. Daarnaast is het essentieel een duidelijke relatie te leggen tussen een user story en het tastbare resultaat. Immers de user story maakt duidelijk waarom de functionaliteit gemaakt is, voor wie het is en wat het is. Niets werkt meer verhelderend dan dit. Zeker voor belanghebbenden niet frequent aanwezig zijn.

De Product Owner tot slot heeft naast het uitnodigen van belanghebbenden nog iets anders voor te bereiden. De Product Owner bespreekt in de Sprint Review de status van de Product Backlog. Dit omdat de Product Backlog in beweging is ten opzichte van de afgelopen Sprint Review. Hij of zij zal op basis van de huidige inhoud de voortgang inzichtelijk maken. Hoewel de Product Owner een afgevaardigde is van de belanghebbenden, is het niet te verwachten dat elke belanghebbende alle wijzigingen en inzichten op het netvlies heeft. Het is van belang dat verwachtingen ten aanzien van de voorgang en het resultaat inzichtelijk wordt gemaakt. De Product Owner heeft dus wat huiswerk te doen.

Aftekenen van resultaten
Soms worden resultaten afgetekend tijdens de Sprint Reviews. De vraag is of dit wel het geschikte moment is. Immers zoals eerder vermeld is het zaak dat de Product Owner gedurende de sprint de resultaten beoordeelt tegen de vooraf overeengekomen Definition of Done. De Sprint Review zou dan ook niet de plek moeten zijn voor formele goedkeuring; de Product Owner heeft de resultaten al goedgekeurd. Wat als er een senior belanghebbende vindt dat het niet goed is? Op zichzelf zeer waardevolle informatie. Het is echter aan de Product Owner om te bepalen wat en wanneer hij of zij daar iets mee gaat doen. Het werk was goedgekeurd door de Product Owner en kennelijk zijn er ‘nieuwe’ inzichten waarop geacteerd kan worden. Uitgangspunt moet zijn dat de belanghebbenden het mandaat van de Product Owner onderstrepen in plaats van ondermijnen. Belangrijk is om te onderzoeken waarom de Product Owner niet op dezelfde ‘golflengte’ zat met de betreffende belanghebbende.

Belanghebbenden sporadisch aanwezig
De Sprint Review moet gezien worden als een belangrijke activiteit. Eentje die het waard is om te bezoeken. Toch zien belanghebbenden dit wel eens anders.
Ten eerste is dit te verklaren door werkdruk en het idee dat er altijd urgentere dingen te doen zijn. Er wordt aan te veel zaken tegelijk gewerkt, waardoor belanghebbenden niet meer aan de verplichtingen kunnen voldoen. Ze gaan brandjes blussen en hebben te veel oog voor de korte termijn. In zulke situatie is het eigenlijk sterk aan te raden om te stoppen met werken aan projecten met een lage prioriteit. Tot het moment dat ze belangrijk genoeg worden voor belanghebbenden om weer deel te nemen aan de Sprint Review. Is het portfoliomanagement wel goed op orde? Hoe komt het eigenlijk dat we aan te veel projecten tegelijk werken?

Ten tweede zijn belanghebbenden vaak afwezig omdat ze verwachten dat het team er niet in zal slagen productierijpe software te kunnen maken in zo’n korte tijd. En laten we eerlijk zijn, dit lukt een startend team ook niet altijd even goed. Belanghebbenden die wél de eerste sessies bij hebben gewoond zullen dan al snel teleurgesteld afhaken. Streef ernaar om vanaf de eerste sprint tastbare waarde te leveren aan belanghebbenden. Hiermee realiseren de belanghebbenden zich dat frequente reviews hun tijd waard zijn en ze in staat gesteld worden snel feedback te geven aan het team zodat ze der iets mee kunnen doen.

Een derde reden tot slot is de vastgeroeste instelling dat we aan het begin van een project iets definiëren, dat we aan het eind van het project wel komen ophalen. De wereld staat tussentijds echter niet stil. Er zijn tal van redenen waarom verandering gedurende het project niet uit te sluiten is. Hoe later fouten ontdekt worden of hoe later duidelijk wordt dat het resultaat niet aan de verwachtingen voldoet, hoe duurder het is om dit te herzien. En als je je dát realiseert is deelname aan de Sprint Review één van de meest rendabele investeringen.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution