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 vaak niet 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 voor de richtlijn: Het voltallige agile team 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 product owner of agile analist alleen doet. Je achterhaalt de requirements samen met de business én de ontwikkelaars. De meeste agile teams houden hier wekelijks een verfijningsbijeenkomst (refinement) voor.
Participatie van de ontwikkelaars
Voor traditioneel denkende ontwikkelaars is actieve participatie bij het achterhalen van requirements een hele omslag. Ze vinden het bijwonen van requirements of refinement meetings 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 de ontwikkelaars tijdens de refinements 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 agile team. 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 agile team 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 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 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 requirementsspecificaties. 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 uur per dag.
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 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.
Conclusie
Actieve participatie bij het achterhalen van requirements kun je niet afdwingen. De ontwikkelaars er geleidelijk in meenemen, is wel mogelijk. Ik heb het meerdere keren zien gebeuren, onder andere bij deelnemers aan ons trainingsprogramma Daadkracht met agile requirements.
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
Zeer herkenbaar artikel. Ook ik als PO (net als mijn analist) lopen vast in de passiviteit van een aantal van mijn ontwikkelaars die bovendien user stories van mij verwachten die tot op bit niveau zijn uitgedetailleerd. En dan steeds weer zaken tegenwerpingen in plaats van meedenken in oplossingen en bijdragen aan het samenstellen van goede user stories. De meeste stories moeten zelfs eerst ge-prerefined worden door mijn analist en een ontwikkelaar voordat het in de refinement besproken wordt, anders ontstaat er teveel discussie over en gaat hij niet mee naar de volgende sprint. Het is vooral in de refinement waar ik last heb van dit type ontwikkelaars.
Mijn manager geeft aan dat ontwikkelaars nou eenmaal aan de hand genomen moeten worden en dat kan alleen door een PO die zelf ook ontwikkelaar is geweest. Hij wijt dan ook de houding van mijn team dat ik die specifieke achtergrond niet heb.
Ik erg ben benieuwd naar vergelijkbare ervaringen van andere POs en naar de manier waarop zij uit een dergelijke impasse zijn gekomen!
Misschien helpt het om , in overleg met je manager, de ontwikkelaars verantwoordelijk te maken voor het ‘wil ik ….’ gedeelte van de user stories en als PO alleen het ‘zodat …’ voor te bereiden. In het begin zal dit stroef lopen, dus je moet het even de tijd geven voordat je conclusies trekt.
Dat een user stories niet meteen na de 1e refinement al in een sprint opgenomen kan worden, is niet erg. Voor de meeste stories zijn 2 refinements nodig, is mijn ervaring.
Ik hoop dat je hier iets mee kunt. Succes.
Hallo Eric,
Ik ben een ontwikkelaar. Ik vind het vervelend om te lezen dat er nog veel ontwikkelaars zijn die muren om zich heen bouwen. Dit bevorderd niemand, de PO niet, de ontwikkelaars zelf niet, het project niet en nog erger de klant niet. Dat is voor wie we met zijn allen leuke software voor willen maken.
Mijn ervaring is vaak dat een refinement beweging van binnenuit gestart moet worden. Ik heb in mijn ervaringen ook wel in teams waar ontwikkelaars een ’talk-to-the-hand’-mentaliteit hebben. Dat is gelukkig in mijn huidige project niet zo. Ik los dat zelf op door met veel energie en overtuiging refinements te organiseren, de rest ziet vanzelf ook wel dat het waarde heeft. Ik wens je veel succes met de ontwikkelaars. Ik wilde mijn medeleven hierbij uiten.
Nicole! Super artikel! 😀
Dankjewel Serban,
Gelukkig zijn er ook volop (en steeds meer) ontwikkelaars die wel participeren. Ik denk dat agile daar een positieve bijdrage aan levert.
Hoi Nicole, het is Serhan 😉 maar geeft niet. Het is een eerlijke typo haha. En dat vind ik ook. Er zijn gelukkig wel omgevingen waar het steeds beter gaat mbt agile en refinements!
Het probleem vandaag is vaak tweevoudig: ten eerste, heeft men op Belgisch niveau weinig voeling met wat de PO rol werkelijk inhoudt. Is het een developer? Een functioneel analist met kennis rond applicatie modellering? Is het een project manager? Of een beetje van al het voorgaande?
Ten tweede, vele bedrijven werken met off shore developers. Betrokkenheid is hoe dan ook heel relatief in vergelijking met een on premise team en de honger voor specificatie groot. Interactie jaagt de facturen ook meestal de lucht in. Wat kan desgevallend de goede aanpak zijn als men agile wil werken?
Hoi Yasmina,
Wat jammer dat je dat zo ervaart dat de rol van de product owner bij velen nog vaag is. Vanuit Reaco Academy zijn een 3-tal blogs geschreven die uitleg geven over de rol van de product owner. Ik kan ze je van harte aanraden maar deel ze vooral ook met je collega’s/ product owners in België.
https://www.reaco.nl/blog/product-owner/
https://www.reaco.nl/blog/tijd-om-de-verantwoordelijkheid-van-de-product-owner-te-nuanceren/
https://www.reaco.nl/blog/het-medicijn-tegen-tijdgebrek-van-de-product-owner/
Wat het uitbesteden van ontwikkelwerk aan off-shore teams betreft: uit recente ervaringen van een collega analist blijkt dat dat best goed werkt mits je als organisatie serieus tijd en aandacht besteedt aan het opbouwen van een band met het off-shore team. In plaats van dat het ontwikkelwerk over de muur wordt geflikkerd. Zolang je teamgenoten laat merken dat je naast ze staat, dat je vanuit betrokkenheid frequent contact met ze zoekt en op een agile wijze met ze wilt samenwerken. Dan staat niks het succes van het eindresultaat in de weg en maakt het niet uit of je samenwerkt met een off-shore team of een team op locatie.