In verschillende organisaties zie we een vergelijkbare situatie optreden. Op het eerste gezicht lijken deze organisaties het best goed voor elkaar te hebben. De agile werkwijze lijkt prima te werken. Maar schijn bedriegt soms.

We geven een praktijkvoorbeeld.

Als analist werk je nauw samen met de product owner. Jullie stemmen regelmatig requirements af met stakeholders. Dit resulteert in een geprioriteerde backlog met user stories.

Tijdens wekelijkse refinements bespreken jullie de user stories die op dat moment de hoogste prioriteit hebben met het agile team.

Over zes iteraties staat de eerste release gepland. Dan moet het team de afgesproken user stories opleveren. Tot nu toe liggen jullie op schema en is het gelukt de geplande user stories op tijd af te ronden.

Alles lijkt goed te gaan, totdat …

Wijzigingen in de requirements

Na de derde iteratie beginnen de stakeholders tegen te stribbelen. Ze zeggen:

“Nu ik het werkend zie, mis ik toch het een en ander. Ik heb wel gezegd dat het op deze manier gebouwd moest worden, maar eerlijk gezegd was ik daar toen niet helemaal zeker van. Nu ik het resultaat zie, worden de consequenties pas echt duidelijk voor mij. Het is echt niet werkbaar zoals het nu is.”

“Geen probleem” zeg jij.

“We zijn flexibel want we werken volgens agile. We kunnen de gewenste aanpassingen als nieuwe user stories toevoegen en in de komende sprints realiseren. Maar we moeten dan wel andere user stories doorschuiven naar de volgende release. Het blijft een kwestie van prioriteiten stellen.”

Herken je dit? Is in jouw organisaties het agile proces ook op deze manier ingericht? Vind je het een goede werkwijze?

Zo ja, lees dan vooral verder!

Je werkt dan namelijk nog op een waterval manier! Het is een verkapte vorm van waterval, namelijk een waterval opgedeeld in stukjes.

Waterval

In de beschreven werkwijze doen stakeholders er verstandig aan om meteen de juiste requirements te definiëren. Anders gaat elke wijziging daarna ten koste van nieuwe functionaliteit.

Dat lijkt verdacht veel op de traditionele aanpak met een RFC-proces (request for change proces).

De voorspelbare reactie van de business is om dan een voorbereidingsfase (vaak aangeduid als Sprint 0) in het leven te roepen, waarin ze de requirements definiëren.

Daarna moet dan een team van analisten de details van de user stories uitwerken. Daarmee lopen ze een paar sprints op de bouwsprints vooruit, zodat ze op tijd nieuwe user stories gereed hebben voor de ontwikkelaars.

Dit is een watervalproces vermomd als agile!

Anticiperen op wijzigingen

In agile help je de business haar doelen te realiseren. Daar is je primaire aandacht op gericht. Niet op requirements.

Je gaat op zoek naar de (IT-)oplossing die daar het meeste aan bijdraagt en derhalve de meeste businesswaarde genereert. Daarbij onderken je dat je die oplossing niet op voorhand kunt uitdenken, zoals we vanuit de watervalaanpak gewend zijn.

In plaats daarvan ontdek je gaandeweg wat de beste oplossing is. Je maakt gebruik van frequente feedback loops om de echte requirements te vinden.

Zo krijgen het Scrum team en ook de stakeholders zelf een steeds scherper beeld van de benodigde oplossing en bijbehorende requirements.

Je anticipeert op wijzigingen, want met zo’n werkwijze ga je onherroepelijk nieuwe inzichten opdoen tijdens de rit.

Nieuw boek in aantocht

Hoe Scrum daar praktisch invulling aan geeft, is Nicole aan het beschrijven in haar derde boek. Het nieuwe boek getiteld ‘Requirements in Scrum’ komt na de winter uit.

We zijn nog op zoek naar een mooie ondertitel. De short list ziet er nu zo uit:

  1. Hoe je als analist doortastend te werk gaat
  2. Hoe je proefondervindelijk tot het beste resultaat komt
  3. Hoe je de juiste requirements vindt en businesswaarde creëert
  4. Hoe Scrum je helpt een fantastisch product op te leveren

Welke ondertitel spreekt jou het meest aan? Waar wil je het liefst meer over weten? We waarderen je feedback enorm en lezen het graag in je reactie hieronder. Dankjewel alvast.

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

9 reacties

  • Sven Rademaker

    Hoe je als analist doortastend te werk gaat
    Of
    Hoe je de juiste requirements vindt en businesswaarde creëert

    • Saskia Huisman

      Hoe je met scrum de meeste business waarde oplevert
      3 en 4 dus samengevoegd
      Ik ben heel benieuwd naar het boek

  • Peter Manz

    Hoe je de juiste requirements vindt en businesswaarde creëert is feitelijk geen taak voor de analist.
    Tenzij wordt bedoeld hoe je de organisatie helpt om hier achter te komen.
    Voldoende aandacht voor de vragen:
    * Wat is nu eigenlijk het op te lossen probleem?
    * Wie heeft dat probleem?
    * Wat moet er mogelijk zijn als het probleem is opgelost..
    Vaak hoor je dat dit waterval is en dat in Agile je dat niet moet doen.
    De analist zou deze vragen moeten stellen en als startpunt voor een analyse voordat met realisatie wordt begonnen.
    Hoe je als analist doortastend te werk gaat heeft weinig met Agile te maken.
    Een analist moet dat immers altijd doen agile of geen agile.
    Proefondervindelijk . . . is in Agile werken niet iets voor het werk van een analist.
    Wat analisten vaak niet doen is bij wijzigingen onderzoeken wat de impact is en deze bij een besluit over een wijziging betrekken.
    Ik zie te vaak dat wijzigingen worden meegenomen zonder een duidelijke beslissing.
    De impact van wijzigingen bepalen is lastig om dat vooraf de scope niet helder is aangeven (zie de vragen hierboven).
    Je weet dan niet of onkunde, incompetentie of een daadwerkelijke noodzakelijke wijziging nodig is.
    Tenslotte Scrum en een fantastisch product . . Scrum is helemaal nooit bedoeld om een fantastisch product op te leveren.
    Scrum is een aanpak om effectief en gecontroleerd een product te leveren waar naar wordt gevraagd.
    De vraag kan ook zijn om een niet zo’n fantastisch product te leveren.
    Wellicht als ondertitel: Hoe de analist helpt om te realiseren wat wordt gevraagd.

  • Sabine Danckers

    Ik ga voor de combinatie van 2 en 3, nl ‘ Hoe je proefondervindelijk de juiste requirements vindt en businesswaarde creëert’. Deze suggestie omdat ik stiekem hoop dat dit de inhoud van het boek dekt. Zo’n boek zou ik nl graag willen lezen 😉

    • Nicole de Swart

      Dat komt mooi uit Sabine, want dat ik precies de kern van het boek. Als ik je ondertitel ga gebruiken, krijg je een gratis exemplaar van me.

    • Anne Breimer

      Helemaal eens met Sabine!! Dat woord “”proefondervindelijk” nodigt je uit om aan de slag te gaan..

  • Eric Pauwels

    ‘Requirements in Scrum’
    Hoe je een product mét business value creëert.

    Beperk diepgaande analyses, omarm verandering en stimuleer voortschrijdend inzicht.

    • Nicole de Swart

      Mooie suggesties. Bedankt Eric.

  • George Pluimakers

    Ik zie mooie elementen. Dan krijg ik toch de neiging van de krenten uit de pap combineren 🙂 Ik kom op:
    Proefondervindelijk de juiste requirements voor wendbaarheid in business doelen en continue klantwaarde

Geef een reactie