Expert in requirements

Je rol als analist in agile: 6 opties

Veel diverse mensen

Hoe de rol van analist wordt ingevuld verschilt van organisatie tot organisatie, zeker in hybride omgevingen. Vroeger was er aan het begin van het systeemontwikkeltraject een afzonderlijke requirements­fase waarin wij de requirements opstelden. Tegenwoordig werken we in sprints en zijn requirements een integraal onderdeel van het ontwikkelproces. Hoewel de aandacht voor requirements is toegenomen, is er weinig informatie te vinden over de rol van analisten in een agile-omgeving. Agile hecht namelijk veel belang aan multi­disciplinaire teams en gebruikt geen rolnamen zoals requirements­analist, tester, architect en user experience designer. Scrum kent uitsluitend de rollen product owner, scrum master en ontwikkelaar.

Zoals vaak binnen agile is ook de rol die een analist het beste kan vervullen afhankelijk van de situatie. Iedere organisatie of elk project zal daarin zijn eigen weg moeten vinden. Om je daarbij te helpen heb ik de 6 meest voorkomende rollen die analisten vervullen op een rij gezet. In willekeurige volgorde zijn dat:

1. Analist in een projectvoorbereidingsteam

Om goedkeuring en budget voor het project te krijgen, is het in hybride omgevingen (deels agile, deels waterval) soms nodig om vooraf requirements op te stellen. Een analist of voorbereidingsteam met analisten bereidt dan, tijdens een voorfase, de start van een project voor. Daarin specificeer je, in meer of mindere mate van detail, de requirements.

Bij deze optie is de aansturing van projecten en/of de afspraken met externe leveranciers nog volgens het traditioneel fixed price model.

2. Analist wordt product owner

Op het eerste gezicht lijkt het logisch om analisten te promoveren tot product owner. Hij is immers verantwoordelijk voor de requirements. Dit is zeker een optie, maar realiseer je daarbij dat de product owner een veel zwaardere rol is met extra verantwoordelijkheden. De product owner zorgt niet alleen dat het systeem aan de gebruikersbehoeften voldoet. Maar controleert ook of de bedrijfsdoelstelling gehaald wordt en daarmee de return on investment positief is. De product owner is daarom bij voorkeur een (lijn-, product- of marketing) manager.

Bij deze optie is het cruciaal dat je als product owner ook de bijbehorende autoriteit en beslissingsbevoegdheid hebt.

3. Analist in een product owner team

Als de product owner niet fulltime beschikbaar is, kan hij bepaalde (operationele) taken delegeren. Vaak ontstaat dan een team van analisten en eventueel andere rollen. Die helpen de product owner met het beheren van de product backlog en het uitwerken van user stories. Belangrijke beslissingen en het prioriteren van de product backlog blijven bij de product owner.

Dit is een goede manier om de product owner te ontlasten. Mits hij actief betrokken blijft en nauw samenwerkt met zijn ‘team van assistenten’.

4. Analist in een sprintvoorbereidingsteam

Als er geen product owner is of als hij zijn verantwoordelijkheid niet kan of wil nemen, pakt vaak een team van analisten het requirementswerk op. Je loopt dan enkele sprints voor het ontwikkel-team uit en bereidt de user stories voor de komende sprints voor. Daartoe onderken je epics en user stories en vult, onderhoudt en prioriteert de product backlog in overleg met de stakeholders. De voorbereide user stories dienen bij voorkeur als input voor de product backlog refinement. Of ze worden direct ter realisatie overhandigd aan het ontwikkelteam.

Belangrijk aandachtspunt bij deze optie is dat je zorgt voor actieve betrokkenheid van zowel de business stakeholders als het ontwikkelteam. Dat gaat het beste in gezamenlijke refinement meetings.

5. Analist in het multidisciplinair ontwikkelteam

Scrum team

De geëigende plek van een analist bij Scrum is in het ontwikkelteam. Dat is een multidisciplinair team waarvan de leden gezamenlijk alle benodigde competenties bezitten. Zeker bij een onervaren of onvoldoende betrokken product owner zijn de vaardigheden om requirements uit te vragen cruciaal. In Scrum kan de product owner het uitwerken van requirements (meestal in de vorm van user stories) delegeren aan het ontwikkelteam. Hij moet wel actief deelnemen aan de verschillende Scrum meetings en de beslissingen nemen.

In deze optie is het belangrijk dat je je echt als teamlid opstelt en niet strikt vasthoudt aan je gebruikelijke analysewerkzaamheden.

6. Analist wordt scrum master

Een analist is vaak een goede kandidaat voor de rol van scrum master. Soft skills zijn namelijk in die rol uitermate belangrijk. Als je je meer op coaching wilt richten en het inhoudelijke requirementswerk kunt loslaten, is de rol van scrum master een goede keuze. Dat is zeker in het begin en bij relatief onervaren agile-teams een fulltime rol. Je zorgt er dan als dienend leider voor dat iedereen binnen en buiten het agile-team de agile-principes en -regels begrijpt. Tevens leer je ze om daarnaar te handelen.

Om deze rol naar behoren te vervullen, moet je behoorlijk wat kennis van en ervaring met agile hebben.


Dit waren de rollen waarin ik analisten het meeste zie acteren. Zit jouw rol ertussen? Of is jouw rol op een andere manier vormgegeven? Laat hieronder weten hoe het bij jouw is georganiseerd en of dat goed bevalt, dan kunnen anderen daar nieuwe ideeën uit halen.

Succes met de requirements,

Nicole de Swart

PS Vond je dit artikel interessant? Deel het dan op Twitter, LinkedIn, Facebook of Google+ door op onderstaande knoppen te klikken.


Reacties (3)

Rik Manhaeve
Het is cruciaal dat het probleem/ de opportuniteit goed in kaart is gebracht. Door de analist richting ontwikkeling te trekken ontstaat het risico dat er vanuit de oplossing wordt gedacht (de voorbeelden daarvan zijn legio). Een analist die de product owner bijstaat lijkt mij de beste rol (de product owner weet wat hij wil maar kan het niet goed uitdrukken en dat is precies de toegevoegde waarde van de analist).
Rol 1 (projectvoorbereiding met bepalen van de doelstellingen als kapstok voor de requirements) en rol 3 (in het product owner team waarbij prototypes, navigatiemodellen, klassenmodellen aan de orde zijn) lijken mij het meest aangewezen. Scrum master (rol 6) is geen goede optie - soort methodoloog die tussen hamer (business) en aambeeld (de ontwikkelaars) zit. Alle rollen (buiten 1 en 3) hebben het risico dat de analist een verlengstuk van de ontwikkeling wordt, daarin gezogen wordt en dat is ten nadele van de business.
Rol 2 geeft de business een uitweg om de verantwoordelijkheid te ontvluchten (de analist mag en kan die rol niet nemen).
Frans van Koppen
Zoals zo vaak hangt het af van de omstandigheden. de rol van product owner of scrum master moet je gewoon liggen en je moet er de competenties voor hebben en in aanvulling van de eisen van de product owner: je moet een netwerk hebben in de organisatie voor wie je de oplossing maakt.
Voor wat betreft de rollen 1 en 4: Wat je moet voorkomen is dat er hierdoor weer veel communicatie in de weg loopt en je als analist weer het doorgeefluik wordt met de bekende olifant effecten. Vooral in 1: stel details uit totdat je ze nodig hebt.
Oplossing hiervoor is in het ontwikkelteam en dat is zeer goed mogelijk als het team heel volwassen is en ook de noodzaak voelt om niet alleen een artefact maakt die technisch goed in elkaar ziet en zijn functies goed vervult, maar vooral de goede functies vervult en daadwerkelijk bedrijfswaarde genereert. De product owner is hiervoor weliswaar de eerste verantwoordelijke en zij dient die bedrijfswaarde goed voor het voetlicht kunnen brengen, maar een ontwikkelteam moet deze competentie ook kunnen bevatten.
De angst voor de focus op de technisch oplossing begrijp ik, maar we moeten daar dan toch echt vanaf.
Dit brengt mij nog wel op, wat voor mij nog een nog genoeg ontgonnen gebied is. Welke instrumenten geven we de product owner om een goede relatie te leggen tot de bedrijfsdynamiek: de integrale verandering waarvan de IT verandering een onderdeel uit maakt. Als we deze verbinding kunnen leggen is het traceerbaar aangeven van de bedrijfswaarde van Requierement, epics en user stories beter aantoonbaar.
Jeroen Muts
Dit is idd een goede indicatie waar ons vakgebied zich heen beweegt, zo zie ik het ook. wat mij betreft nog een aanvulling: In de praktijk (ik werk voor een grote organisatie) zie ik ook nog wel eens combinaties van "1 en 5", "3 en 5" of "4 en 5".

Geef een reactie

Gratis preview Handboek Requirements

Cover ‘Handboek Requirements’

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek (eind augustus in de winkel)

Nicole de Swart

Nicole de Swart

Volg Nicole op:

Gratis video met tips voor user stories

Masterclass ‘Vervolmaken van je user stories’

Ontdek hoe je 5 door analisten veel gemaakte fouten omzeilt