De 5 grootste gevolgen die agile voor het requirementsvak heeft

Sommige analisten beweren dat de veranderingen door agile en scrum wel meevallen. Ik denk dat deze analisten de impact onderschatten. Of dat ze in een hybride omgeving werken die meer traditioneel dan agile is.

Agile en scrum hebben de wijze waarop we software ontwikkelen behoorlijk veranderd. De verschillen tussen een traditionele en een agile aanpak zijn groot. Dit heeft voor alle IT-disciplines grote gevolgen gehad.

Hier volgen de 5 grootste gevolgen die agile voor ons requirementsvak heeft gehad.

1. Brugfunctie

We zeiden vaak dat requirements de brug vormen tussen business en IT. Traditioneel is het de taak van analisten om de requirements uit te vragen bij de business stakeholders en deze eenduidig vast te leggen. Vervolgens gingen ontwerpers, ontwikkelaars en testers op basis van de requirementsdocumentatie aan het werk.

In agile is het achterhalen van requirements geen taak meer van een analist. Het voltallige agile team is er actief bij betrokken. De analist faciliteert hooguit de kennisoverdracht van business naar ontwikkelteam. De ontwikkelaars vernemen zelf direct van de stakeholders wat hun wensen zijn. Daar hoeven ze dan geen uitgebreide requirementsdocumenten meer voor te lezen.

2. Kennisoverdracht

Analisten waren altijd verantwoordelijk voor de requirements. Zij hadden een dagtaak aan het opstellen van de requirements. Hierdoor bezaten zij de kennis over de wensen van de business. Die kennis droegen ze voornamelijk schriftelijk over aan de andere projectleden.

In agile hoeft een analist zijn kennis niet over te dragen aan het ontwikkelteam. Het team gaat namelijk zelf rechtstreeks in gesprek met de product owner en andere vertegenwoordigers van de business. Tijdens refinement meetings bijvoorbeeld vernemen alle teamleden de requirements uit de eerste hand. Daardoor is overdracht van kennis na de meeting niet meer nodig. 

3. Oplossing

Analisten zijn gewend een strikte scheiding aan te houden tussen het Wat en het Hoe. Dus tussen respectievelijk requirements en (technische) oplossingen. We zeggen altijd dat de business gaat over het Wat en de IT’ers over het Hoe.

In agile geldt nog steeds dat te vroeg in oplossingen denken een valkuil is. Het is nog steeds belangrijk eerst de behoeften van de business helder te hebben. Maar in de meeste agile meetings worden requirements en (functionele) oplossingen in samenhang besproken. De vertegenwoordigers van de business en ontwikkelaars wisselen ideeën uit en denken met elkaar mee. Ze zijn sparringpartners geworden met ieder hun eigen achtergrond en expertise.

4. Businesswaarde

Bij traditionele systeemontwikkeling is alles gericht op de gedefinieerde en goedgekeurde requirements. Zo stuurt een projectmanager op basis van de gedefinieerde requirements. En implementeert een ontwikkelaar en test een tester de goedgekeurde requirements. Afhankelijk van de kwaliteit van de requirements levert het systeem meer of minder businesswaarde.

In agile zijn alle teamleden gefocust op het maximaliseren van de businesswaarde. Dit doen ze door al na enkele sprints een systeemincrement op te leveren dat toegevoegde waarde heeft voor de business. Die software breiden ze dan iedere sprint uit met meer businesswaarde. 

Het systeem groeit zo van een zeer eenvoudig systeemincrement naar een volwaardig systeem. In het begin heeft de software slechts beperkte businesswaarde voor een subgroep van de gebruikers. En stap voor stap wordt de businesswaarde steeds groter en voor steeds meer gebruikers interessant.

5. Kwaliteit

De volledigheid, juistheid en eenduidigheid van traditionele requirements is erg belangrijk. We spraken vaak over SMART requirements. Analisten besteedden daar veel aandacht aan. We pasten allerlei methoden en technieken toe om de kwaliteit van de requirements te verhogen.

Door de businesswaarde gedreven manier van ontwikkelen is dat in agile projecten niet meer nodig. Het systeem en dus ook de requirements hoeven niet in één keer goed te zijn. En ook de kwaliteit is niet echt meer van belang. In agile laat je de requirements en het systeem geleidelijk ontstaan. Het ontwikkelteam én de business ontdekken gaandeweg de echte behoeften van de stakeholders.

Meer verschillen tussen traditionele en agile requirements

Natuurlijk zijn er nog veel meer verschillen te noemen. Dit zijn de 5 belangrijkste die ik je mee wil geven. Welke verschillen zou je daar aan toe willen voegen? Zet je aanvullingen of opmerkingen in het reactieveld hieronder. Ik kijk ernaar uit.

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Nicole de Swart

Nicole de Swart

Auteur Handboek Requirements

Volg Nicole op:

Priya Soekhai

Priya Soekhai

Expert agile samenwerken

Volg Priya op:

Tips over agile requirements

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

Abonneren op de tips

Je kunt je op elk moment weer uitschrijven

Copy link