Wat als de ontwikkelaars volledig gespecificeerde requirements willen?

Je kunt als analist wel graag agile willen werken en op een agile wijze met requirements om willen gaan, maar daar heb je ook je teamgenoten voor nodig. Als de ontwikkelaars in je team nog traditioneel denken en volledige requirements willen hebben, valt het niet altijd mee op een agile wijze te werken. 

 Wat doe je bijvoorbeeld als:

  • De ontwikkelaars volledig gespecificeerde requirements willen, terwijl je bij agile requirements juist niet teveel wilt specificeren?
  • De ontwikkelaars een ‘u vraagt wij draaien’-mentaliteit hebben, terwijl je binnen agile juist actieve participatie van ze wilt?

Beide zijn essentieel voor het succesvol toepassen van agile requirements. Dat is ook de reden dat in scrum als richtlijn geldt: Het voltallige ontwikkelteam besteedt 10 % van haar tijd voor het helder maken en verfijnen van de requirements van de komende sprints.

Het achterhalen van requirements is zeker niet iets dat je als agile analist alleen doet. Je achterhaalt de requirements samen met de business én het ontwikkelteam. De meeste agile teams houden hier wekelijks een verfijningsbijeenkomst (refinement meeting) voor.

Participatie van het ontwikkelteam

Voor traditioneel denkende ontwikkelaars is actieve participatie bij het achterhalen van requirements een hele omslag. Ze vinden het bijwonen van requirements of refinement meetings vaak tijdverspilling en zien daar het nut niet van in.

Deze ontwikkelaars proberen te overtuigen met rationele argumenten heeft doorgaans weinig zin. Toch is het de moeite waard om de betrokkenheid en participatie van de ontwikkelaars te bevorderen.

Voornaamste voordelen

Actieve participatie van het ontwikkelteam tijdens de refinement meeting heeft als voornaamste voordelen:

  • Meer businesswaarde

    Je krijgt een systeem met veel meer businesswaarde, als je gebruik maakt van de expertise en creativiteit van het hele multidisciplinaire ontwikkelteam. Als het team begrijpt wat de business met het systeem wil bereiken, kunnen ze meedenken en oplossingen en ideeën aandragen. Zij kennen de (on)mogelijkheden van de techniek als geen ander en komen vaak met ideeën waar een ander niet op komt.

  • Minder specificaties nodig

    Je hoeft de requirements niet uitgebreid te specificeren. Het voltallige ontwikkelteam heeft immers geholpen met het scherpstellen van de user stories. Dit bespaart je veel tijd én minimaliseert de kans op interpretatieverschillen. Zeker wanneer de user stories just in time worden gedetailleerd, heeft het team genoeg aan het vastleggen van enkele geheugensteunen (precies zoals user stories bedoeld zijn).

  • Minder interpretatieverschillen

    Tijdens een refinement meeting komen onduidelijkheden en interpretatieverschillen sneller aan het licht dan bij het schriftelijk overdragen van requirements. Bovendien kun je ze meteen rechtzetten, waardoor ze geen onnodig werk veroorzaken om onder andere fouten te herstellen.

  • Precies het juiste detailniveau

    Je hoeft je als analist niet af te vragen hoe gedetailleerd je de user stories moet uitwerken. De ontwikkelaars weten zelf het beste welke detailinformatie ze nodig hebben. Tijdens de refinement meeting blijven ze vragen stellen totdat ze genoeg weten om de user story in een sprint op te nemen.

Hoe vergroot je de betrokkenheid van de ontwikkelaars?

Om te beginnen is het belangrijk om ontwikkelaars met een ‘u vraagt wij draaien’-mentaliteit  zo ver te krijgen dat ze vragen gaan stellen over de requirements. Je wilt meer contact met ze. Als dat is gelukt, kun je hun betrokkenheid geleidelijk uitbreiden.

Tips om de ontwikkelaars te stimuleren tot het stellen van vragen over requirements, doe je bijvoorbeeld door:

Tip 1. Werk de user stories bewust niet volledig uit

Geef de ontwikkelaars en testers bewust geen compleet uitgewerkte requirements­specificaties. Als je de ontwikkelaars niet alle details geeft die ze nodig hebben, moeten ze wel vragen stellen om aan de ontbrekende informatie te komen. (Overdrijf dit in het begin niet, anders lopen ze tijdens de sprint tegen teveel onverwachte dingen aan.)

Tip 2. Bouw een persoonlijke band op

In de communicatie helpt het enorm als je elkaar persoonlijk kent. Investeer daarom tijd om de ontwikkelaars beter te leren kennen. Verplaats bijvoorbeeld je werkplek (tijdelijk) naar de ruimte waar de ontwikkelaars zitten, al is het maar een paar dagen per week.

Tip 3. Maak het stellen van vragen zeer laagdrempelig

Zorg dat jij (of de product owner of een key user) beschikbaar is voor het beantwoorden van vragen. Ook dan helpt het enorm als je veel bij ze over de vloer komt. En als het op dat moment niet face-to-face kan, zijn whatsapp, skype en telefoon er ook nog.

Tip 4. Neem zelf ook initiatief

Vraag de ontwikkelaars regelmatig of de requirements duidelijk zijn en of je ergens mee kunt helpen. Vraag ook of ze het op prijs stellen als je alvast naar de net gebouwde software kijkt om te checken of je de requirements duidelijk genoeg had gespecificeerd. Je wilt immers misverstanden en onjuiste aannames snel uit de wereld kunt helpen.

Start met planningpoker

Wanneer je geregeld mondeling contact hebt met de ontwikkelaars over de requirements, wordt het tijd om op te schalen naar actieve participatie. Het invoeren van planningpoker is een manier om dat voor elkaar te krijgen. De ontwikkelaars zijn de enige die een goede inschatting van de omvang van een user story kunnen maken. In het begin zal dat ook voor hen niet meevallen. Reken ze daar in geen geval op af.

Zie het als een leerproces en bekijk samen hoe jullie de planningpoker sessies kunnen verbeteren. Mijn ervaring is dat als oorzaak van de onnauwkeurige schattingen vrijwel altijd bij de requirements worden gelegd. De requirements of user stories waren dan niet niet helder of niet volledig.

De oplossing die je dan aandraagt is dat je een user story dan voortaan eerst mondeling toelicht én dat de ontwikkelaars vervolgens vragen stellen totdat ze genoeg weten (voor een 80% betrouwbare schatting). 

Probeer het eens.

Actieve participatie bij het achterhalen van requirements kun je niet afdwingen. De ontwikkelaars er geleidelijk in meenemen, is wel mogelijk. Ik heb het verschillende keren zien gebeuren. Gedragsveranderingen vergen enige tijd, maar de beloning is er dan ook naar. Je gaat merken dat het project dan steeds soepeler gaat lopen

Ik hoor ook graag jouw tips en ervaringen met ontwikkelaars. En ik ben benieuwd hoe zeer de ontwikkelaars in jouw project zijn betrokken bij de requirements? Laat hieronder je een reactie achter. 

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap