Hier volgt een fragment uit het boek ‘Requirements in Scrum’.
Scrum hecht veel waarde aan samenwerking en kruisbestuiving. Daarom is een scrum team bij voorkeur multidisciplinair. Dat wil zeggen dat het team alle kennis en vaardigheden in huis heeft om het product te realiseren.
Hoewel analysevaardigheden belangrijk zijn in Scrum, wordt de analistenrol niet expliciet onderkend.
“The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.” (Scrum Guide, 2020)
Scrum gebruikt bewust geen traditionele rolnamen zoals analist, tester, architect en UX designer. Ze hebben allemaal het label ‘Ontwikkelaar’ gekregen.
Daarmee onderstreept Scrum de teamverantwoordelijkheid en wil ze hokjes denken binnen het scrum team tegengaan en de samenwerking bevorderen.
Ontwikkelaars (waar dus ook analisten onder vallen) worden geacht als één team samen te werken en vooral ook werkzaamheden die buiten hun specialisme liggen, (meehelpen) uit te voeren.
De term ‘ontwikkelaar’ heeft in Scrum dus een veel bredere betekenis dan we gewend zijn. Het woord ‘ontwikkelen’ refereert aan het maken van een product. Volgens het Van Dale woordenboek betekent ‘ontwikkelen’ ontwerpen en maken. Dat is dus veel meer dan alleen programmeren.
Verantwoordelijkheid scrum team
In de scrum guide is te lezen:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
De werkzaamheden van een scrum team zijn zeer breed en vereisen ook analysevaardigheden. Van alle leden van een scrum team wordt verwacht dat zij zich inleven in de gebruikers en de organisatie. Ze moeten de gebruikersbehoeften gaan begrijpen, ongeacht of de product owner het uitwerken van requirements aan het team gedelegeerd heeft.
Voortouw nemen
Afhankelijk van de agile volwassenheid van het scrum team, neem je hier als analist in meer of mindere mate het voortouw in. Je helpt de teamleden en de stakeholders om gezamenlijk de requirements scherp te stellen.
Aan de product owner en stakeholders laat je zien welke informatie en welke mate van detail vereist zijn voordat de user stories in een sprints opgenomen worden. Je leert ze dat veel dingen die voor hen misschien logisch zijn dat voor andere vaak niet zijn.
Aan de ontwikkelaars laat je zien wat voor vragen ze het beste kunnen stellen. Je leert ze dat goed doorvragen belangrijk is en dat ze de stakeholders moeten blijven ‘challenge-en’ op waarde. Cruciaal daarbij is dat ze niet meteen een oplossing in duiken en dat ze de gewenste businesswaarde voor ogen houden.
Beide punten zijn zowel voor ontwikkelaars als stakeholders lastig in de praktijk te brengen. En zelfs menig analist heeft hier moeite mee.
Je toegevoegde waarden als analist
Je grootste toegevoegde waarden als analist werkzaam in een Scrum omgeving zijn:
- Het scrum team en de stakeholders helpen om samen te ontdekken wat de requirements zijn. Dat doe je onder andere tijdens product backlog refinements en sprint reviews.
- Zorgen dat iedereen gericht blijft op het leveren van zo veel mogelijk waarde. Daarbij is continue aandacht voor het productdoel essentieel.
- Voorkomen dat er te vroeg in oplossingen wordt gedacht. Ook hiervoor is focus op het productdoel en businesswaarde belangrijk.
Herken je deze toegevoegde waarden van analisten? Of ligt jouw toegevoegde waarde op een ander vlak? We zijn benieuwd hoe jij je rol binnen Scrum invult. Laat je het ons even in een reactie hieronder?
Nicole de Swart & Priya Soekhai
Nicole,
De notie dat ontwikkelaar veel breder is dan programmeur is zeer waardevol maar stelt zich meteen de vraag in hoeverre dit in de praktijk ook zo wordt uitgevoerd. Bestaat daar onderzoek naar om bv na te gaan hoeveel programmeurs, analisten, UX designers in teams zitten? Hoeveel generalizing specialists? Wat is de relatie tot het success gemeten in business termen (tijd en geld spelen hierbij een ondergeschikte rol want het gaat om capabilities en acceptatie)? Onderzoeken met breed perspectief, vele teams en projecten onderzocht, oorzaak en gevolg analyses tussen effectiviteit en team…. Referenties hiervoor (liefst niet van producenten omwille van het risico op bias)?
Rik Manhaeve
Hallo Rik, Je vraagt nogal wat 😉 Er wordt veel onderzoek naar de praktijk van agile gedaan, maar specifiek over de vragen die je stelt, ken ik er geen.
Dag Rik, we hebben geen idee of dat soort onderzoeken bestaan. Het lijkt mij persoonlijk ook totaal niet interessant om dit te weten. Wat voor waarde zou zo’n onderzoek hebben? Waarom zou je dit willen weten?
Het gaat er in Agile niet om wat voor specialisten er allemaal in een team zitten en hoeveel, maar dat het team als één geheel het werk kan verzetten wat nodig is om de juiste waarde te leveren. En het team bepaalt zelf welke specialiteiten ze daarvoor nodig hebben. Als Scrum Master zie ik dat elke situatie uniek is en dat de teams per situatie heel erg kunnen verschillen van samenstelling. Dus zo’n onderzoek is misschien leuk voor mensen die van cijfers houden, maar verder voegt het in mijn ogen niets toe en leidt het eerder af van waar het werkelijk om gaat. Het gevaar bestaat dat dit soort onderzoeksresultaten een eigen leven gaan leiden en dat men op basis hiervan teams gaat inrichten en erop gaat sturen, in plaats van per situatie te kijken wat nodig is.
Michel,
Je hebt deels gelijk. De cijfers kunnen een eigen leven gaal leiden maar als mensen zich daardoor laten sturen zijn ze misschien niet zo zeker van zichzelf of kennen hun eigen situatie niet goed genoeg. Dat een team in eerste instantie goed moet samenwerken, is zo goed als een open deur intrappen. Als je team niet samenwerkt, waarvoor bestaat het dan?
Mijn vrees is dat de crossfunctionaliteit vrij eenzijdig wordt ingevuld (lees sterk technologisch gericht) en dit kan de mogelijke waarde eroderen en de focus (zie de uitspraak van Jeff Gotthelf) vooral op output en niet op outcomes ligt. De grootste slachtoffers hiervan zijn alle stakeholders buiten IT.