“De ontwikkelaars willen exact gespecificeerd hebben wat ze moeten bouwen en testen. Ik heb het daardoor erg druk met het uitwerken van de requirements. Maar nog blijven de ontwikkelaars en testers in mijn team continu vragen naar meer informatie en meer details. Ik word er soms moedeloos van.”
Zo beschreef Sebastiaan zijn situatie toen hij deelnam aan ons praktijkprogramma Daadkracht met agile requirements.
Sebastiaan voelde zich onder druk gezet. Hij werd geleefd en kwam niet meer toe aan zijn andere werkzaamheden als business analist. Hoe gedetailleerd hij de requirements ook specificeerde, het was nooit genoeg.
Sebastiaan is zeker niet de enige waarvan wordt verwacht dat hij de requirements tot in detail beschrijft. Iets vergelijkbaars zien we ook bij veel andere analisten. Onterecht worden wij nog vaak 100% verantwoordelijk gehouden voor de requirements.
Met een beetje pech gaan andere teamleden dan achteroverleunen en kritiek leveren op de specificaties in plaats van samenwerken als één team.
Omdat we dit nog steeds geregeld tegenkomen, delen we ons advies aan Sebastiaan in dit artikel.
Daag de ontwikkelaars uit
We hebben Sebastiaan verschillende ideeën en suggesties aan de hand gedaan om zijn probleem op te lossen. De volgende tip sprak hem het meeste aan.
Maak inzichtelijk hoeveel requirementsdocumenten er op dit moment al opgesteld zijn. Daag vervolgens de ontwikkelaars uit om samen met jou vast te stellen welke specificaties ze echt nodig hebben. Dat doe je bijvoorbeeld door ze de volgende twee opties te geven:
Optie 1
We spreken af welke requirementsdocumentie en -specificaties er precies uitgewerkt moeten worden. Voordat jullie gaan bouwen moeten jullie die dan ook echt allemaal lezen.
Optie 2
We gaan een andere werkwijze met minder specificaties uitproberen, waarbij:
- We minimaal 1 keer per week een refinement doen. Dit is een interactieve sessie met het hele agile team en vertegenwoordigers van de business. We spreken daarin de user stories voor de aankomende 2 of 3 sprints door en zorgen samen dat de requirements helemaal duidelijk worden.
- We de summiere beschrijving van een user story alleen aanvullen met extra specificaties als dat echt noodzakelijk is.
- Ik de hele sprint stand by blijf om jullie vragen over de user stories van de lopende sprint te beantwoorden.
Onze ervaring is dat je ongeacht de keuze van de ontwikkelaars uiteindelijk op heel veel minder specificaties uitkomt.
Drie praktijkvoorbeelden
Dit zijn onze persoonlijke ervaringen met de tactiek.
Papieren toren
Priya heeft een keer letterlijk alle requirementsdocumenten die al waren opgesteld op papier uitgeprint. De papieren toren die als gevolg van deze actie uit de printer rolde (gelukkig was het gerecycled papier) op een tafel gelegd en het team de 2 opties voorgelegd. Je raadt het al: het team koos voor optie 2.
Stapel halveren
In een ander project waren de teamleden uiterst kritisch en werd de stapel eerst gehalveerd, en nog een keer gehalveerd, en nog een keer … en uiteindelijk kwamen we uit op 10% die echt relevant was en waarde had voor de klus. Die 10% van de oorspronkelijke documentatie is later nog teruggebracht naar 5%. Daarmee bleek de essentie van de functionaliteit die gerealiseerd moest worden goed te duiden.
Top 3
Met alle teamleden samen hebben we een keer een top 3 vastgesteld van de informatie die aanvullend op de user story beschrijving gespecificeerd moest worden. Dit hebben we een aantal sprints uitgeprobeerd. In het begin wisselde de top 3 per sprint, maar al snel kwamen we tot een gulden middenweg.
De grootste winst
Sebastiaan zag ons derde praktijkvoorbeeld helemaal zitten. Dat bracht hem tot de volgende uitspraak, waar wij hartelijk om moesten lachen.
Het inzicht dat de ontwikkelaars met deze ervaring opdeden, was uiteindelijk de grootste winst. Ze kwamen erachter dat ze veel meer te weten komen door zelf de details te verkennen, dan wanneer ze alleen lezen wat een ander geschreven heeft.
De ontwikkelaars ontdekten ook dat ze vooraf niet alle informatie nodig hebben. De details volgen vanzelf door zich tijdens de sprint in de user story te verdiepen.
Wat is jouw ervaring met ontwikkelaars? Willen ze per se gedetailleerde specificaties of kunnen ze overweg met agile requirements? Deel je ervaring in het reactieveld hieronder. Wij (en de andere lezers) kijken ernaar uit.
Nicole de Swart & Priya Soekhai
Mijn ervaring is dat niet zozeer de ontwikkelaars, maar juist de analisten en de testers gedetailleerde specificaties willen. Vooral specs van de bestaande situatie. Als je als analist een high-level business requirement krijgt en je gaat een workshop plannen om samen met de business de user stories en de acceptatiecriteria op te stellen, dan wil je graag goed beslagen ten ijs komen. Specificaties van het huidige systeem helpen hierbij. In de eerste plaats om te voorkomen dat je telkens aan de ontwikkelaar moet vragen: “Zou je eens in de code willen kijken hoe het systeem zich nu precies gedraagt?” en in de tweede plaats om er achter te komen *waarom* het huidige systeem zich zo gedraagt. Want als de business zegt “We willen graag dat het systeem x doet” en jij kunt ze vertellen “Ja, maar het systeem doet nu y omdat blablabla; is die reden niet meer geldig?”, dan zeggen ze vaak: “O, ja, dat is waar ook, maar dan willen we dat het systeem z doet.” Ik pleit ervoor om vooraf of tijdens een sprint de user stories goed uit te werken, zodat je *na afloop* een goede documentatie hebt van de functionaliteit en de rationales. Overigens zijn user stories niet ideaal als documentatievorm van de bestaande situatie, maar dat is een ander onderwerp.
Hi Hans, Ja eens dat het van belang is waarom het huidige systeem zich zo gedraagt. Dat hoef je niet vooraf gedetailleerd uit te zoeken maar komt (als het goed is) tijdens de refinement aan bod. Dan zit je met alle disciplines rond de tafel. Ik snap dat analisten goed beslagen ten ijs willen komen, maar bij een (redelijk goed functionerend) agile team is dat juist niet de bedoeling. De rol van een analist is immers verschoven van zelf opstellen van de requirements naar het faciliteren van de rechtstreeks afstemming tussen business en IT/agile team.
Dat in veel organisaties de praktijk en mindset nog voor een belangrijk deel traditioneel is, ben ik direct met je eens. Dan moet je inderdaad meer vooraf uitwerken.
Waarom zou je user stories VOORAF goed uitwerken om NA AFLOOP goede documentatie te hebben? Is het niet slimmer om dat TIJDENS de sprint te doen. Dan hoeft het ook niet in de vorm van user stories (die daar inderdaad niet geschikt voor zijn) maar kun je een documentatievorm waar de doelgroep goed mee uit de voeten kan, kiezen.
Ik kan me wel vinden in bovenstaand artikel, maar ik zou willen benadrukken dat dit niet voor alle projecten mogelijk is, hoe agile-minded de organisatie ook is. Vaak heb je te maken met een complex systeemlandschap, waarbij voor elke (nou ja, elke…) kleine aanpassing aan systeem A vooraf goed bekeken moet worden wat de impact precies is op systemen B, C, D en E. Als je tijdens een sprint er achter komt dat er allerlei overleg nodig is met andere ontwikkelteams of zelfs andere organisaties (ketens), dan ben je niet goed bezig. Een grote organisatie kreeg regelmatig klachten van zijn klanten dat het bedrag van hun bestelling dubbel was afgeschreven. Iedereen begrijpt dat je dan niet de sprint moet ingaan met de user story “Als klant wil ik dat het bedrag maar éénmaal wordt afgeschreven, zodat ik niet blut raak”; eerst moet je onderzoeken wat de oorzaak is van het probleem. Maar vervolgens hebben we er nog maanden over gedaan om de teams die verantwoordelijk waren voor de diverse systemen op één lijn te krijgen over de oplossing en over hoe we die systemen in de juiste volgorde konden upgraden. Uiteindelijk gingen we de sprint van ons e-commercesysteem in met een user story van maar één story point, omdat de benodigde aanpassing aan de website minimaal was.
Hoi Hans, de situatie die je beschrijft is herkenbaar. Ook agile-minded bedrijven zijn niet onfeilbaar. Belangrijk is wel dat je als bedrijf met een agile mindset, goed kunt omgaan met voortschrijdend inzicht en de weerbarstige praktijk. Daarom vind ik refinements super belangrijk. Ongeacht een incident/productieprobleem of urgente wens, in de refinement ga je als team verfijnen wat de impact is. Dan pas kun je bepalen welke stappen nodig zijn en in welke volgorde de oplossing uiteindelijk daadwerkelijk live gaat. Het is een goed voorbeeld wat je schetst. Ik ben het enerzijds eens met dat het handig is om belangrijke rationale ergens terug te vinden zijn. Maar wie neemt het op zich om dat consequent bij te houden? In agile ben je als team verantwoordelijk om de juiste oplossing te vinden, dus neem je ook als team de beslissing wat je al dan niet vastlegt. Dit kan en mag per organisatie verschillend zijn. Het is wel erg handig als je op 1 lijn zit maar het is een illusie dat je dit op voorhand tot in alle details kunt overzien, noch kun je het afdwingen. Organisaties die de agile mindset hebben of ambiëren leren vaak al doende en proefondervindelijk hoe om te gaan met voortschrijdend inzicht en ook leren ze al doende hoe ze succesvol kunnen worden in zowel de interne als externe samenwerkingsverbanden.
Helemaal eens dat je de afhankelijkheden met andere team helder moet hebben voordat je een PBLitem / user story in een sprint opneemt. Dat kan erg complex worden. En dat zou dan weer een goede reden zijn om van component teams over te gaan naar feature teams en alles te doen dat mogelijk is om het systeemlandschap (stapsgewijs) minder complex / beter onderhoudbaar te maken. Meestal is dat een langdurend traject en zeker niet eenvoudig, maar daar heb jij veel meer verstand van dan ik, Hans 🙂
In ons Scrum team is herhaaldelijk gediscussieerd over nut en noodzaak van use cases. Dat heeft ertoe geleid dat ik als ontwerper user stories maak met daarin afdoende details voor de developers.
We bespreken de wat grotere of meer complexe stories vaak meerdere keren. Soms wordt er dan wel eens geklaagd dat zaken nog niet ver genoeg zijn uitgewerkt, maar laatst werd er toch ook weer gezegd dat het goed is om ook de discussies mee te krijgen over de oplossing, zodat je al meer ingewerkt raakt in de problematiek.
Onder het kopje Achtergrond “mag” ik dan in de user story wat details kwijt over nut en noodzaak van de story. Deze info is met name van belang voor het bijwerken van de use case. Ik ben in mijn team de enige die dat ding schrijft en leest. De rest leest user stories. Alleen de testers geven wel aan dat ze soms in de use cases kijken.
De use case bevat in dit geval veel voetnoten waarin ik die achtergrondinformatie verwerk. Het lopende verhaal van de use case kan dan beperkt blijven tot de pure bouwspecificaties (al kent de use case ook wel eens wat uitleg paragrafen).
Die voetnoten zijn voor mij (of mijn opvolger) cruciaal om te begrijpen waarom de zaken zijn uitgewerkt zoals ze zijn. Daarmee kun je bij toekomstige wijzigingen veel beter inschatten wat er moet worden gewijzigd en dit uitleggen aan je team.
Dag Maurits, dank voor je reactie. Het siert je dat je de verantwoordelijkheid voelt en die verantwoordelijkheid ook op je neemt om bestaande systeemdocumentatie (de use cases) bij te werken. Blijkbaar doe je het niet voor niets want je schrijft dat de testers er soms ook gebruik van maken indien het nodig blijkt. Ik kan me ook voorstellen dat in het geval er nieuwe collega’s bij het team komen werken dat ze daarmee een basis van systeemdocumentatie hebben aan de hand waarvan ze kunnen inwerken. Wat de voetnoten betreft: ik kan me voorstellen dat in het geval het veel wijzigingen betreft en steeds uitgebreider wordt, het verhuist naar een paragraaf bij de use case. Ik heb ook wel eens meegemaakt dat die gewijzigde info met veel dankbaarheid werd hergebruikt om de release notes samen te stellen van een bepaalde release. Je bepaalt zelf wat voor jullie werkt en goed te overzien is. Het is een illusie dat er helemaal niks wordt gedocumenteerd in een agile werkwijze. Ik heb vaak ervaren bij verschillende bedrijven dat hulpmiddelen zoals Enterprise Architect, Confluence en andere vergelijkbare business-process-modellingtools of UX-tools de mogelijkheid bieden om aanvullende systeeminformatie/documentatie in te beheren en ook te delen. Je moet wel goed afspreken met elkaar wie welke info waar vastlegt, en dat collega’s die daar behoefte aan hebben het ook kunnen terugvinden en teruglezen. Kwestie van goed samen afspreken. Wat je ook doet of wat je werkwijze ook is, toets frequent wat de nut en noodzaak ervan is en hoever je moet gaan in het vastleggen van zaken. Ook het documenteren van zaken is in een agile werkwijze een kwestie van samenwerken zodat belangrijke informatie terug te vinden is (bijvoorbeeld als er een impactanalyse moet worden gemaakt), dat is niet de verantwoordelijkheid van 1 persoon maar een gezamenlijke inspanning. Heel succes met de agile werkwijze 🙂
Wat mij betreft is het niveau van detaillering van de requirements afhankelijk van de situatie. Daarbij wordt de situatie in 90% van de gevallen bepaald door het ontwikkelteam waar je op dat moment mee werkt. Ambities, werkdruk en professionaliteit van de mensen in het team, ongeacht of deze in vaste dienst zijn of zijn ingehuurd, zijn bepalend voor de behoefte aan detaillering die ze wensen.
De teamsamenstelling is vaak een feit waar je (bijvoorbeeld door de arbeidsmarktomstandigheden) maar beperkt invloed op hebt. Kijk dus altijd naar de drijfveren van de mensen waarmee je werkt en probeer daar op aan te sluiten. Gewoon vragen aan de teamleden wat ze leuk vinden om te doen en waar ze naartoe willen groeien is vaak al genoeg om te weten op welk detailniveau de requirements moeten worden aangeleverd. Het motiveren en prikkelen van het team door speelruimte in de requirements open te laten kan bij het ene team heel goed werken en bij een ander team tot veel frustratie leiden. Verdiep je in je team en wees pragmatisch.
Dank voor je aanvulling Robert. Het is inderdaad afhankelijk van de situatie. Bij samenwerken blijft het geven en nemen van beide partijen. Ook een lerende houding is belangrijk, zeker in een agile omgeving. Dus niet vasthouden aan het oude, zoals in de situatie van Sebastiaan het geval was, maar samen zoeken naar een betere werkwijze.