De rol die een analist in een scrum teams vervult, verschilt van organisatie tot organisatie, zeker in hybride omgevingen (deels agile, deels traditioneel). Met analist bedoel ik business analist, informatie analist en soortgelijke functies.

Vroeger was er aan het begin van het systeem-ontwikkeltraject een afzonderlijke requirements­fase waarin analisten de requirements definieerden. Tegenwoordig werken we in sprints en zijn requirements een integraal onderdeel van het ontwikkelproces.

De rol van een analist in scrum

Hoewel met agile de aandacht voor requirements is toegenomen, is er weinig informatie te vinden over de rol van business en informatie analisten in agile en scrum. Agile hecht namelijk veel waarde aan multidisciplinaire teams.

Scrum gebruikt geen rolnamen als business analist, informatie ­analist, tester, architect en user experience designer. In scrum zijn uitsluitend de rollen product owner, scrum master en ontwikkelaar onderkent.

Zoals vaak binnen agile is ook de rol die een analist het beste kan vervullen afhankelijk van de situatie. Iedere organisatie of elk team zal daarin zijn eigen weg moeten vinden.

Om je daarbij te helpen heb ik de 6 meest voorkomende rollen die business en informatie analisten in scrum of agile vervullen op een rij gezet.

De 6 meest voorkomende rollen van analisten in scrum of agile

In willekeurige volgorde zijn die rollen in de praktijk:

1. Analist in een projectvoorbereidingsteam

Om goedkeuring en budget voor het project te krijgen, is het in hybride omgevingen soms nodig om vooraf requirements op te stellen.

Een analist of een voorbereidingsteam met analisten doet dat dan meestal. Zij worden gevraagd om de start van een project voor te bereiden tijdens een soort voorfase. Daarin specificeren zij de requirements in meer of mindere mate van detail.

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

2. Analist wordt product owner

Op het eerste gezicht lijkt het logisch om een business of informatie analist 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 verantwoordelijk­heden.

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 agile team uit en bereidt de user stories voor de komende sprints voor. Daartoe onderken je epics en user stories. En je vult, onderhoudt en prioriteert de product backlog in overleg met de stakeholders. De voorbereide user stories dienen bij voorkeur als input voor de refinement. Of ze worden direct ter realisatie overhandigd aan het agile team.

Belangrijk aandachtspunt bij deze optie is dat je zorgt voor actieve betrokkenheid en direct contact tussen de business stakeholders en het agile team. Pas op dat je niet tussen de business en de ontwikkelaars in komt te staan. Gezamenlijke refinements helpen daarbij.

5. Analist in het multidisciplinaire scrum team

De geëigende plek van een analist in scrum is in het scrum team. 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 andere teamleden. Hij moet wel actief deelnemen aan de verschillende scrum events en blijft de voornaamste 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.

Het is zeker in het begin en ook 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 iedereen om daarnaar te handelen.

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

Jouw rol

Dit waren de rollen waarin ik business en informatie 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.

Nicole de Swart

Misschien vind je dit ook interessant

7 reacties

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

    • Nicole de Swart

      Hallo Frans, Zoals je beschrijft zou het inderdaad moeten gaan, maar helaas is dat in veel organisaties (nog) niet de praktijk.
      Met betrekking tot de businesswaarde zou ik het omdraaien. Je schrijft ‘het traceerbaar aangeven van de bedrijfswaarde van Requierement, epics en user stories’.
      Het idee bij agile requirements is dat je begint met de businesswaarde en van daaruit de functionaliteit waarmee die waarde behaald kan worden, definieert. Dit heb ik toegelicht in het blogartikel https://www.reaco.nl/blog/hoe-bepaal-je-businesswaarde-van-user-story/

  • 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”.

    • Nicole de Swart

      Dank voor je aanvulling, Jeroen. Combinaties zie ik inderdaad ook nogal eens voorkomen.

  • Asjen van den Berg

    Ik zou zeggen dat er ook een zevende optie is: De analist wordt architect. In een IT-omgeving waarin meerdere projecten en changes langskomen, kan de architect de architectuurprincipes formuleren en concreet maken, door mee te kijken en te adviseren in de verschillende projecten.
    Optie 3 en 4 zijn in feite workarounds rondom een PO die niet goed functioneert. Je kunt er best mee omgaan op de manier die je omschrijft, maar ideaal is het niet. Het kan verwarring opleveren en levert per definitie extra communicatie op. Doordat er nu een extra schakel (een PO-team/analist) tussen de PO en het ontwikkelteam in staat, komt de visie en de input vanuit stakeholders veel minder goed over bij het ontwikkelteam, die daardoor minder het ‘Waarom’ te horen krijgt, en meer het ‘Wat/Hoe’. Daardoor gaan ze uitvoeren wat al bedacht is, in plaats van zelf na te denken over het probleem van de gebruiker en hoe ze dat zo goed mogelijk op moeten lossen.

    • Nicole de Swart

      Bedankt voor de aanvulling Asjen. En eens, dat 3 en 4 workarounds zijn bij een niet goed functionerende
      PO. 1 t/m 4 zijn allen niet ideal. Het is uitdrukkelijk niet de bedoeling dat de analist tussen de PO en de ontwikkelaars komt te staan. Dat geeft onder andere de nadelen die jij beschrijft. Vandaar dat ik ook aandachtspunten bij de verschillende opties heb gezet.

Geef een reactie