Binnen agile is er gelukkig veel aandacht voor requirements. Iedere sprint opnieuw wordt er gekeken wat op dat moment de voornaamste requirements zijn.
Voor de rol van analist is veel minder aandacht. Als analist ben je lid van het multidisciplinaire agile team. Of je ondersteunt de product owner bij het uitvoeren van zijn taken.
Kansen voor analisten
Scrum geeft aan dat de product owner verantwoordelijk is voor het maximaliseren van de waarde van het te ontwikkelen systeem. Met de product backlog en de prioritering van de user stories daarin, laat hij zien hoe hij die waarde denkt te realiseren. Als het goed is zorgt hij er zo voor dat het ontwikkeltraject meer is dan het implementeren van een serie losse user stories.
Maar bij veel teams is het doel van een sprint niet meer dan het bouwen van zoveel mogelijk stories. Met een beetje pech krijg je dan een watervaltraject dat in sprints is opgeknipt. In plaats van een agile traject dat zich focust op het leveren van businesswaarde.
Er zijn echter genoeg product owners die deze hoofdtaak niet goed oppakken. Als dat in jouw organisatie ook het geval is, ligt hier één van de belangrijkste toegevoegde waarden die je als analist kunt hebben.
Je grootste toegevoegde waarde
Je bent van onschatbare waarde als je iedereen gefocust houdt op het productdoel. Als Het productdoel en de productvisie niet helder zijn, is de kans groot dat een agile traject gaat zwalken. Het team werkt dan als het ware met een blinddoek voor.
In agile worden de requirements pas gaandeweg het traject vastgesteld. Je hanteert een iteratieve aanpak. En maakt gebruik van voortschrijdend inzicht en feedback van de gebruikers. Daarbij heb je een richting, een productdoel nodig om te zorgen dat je de goede kant op gaat.
Toch is in veel gevallen het productdoel niet bekend. Of het productdoel lijkt duidelijk maar is in feite een oplossing, geen doel. Maak in dat geval het helder krijgen van het productdoel en de productvisie je topprioriteit.
Competenties analist
Analisten kennen het belang van een productdoel. Ze weten dat een systeem geen doel op zich is maar een middel. Een middel om een verbetering bij de klant of in de interne bedrijfsvoering gestalte te geven.
In theorie kun je het productdoel eenvoudig overnemen uit de projectaanvraag, business case, projectplan of iets dergelijks. Maar in de praktijk is dat zelden het geval. Meestal zijn ze namelijk niet concreet genoeg of zijn het oplossingen. Dit komt omdat de meeste mensen inclusief product owners, in oplossingen denken.
Analisten zijn zich hiervan bewust en beschikken over de vereiste competenties om het productdoel wel op tafel te krijgen. Hoewel dat nog best lastig kan zijn. Het is dan zaak om goed door te vragen naar de reden achter een gewenste oplossing.
Vragen die je bijvoorbeeld kunt stellen om het achterliggende doel boven water te halen:
- Wat levert dat de business op? Welke voordelen heeft die oplossing voor de business?
- Waarom is de opdrachtgever bereid veel geld aan deze systeemaanpassingen uit te geven?
- Wat gaat er mis als we deze oplossing niet bouwen?
Meer praktische handvatten en voorbeeldvragen vind je in de online training De kunst van het doorvragen.
Samenvattend: Als analist heb je alles in huis om juist in agile omgevingen veel toegevoegde waarde te bieden. In het bijzonder wanneer de product owner steken laat vallen of competenties mist.
Vertel me waar jij tegenaan loopt bij het scherp krijgen van het productdoel of het prioriteren op businesswaarde. Gebruik daarvoor het reactieveld hieronder. Dan geef ik je tips.
Nicole de Swart
Hi Nicole,
Wat een leuk artikel weer. Waar loop ik wel eens tegenaan. Ik merk dat stakeholders en het team niet altijd zitten te wachten op vragen en op doorvragen. Ik merk dat zij het wel eens lastige vragen vinden of het lastig vinden om er zo over na te denken. Ook kost het tijd en we hebben immers toch al een oplossingsrichting in gedachten? Stakeholders denken inderdaad snel in oplossingen. Wij krijgen geregeld opdrachten die al oplossend zijn en niet vanuit behoeften (business waarde). Hoe krijg ik stakeholders en mijn team enthousiaster of in de meewerkstand met beantwoorden van vragen en het meedenken? Dank je wel.
Groet,
Eva
Fijn te horen dat je m’n artikel waardeert.
Dat ze het lastige vragen vinden, geeft juist de noodzaak om er wel aandacht aan te geven aan. Als de vragen minder lastig voor ze te beantwoorden zijn en als ze snappen waarom het cruciaal is voor het succes van het project, gaan ze beter meewerken.
Wat je kunt proberen is:
– voorbeelden van mogelijke antwoorden (dus mogelijke productdoelen) geven, bv efficiënter werken, meer terugkerende klanten.
– vragen stellen over de voordelen van de gekozen oplossingsrichting voor de business. Waarom is die oplossing het beste voor de business?
– een antwoord geven waarvan je weet dat ze het daar totaal niet mee eens zijn. Dan is de kans groot dat ze beter hun best doen om een ander antwoord te geven. bv Is het zo dat zo’n CRS-module ervoor gaat zorgen dat …..?
– aangeven wat het verschil is tussen output en outcome en beide samen definiëren