Selecteer een pagina

Webcollege

De rol en toegevoegde waarde van analisten

Dit ga je leren

In dit webcollege leer je hoe je als analist heel veel toegevoegde waarde levert en wat je taken en verantwoordelijkheden zijn. Ik laat je zien wat je positie ten opzichte van de product owner is. En je ontdekt in welk team je het meest waardevol bent.

Klik hieronder de rode en blauwe balken open om de inhoud te lezen. De grijze balken krijg je pas te zien als je deelneemt aan het programma.

Preview

Dit is een preview van één van de webcolleges uit het online programma ‘Agile requirements tot op het gewenste detailniveau uitwerken’.

Het is een nieuw trainings- en coachingsprogramma speciaal ontwikkeld voor analisten in een deels agile, deels traditionele omgeving.

Je ontkomt er niet aan om je werkwijze af te stemmen op je omgeving. Daarbij moet je ook rekening houden met de traditioneel denkende stakeholders en hier en daar concessies doen aan de agile werkwijze.

Wat je nodig hebt is een mix van agile en traditionele technieken die aansluit op jouw praktijksituatie. Maar hoe vind je die mix? Hoe werk je user stories en requirements grotendeels agile uit en kom je toch tegemoet aan de traditionele krachten in je organisatie?

Daar gaan wij je in dit praktische programma mee helpen!

Lees hier wat dit praktische programma precies inhoudt.

Agile requirements tot op het gewenste detailniveau uitwerken

Nicole de Swart

Requirements­­technieken expert & auteur Handboek Requirements

Priya Soekhai

Analist & expert in agile samen­werken

Inhoud van dit webcollege

Bestudeer de hoofdstukken hieronder en maak de opdrachten

Ga naar je coachings​​pagina

HOOFDSTUK 1. KERN REQUIREMENTSVAK

Hoewel de manier waarop we ons werk uitvoeren de afgelopen jaren aanzienlijk is veranderd, is de kern van het requirementsvak onveranderd gebleven.

Het gaat nog steeds om het creëren van een helder en gezamenlijk beeld van de behoefte van de business.

Alle betrokkenen bij het softwareontwikkeltraject, zowel vanuit de business als vanuit ICT, moeten de requirements op dezelfde manier begrijpen. Niet alle requirements zijn voor iedereen even relevant, maar er mogen in ieder geval geen afwijkende beelden ontstaan over de high level en de low level requirements.

Cruciaal binnen het requirementsvak is zorgen dat business en ICT elkaar begrijpen. Of beter gezegd, zorgen dat voor beide de behoeften (aan systeemondersteuning) van de business duidelijk wordt.

Daarvoor is nodig dat:

  • De stakeholders uit de business helderheid krijgen over hun requirements
  • De betrokken ICT’ers begrijpen welke systeemondersteuning de business nodig heeft

Over hoe je dat voor elkaar krijgt en welke methoden en technieken je daarbij het beste kunt gebruiken lopen de meningen uiteen. Dat zie je vooral goed naar voren komen in de verschillende aanpakken om tot traditionele en tot agile requirements te komen. Een in het oog springend verschil is de manier van communiceren.

Er is zowel mondelinge als schriftelijke communicatie nodig, maar in welke verhouding is afhankelijk van de aanpak en van de omstandigheden.

Mondelinge communicatie is nodig om elkaar goed te begrijpen en een gezamenlijk beeld te vormen. Schriftelijke communicatie is nodig om te voorkomen dat belangrijke informatie verloren gaat.

Traditioneel werd er veel nadruk gelegd op het documenteren en dus bewaren van de goedgekeurde requirements. Bij de waterval aanpak is het namelijk cruciaal dat die informatie gedurende lange tijd bewaard blijft en aan andere partijen en disciplines overgedragen wordt.

Agile legt de nadruk meer op het begrijpen van de behoeften en wensen van de business en op het gezamenlijk achterhalen van requirements. Daarvoor is het noodzakelijk dat het ontwikkelteam en de (vertegenwoordigers van de) gebruikers geregeld mondeling contact hebben.

De kern van het requirementsvak is echter onveranderd gebleven!

De volgende kernpunten gelden in elke aanpak:

  • Meerdere perspectieven en alle stakeholdersgroepen in ogenschouw nemen
  • Scope vaststellen en requirements prioriteren. Er zijn immers meer requirements dan dat er tijd en budget is om ze te realiseren
  • Requirements moeten bijdragen en gerelateerd worden aan de bedrijfsdoelen
  • Overzicht creëren en structuur aanbrengen
  • Verwachtingen van stakeholders managen
  • Van high level naar low level requirements. Top down steeds verder inzoomen en dus steeds meer details toevoegen
  • Van requirements naar oplossingen. Niet te vroeg een oplossing in duiken
De taak van een analist binnen agile

Er wordt vaak gezegd dat het onze taak is om requirements te schrijven. Het lijkt wel alsof het draait om het vastleggen, het documenteren van requirements. Degenen die requirements opstellen hebben in sommige organisaties zelfs de functienaam ‘documentalist’.

Het feit dat iets op papier staat, betekent nog niet dat het ook in het hoofden van de mensen zit. En daar gaat het echt om!

Alle betrokkenen moeten hetzelfde beeld hebben van de requirements. ICT’ers hebben die kennis nodig om hun werk goed te kunnen doen, namelijk de software realiseren die aan de gebruikersbehoeften voldoet. Daartoe zullen ook de gebruikers (vertegenwoordigers) en andere stakeholders van de business zich een concreet en gedetailleerd beeld van de requirements moeten vormen.

Het achterhalen van requirements is in agile niet meer (alleen) de taak en verantwoordelijkheid van een analist.

Het is eerder de verantwoordelijkheid van de product owner. Maar ook het ontwikkelteam heeft als taak te zorgen dat zij de business en de requirements begrijpen. Als analist zorg je voor focus en help je de business, vertegenwoordigd door de product owner en eventueel andere stakeholders, en het ontwikkelteam om gezamenlijk de requirements scherp te stellen.

Je brengt de werelden van de business en de ICT’ers dichter bij elkaar, en helpt ze om samen iedere sprint maximale toegevoegde waarde voor de business te leveren. In een hybride omgeving waar business en ICT twee gescheiden werelden zijn, is dat geen eenvoudige taak. Vooral als ze het belang en de kracht van mondeling overleg niet kennen.

In een agile traject is het opstellen van requirements minder complex dan in een traditionele project. Het is daarom voor gebruikers en ontwikkelaars gemakkelijker om de requirements en elkaar te begrijpen. Dat komt omdat je niet meteen alle en ook niet meteen de definitieve requirements opstelt. Dat is in een complexe en dynamische omgeving niet eens mogelijk, omdat dat beeld door voortschrijdend inzicht steeds verandert. Daarom zijn kwaliteitscriteria zoals volledigheid, eenduidigheid en correctheid minder van belang. Ook heeft het niet zoveel zin om vastgelegde requirements te laten goedkeuren.

Daar denken traditioneel denkende stakeholders waarschijnlijk anders over. Zij beschouwen requirements als min of meer vaststaande afspraken, terwijl agile requirements evolueren en meegroeien met de kennis van en nieuwe inzichten over de gebruikersbehoeften.

Opdracht 1a

Beantwoord de volgende vraag over je eigen praktijksituatie:

Hoe goed lukt het nu om een helder en voor business en ICT gezamenlijk beeld van de requirements te creëren?

  • Hoe zorg je ervoor dat business en ICT hetzelfde beeld hebben?
  • Waaruit blijkt dat de betrokken ICT’ers begrijpen welke systeemondersteuning de business nodig heeft?
Opdracht 1b

Laat je door de opgesomde kernpunten van het requirementsvak inspireren om verbeteringen in je werkwijze door te voeren.

  • Voer deze week nog kleine verbeteringen door die weinig tijd kosten.
  • Maak een lijst met verbeteringen die je zelf kunt doorvoeren, zonder dat je daar het management of (traditioneel denkende) collega’s voor nodig hebt. Plan ook wanneer je die verbeteringen gaat doorvoeren.
HOOFDSTUK 2. DE ANALISTENROL BINNEN AGILE

Agile schenkt gelukkig veel aandacht aan requirements. Iedere sprint opnieuw wordt er bekeken wat op dat moment de voornaamste requirements zijn.

De rol van analist krijgt veel minder aandacht. Zo kent scrum uitsluitend de rollen product owner, scrum master en ontwikkelaar.

De analistenrol is dus niet onderkend in scrum. Dat komt omdat agile veel belang hecht aan een multi­disciplinair team dat gezamenlijk verantwoordelijkheid draagt voor het eindresultaat. Scrum gebruikt bewust geen rolnamen zoals analist, tester, architect en user experience designer.

Je bent als analist gewoon onderdeel van het multidisciplinaire ontwikkelteam.

Waarom dat in de praktijk vaak anders is, laat ik in het volgende hoofdstuk zien.

De samenstelling van een ontwikkelteam blijft, bij voorkeur, voor langere tijd gelijk. Dat verhoogt de productiviteit en effectiviteit van het team. De teamleden krijgen dan de kans om goed op elkaar ingespeeld te raken en hun werkwijze steeds verder te verbeteren.

Het idee is dat een multidisciplinaire ontwikkelteam uit maximaal zeven tot negen personen bestaat. Anders lukt het niet om intensief samen te werken en als team verantwoordelijkheid voor het op te leveren product te dragen. De teamleden moeten gezamenlijk alle competenties bezitten die vereist zijn om het gewenste resultaat te realiseren. Dat is inclusief de kennis en vaardigheden om requirements scherp te krijgen.

Als het goed is, is het ontwikkelteam zelforganiserend en krijgen ze daar de ruimte voor. Ze mogen (binnen het scrum raamwerk) als team zelf bepalen hoe ze hun werk uitvoeren en managen, als ze de agile principes maar respecteren.

Niemand, noch het management, noch de scrum master noch de product owner, mag het ontwikkelteam een werkwijze of standaard aanpak voorschrijven. Een organisatie hoort vertrouwen te hebben in het vakmanschap van hun medewerkers en te investeren in de faciliteiten voor de agile teams.

Generalisten of specialisten

Agile verwacht van de leden van het multidisciplinaire team dat ze ook werkzaamheden die buiten hun specialisme liggen, (meehelpen) uitvoeren. Dat benadrukken, is een van de redenen dat scrum voor alle leden van het multidisciplinaire ontwikkelteam dezelfde rolnaam hanteert, namelijk de rolnaam ontwikkelaar.

Dat betekent niet dat alle teamleden ook moeten programmeren! Het is een misverstand dat het multidisciplinaire team uit generalisten moet bestaan. Specialisten zijn bijzonder waardevol want ze leveren doorgaans sneller en kwalitatief beter werk.

Generalist en specialist-op-één-gebied zijn de twee uitersten op de specialisatieschaal.

Een effectief team bekijkt gezamenlijk (in de stand up) welke taken de hoogste prioriteit hebben en wie welke taak oppakt. Uiteraard houden ze daarbij rekening met de competenties en voorkeuren van elk teamlid. Maar iedereen moet een waardevolle bijdrage leveren aan het teamresultaat. Wachten totdat een ander teamlid zijn werk heeft afgerond is er dus niet bij.

De ene keer doe je werk binnen je specialisme, de andere keer help je een andere specialist en leer je al doende nieuwe vaardigheden. Of soms is er geen specialist en moet je het jezelf aanleren. Op deze manier word je steeds waardevoller voor het team en ontwikkel je misschien wel een 2e of 3e specialisme. Perfect.

In hybride organisaties wordt het multidisciplinair werken doorgaans niet voldoende of niet op correcte wijze gestimuleerd en gefaciliteerd. Dat kan resulteren in een van de volgende uitersten:

Als analist (of tester of java programmeur bijvoorbeeld) maak je onderdeel uit van een afdeling met analisten en word je gestimuleerd om een betere analist te worden. Daar word je op beoordeeld en beloond. Je competenties verbreden of een ander specialisme aanleren doet je carrière (op korte termijn) geen goed.

Als teamlid wordt van je geëist dat je je in meerdere vakgebieden specialiseert. Je wordt dan geacht om binnen het agile team meerdere rollen en verantwoordelijkheden op je te nemen, bijvoorbeeld de rol van analist en van tester. Specifieke rollen toekennen draagt niet bij aan de multidisciplinaire samenwerking en gedeelde verantwoordelijkheid die agile zo hoog in het vaandel heeft staan.

Een ander veelvoorkomend punt in dit soort organisaties is dat medewerkers in meerdere teams tegelijkertijd zitten.

Tegelijkertijd voor meerdere agile teams werken is funest voor je productiviteit en voor de productiviteit van de teams als geheel.

Als analist (of ander specialisme) word je soms in meerdere teams geplaatst omdat er een tekort is aan analisten, of omdat er in één team niet genoeg analysewerk voorhanden is. De achterliggende gedachten hierbij is dat analisten alleen analysewerk kunnen doen en dat al het analysewerk door analisten moet gebeuren. Dezelfde gedachtegang gaat voor ieder specialisme op.

Organisaties die hun teams op deze manier bemensen, houden daarmee zelf hun probleem van het tekort aan specialisten in stand. Ook leidt het tot andere problemen zodra er (tijdelijk) minder werk van een bepaald specialisme te doen is.

Mocht jij even geen analysewerk hebben, vraag dan (tijdens de stand up) aan je teamgenoten hoe je ze kunt helpen.

Scrum master en product owner
Opdracht 2a

Beantwoord de volgende vragen over je eigen praktijksituatie:

Waar bevind jij je op de schaal tussen generalist en specialist-in-één-gebied?

  • In welke mate zijn bij jullie de teams bemenst met generalisten / specialisten?
  • Zitten jij en/of je collega’s in meerdere teams en wat is daarvan de reden?
Opdracht 2b
HOOFDSTUK 3. TOEGEVOEGDE WAARDE ANALIST

Als de product owner niet goed functioneert en de te leveren businesswaarde onvoldoende helder weet te maken, ontstaan er problemen met de agile werkwijze.

Als je niet oppast wordt het bouwen van zoveel mogelijk stories het doel van het ontwikkelteam.

Je krijgt dan al snel een watervaltraject dat in sprints is opgedeeld, in plaats van een agile traject dat zich focust op het leveren van businesswaarde. Als dat in jouw organisatie ook het geval is, ligt hier één van de belangrijkste toegevoegde waarden die je als analist kunt hebben.

Hoewel er voor een agile analist geen afzonderlijke taken en verantwoordelijkheden zijn gedefinieerd, zijn analysevaardigheden ook in een agile ontwikkeltraject essentieel. De business moet immers (ook voor zichzelf) helder krijgen wat hun requirements zijn en het ontwikkelteam moet zich inleven in de gebruikers en hun requirements.

Daarbij zijn twee punten cruciaal, namelijk dat ze niet meteen een oplossing in duiken en dat ze steeds de gewenste businesswaarde voor ogen houden. Beide punten zijn lastig in de praktijk te brengen. Dat geldt voor de teamleden en stakeholders, en soms ook voor analisten.

De grootste toegevoegde waarden van analisten in een agile traject zijn:

  • Zorgen dat iedereen gericht blijft op het leveren van zo veel mogelijk businesswaarde (Webcollege B1 en B2)
  • De business en ICT helpen om gezamenlijk de requirements scherp te krijgen (Webcollege C1)
  • Voorkomen dat er te vroeg in oplossingen wordt gedacht (Webcollege C2)

Als analist breng je de werelden van business en ICT dichter bij elkaar.

Dat doe je door de product owner, gebruikers(vertegenwoordigers) en het ontwikkelteam te helpen om elkaar en de requirements beter te begrijpen. Afhankelijk van de agile volwassenheid van de product owner en het ontwikkelteam, neem je hier zelf in meer of minder mate het voortouw in.

Aan de product owner en andere gebruikers(vertegenwoordigers) 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 wilt ze leren dat goed doorvragen belangrijk is en dat ze de business moeten blijven ‘challenge-en’ op businesswaarde.

Je positie als analist
Opdracht 3a
Opdracht 3b

Ga naar het totaal​overzicht