Het valt dikwijls niet mee om de behoeften van de business echt scherp te krijgen. Dat geldt niet alleen voor jou als analist maar ook voor de gebruikers en andere stakeholders.
We horen geregeld analisten en andere ICT’ers zeggen dat de gebruikers niet weten wat ze willen. Maar is dat echt zo?
Gebruikers kunnen je direct vertellen wat er onhandig werkt aan hun huidige systeem. En nadat ze nieuwe software in gebruik hebben genomen, komen ze er al snel achter wat onhandig werkt en welke functionaliteit nog ontbreekt.
Gebruikers ontdekken pas welke ondersteuning ze echt nodig hebben, wanneer ze het systeem ‘in handen krijgen’.
Requirements achterhalen
Tijdens de zoektocht naar requirements vragen we de gebruikers feitelijk om in de toekomst te kijken.
We verlangen van ze dat ze zich verplaatsen in hun toekomstige werksituatie, met een gewijzigd werkproces of zelfs een nieuw bedrijfsproces. Aan welke eisen en wensen moet de software dan voldoen?
Dat ze daar nog geen scherp beeld van hebben is niet zo vreemd. Gebruikers gaan uit van hun huidige situatie, dat is hun referentiekader.
Door ze te vragen naar hun requirements voor een nieuwe (door het management gewenste) werkproces, vragen we ze in feite om een voorspelling te doen.
Met agile requirements doe je dat niet!
Agile requirements
In agile probeer je niet in één keer de definitieve requirements te achterhalen. Dat doe je in een aantal validatierondes. Validatie van gerealiseerde software wel te verstaan!
Je laat de (vertegenwoordigers van de) gebruikers, het liefst na elke sprint, feedback geven op de opgeleverde software.
Een essentieel verschil tussen agile en traditionele requirements is dat je in agile onderkent dat niemand (met zekerheid) weet wat de requirements zijn, totdat de software is gerealiseerd en getoetst bij de gebruikers.
Dit heeft verregaande consequenties voor de werkwijze van teams en uiteraard ook van analisten. Dat leg ik (Nicole) je haarfijn uit in mijn nieuwste boek Requirements in Scrum.
Een essentieel onderdeel van de iteratieve en incrementele werkwijze van agile is iteratief valideren. Daarbij vraag je de (vertegenwoordigers van de) gebruikers elke sprint feedback te geven op de ontwikkelde software.
De voorafgaand aan de sprint opgestelde requirements laten goedkeuren door de business wordt dan overbodig. In agile ontdek je de requirements proefondervindelijk.
Iteratief valideren
Scrum heeft voor het iteratief valideren van de software de sprintreview in het leven geroepen. Dat vaak onterecht een demo wordt genoemd.
Tijdens een sprintreview wil je van de business weten wat zij de voornaamste verbeteringen of uitbreidingen op de reeds ontwikkelde software vinden. Je wilt weten hoe je in de eerstvolgende sprint de meeste businesswaarde kunt toevoegen.
Dat doe je door proactief te sturen op het realiseren van het productdoel en de productvisie.
Vier praktische tips voor iteratief valideren en de sprintreview:
- Stel feedbackvragen tijdens de sprintreview en focus daarbij op de verbeterpunten die in de komende twee sprints opgepakt moeten worden. Refereer daarbij geregeld aan het productdoel.
- Een bekende valkuil is het doorspreken van alle opmerkingen en verbeterpunten. Dat kost onnodig veel tijd, schept verkeerde verwachtingen en resulteert in een ondoorzichtige product backlog.
- Uitsluitend afgaan op hetgeen de gebruikers zeggen, is geen goed idee. Hun belangen komen niet altijd overeen met die van de opdrachtgever. Stem daarom, naast gebruikers, ook met stakeholders af die de opdrachtgever daadwerkelijk vertegenwoordigen.
- Laat gebruikers zelf ervaren hoe het is om met het nieuwe systeem te werken. Daarvoor moeten ze zelf ‘achter de knoppen’ zitten, bijvoorbeeld in een proeftuin, of in de praktijk met een betaversie of schaduwdraaien.
Wat is jou ervaring met het valideren van requirements? Doe je dat het liefst voor- of nadat de software is gebouwd? We lezen je opmerkingen over dit artikel en eventuele vragen graag hieronder bij de reacties.
Nicole de Swart & Priya Soekhai
Nicole,
Zoals je terecht stelt, kunnen de mensen er moeilijk mee om als ze requirements voor een toekomstig werken moeten opgeven.
Zoals je ook aangeeft kunnen ze dat wel als ze dingen zien, ervaren. Dan aangeven wat werkt en wat niet loopt veel vlotter.
Als we dan de aanpak van agile bekijken (niet alles vooraf maar in kleine stukjes), lijkt mij dat geen echte oplossing. Het doet exact wat reeds werd gedaan (en niet werkte) maar op een kleinere schaal. Er is geen enkele reden waarom dit wel zou werken (de vele praktijkvoorbeelden komen van ontwikkelaars en niet van gebruikers, dus ze bewijzen niets – alleen een goed gevoel bij de ontwikkelaars).
Informatici zijn gewoon abstract te denken, gebruikers denken concreet: er is een mentale mismatch. Prototyping (met verschillende graden van precisie) lijkt hier een mogelijke oplossing te bieden want de dingen worden concreet gemaakt. Belangrijk is dat je er dan niet teveel effort voor doet want dan komt de inertie-bias bovendrijven. Dus requirements vragen in kleine schuifjes zet je in de startblokken maar zonder prototypen loop je wel 100 naast piste en haalt de finish niet.
Ik ben het niet met je eens, Rik, dat agile exact zou doen wat reeds werd gedaan maar op kleinere schaal (zoals je schrijft). Dat klinkt alsof je de waterval aanpak opknipt in sprints. Agile hanteert echter een fundamenteel andere werkwijze waarbij je samen met de gebruikers en andere stakeholders proefondervindelijk ontdekt hoe de software moet werken. Dit gaat zelfs verder dan prototyping.