Agile requirements vallen of staan met de actieve betrokkenheid van de business en het scrum team. De samenwerking moet van twee kanten komen. De vertegenwoordigers van de business én het scrum team moeten bereid zijn om actief te participeren bij het uitwerken van requirements.
Het kan een hele klus zijn om dat voor elkaar te krijgen. Zeker wanneer er over en weer weinig vertrouwen is. Als analist kun je daar een belangrijke rol in spelen.
Ervaring met vergroten betrokkenheid business en scrum team
Betrokkenheid kun je niet afdwingen. Maar je kunt wel een heleboel doen om betrokkenheid te stimuleren. En zo betrokkenheid geleidelijk opbouwen en vergroten. En bedenk dat elk stapje in de goede richting winst is.
Onze ervaring is dat vergroten van actieve betrokkenheid tijdens de refinement of tijdens de sprintreview grote impact heeft op het succes van het ontwikkeltraject. Van beide geven we een voorbeeld van hoe je dat zou kunnen bevorderen.
Actieve betrokkenheid scrum team tijdens refinement
Bij een product backlog refinement verfijnt het voltallige agile team de user stories op de product backlog.
Als het goed is bespreken de product owner (doorgaans bijgestaan door een analist en/of gebruikersvertegenwoordigers) en de ontwikkelaars samen, als volwaardige sparringpartners, hoe het systeem de gebruikers het beste kan ondersteunen.
In de praktijk zien we vaak dat één van beide partijen onvoldoende betrokken is. Als bijvoorbeeld ontwikkelaars wel aanwezig zijn maar niet actief meedoen, is het tijd om in actie te komen.
Meer verantwoordelijkheid geven
Een manier om de betrokkenheid van de ontwikkelaars te vergroten is door ze meer verantwoordelijkheid te geven. Dat klinkt wellicht tegenstrijdig. Maar doordat je hiermee een beroep doet op hun expertise en creativiteit pakt het vaak positief uit.
Een beproefde manier om dat te doen is door ontwikkelaars een actieve rol te geven bij het definiëren van user stories. Je maakt dan bijvoorbeeld afspraken over het invullen van het user story template: Als <gebruiker> wil ik <functionaliteit>, zodat <businesswaarde>.
Je spreekt af dat de business stakeholders uitsluitend de onderdelen ‘gebruiker’ en ‘businesswaarde’ mogen invullen. De ontwikkelaars krijgen de verantwoordelijkheid de ‘functionaliteit’ die nodig is om de businesswaarde te leveren, te definiëren.
Dit dwingt ze om zich in de business en de gebruikers te verdiepen. Als analist kun je ze eventueel op weg helpen met het stellen van handige vragen.
Bijkomend voordeel is dat de product owner en de business stakeholders gestimuleerd worden de businesswaarde goed te verwoorden.
Actieve betrokkenheid business tijdens sprintreview
Met de iteratieve werkwijze van agile wil je minimaal eens per sprint feedback van business stakeholders. Feedback op de gerealiseerde software wel te verstaan. Dan pas gaat het systeem voor de business leven. En worden hun behoeften (d.w.z. requirements) helder. Scrum heeft hier de sprintreview voor in het leven geroepen.
In de praktijk zien we vaak dat de sprintreview niet meer is dan een demonstratie van de ontwikkelde software. En meestal ook een manier van het agile team om verantwoording af te leggen. Dat verklaart waarom de sprintreview gewoonlijk (onterecht) demo wordt genoemd.
Het is dan ook niet verwonderlijk dat business stakeholders niet gemotiveerd zijn om naar de sprintreview te komen. Het goede nieuws is dat het de andere kan op net zo werkt. Maak de sprintreview interessant voor de business stakeholders en ze komen er graag naar toe.
Feedbackvragen stellen
Tijdens de sprintreview wil je actieve betrokkenheid van de business. Je wilt het liefst een volwaardige dialoog tussen business en scrum team. Een manier om de betrokkenheid van de business stakeholders te vergroten is het stellen van feedbackvragen.
Dat gaat sowieso een hoop nuttige informatie over de requirements opleveren. En als de ontwikkelaars nog geen rechtstreeks contact met de business heeft, is dit de eenvoudigste manier om ze te laten ervaren hoe nuttig dat is.
Het valt of staat echter met de kwaliteit van de feedback opmerkingen die je van de business krijgt. Voorkom daarom dat de feedback alleen over schermdetails en punten en komma’s gaat. Dat doe je door steeds terug te grijpen op het grotere geheel, het productdoel en de productvisie. Alleen dan zie je welke user stories en requirements de meeste businesswaarde leveren.
Bespreek tijdens de sprintreview met alle aanwezigen waar de focus van de volgende sprint op moet liggen. Deze reviews moeten de plek worden waar business en scrum team bepalen hoe het systeem sprint na sprint vorm krijgt. Naar de sprintreviews komen, wordt dan dé manier om invloed op het in ontwikkeling zijnde systeem uit te oefenen.
Betrokkenheid vergroten?
We hopen dat dit artikel je genoeg ideeën en inspiratie heeft gegeven om de actieve betrokkenheid van de business en het scrum team te vergroten. Of in elk geval de eerste stap in de goede richting te zetten. Elk stapje in de goede richting is er één.
Hoe is in jouw situatie de betrokkenheid van business en scrum team bij de requirements? Ben je tevreden over de samenwerking? Vertel het ons in het reactieveld hieronder. We geven je graag nog aanvullende tips.
Je hebt meer invloed op je omgeving dan je denkt. Dat laten we je graag ervaren in onze masterclass Cocktail van agile en traditionele requirements.
Nicole de Swart & Priya Soekhai
Als de sprintreview bedoeld is als centraal feedback-moment, dan moet de gerealiseerde functionaliteit dus een week tot een paar dagen van te voren worden geleverd aan de genodigden en krijg je dus de review van sprint N ergens in het begin van sprint N+1.
Of krijg je in de review van sprint N feedback op sprint N-1 zodat je deze feedback kunt verwerken in sprint N+1?
De gerealiseerde functionaliteit van te voren leveren is gewoonlijk niet nodig. Je houdt elke sprint (van bijvoorbeeld 2 weken) een sprintreview en neemt de stakeholders dus mee in het steeds verder uitbreiden en verbeteren van de software. Alleen de in de laatste (bijvoorbeeld) 2 weken toegevoegde functionaliteit is nieuw voor ze. Vaak is dat (deels) de in de vorige sprintreview besproken toevoeging.
Wanneer je, aanvullend op de sprintreviews, een review workshop organiseert of proeftuin inricht bijvoorbeeld, dan gaat er inderdaad vaak wel een sprint overheen voordat je de resultaten hebt.
Waarom is er een onderscheid tussen een “scrum team” en “business” ? Ik ga altijd voor end to end. Of zit de weerstand bij de business? 😉
Hallo Peter, Als je bedoeld dat je alle betrokkenen bij elkaar zet en laat samenwerken (end to end) is dat perfect. Wij zien nog vaak een traditionele mindset waarbij analisten in hun eentje verantwoordelijk waren voor het opstellen van de requirements. In agile doe je dat gezamenlijk en proefondervindelijk.
Ja, de weerstand of beter gezegd gebrek aan betrokkenheid zit vaak bij de stakeholders uit de business. Het komt veel voor dat de business de rol van product owner niet of onvoldoende invult. Ook zien we nog te vaak dat stakeholders onvoldoende participeren/samenwerken met het scrum team en bijvoorbeeld niet naar de sprint reviews komen.
Ook voor het scrum team en dan met name de ontwikkelaars geldt dat ze lang niet altijd mee willen werken/denken over de requirements en niet willen deelnemen aan de refinements. Vanuit de watervalaanpak zijn ze gewend alle requirements schriftelijk aangeleverd te krijgen.
Gelukkig gaat de samenwerking tussen scrum team en business steeds beter in veel organisaties.