De afgelopen jaren hebben we massaal de watervalaanpak vaarwel gezegd en agile en Scrum omarmd. Ondertussen is duidelijk geworden dat agile zijn eigen uitdagingen kent. Dat geldt des te meer als je in een deels agile / deels waterval omgeving werkt. De agile requirementstechnieken zijn dan niet één-op-één toepasbaar. Je moet ze aanpassen aan je specifieke situatie en combineren met traditionele technieken.
Het combineren van de agile en traditionele requirementsaanpak lijkt op het eerste gezicht eenvoudiger dan het is. Ik zie er daar veel analisten mee worstelen. Daarom geef ik je hier de belangrijkste do’s and don’ts.
Wat je beter NIET kunt doen
Zoeken naar de efficiëntste werkwijze
Als je de agile en traditionele requirementsaanpak wilt combineren, ontkom je niet aan inefficiënties. Dat is de prijs die je moet betalen als je niet puur agile of puur waterval werkt, zou je kunnen zeggen. In het eerste geval doe je concessies aan de lean inrichting van agile en in het tweede geval torn je aan de specialistische en geoptimaliseerde fasen van de watervalaanpak.
Wat je vooral WEL moet doen
Requirements doelgericht achterhalen
Als je wilt profiteren van de verworvenheden van agile, is het in de eerste plaats van belang om een doelgerichte werkwijze te hanteren. Dat houdt in dat:
- je primaire focus ligt op het realiseren van de bedrijfsdoelstelling
- je gaandeweg het project ontdekt wat de échte behoeften van de business zijn
- je voortschrijdend inzicht bewust stimuleert en requirements steeds blijft verbeteren
- de voortgang van het project afgemeten wordt aan de te behalen bedrijfsdoelstelling
Dit in tegenstelling tot de oplossingsgerichte werkwijze, waarbij je focust op het te ontwikkelen systeem en de functionele en niet-functionele eisen die daaraan gesteld worden. Dit vanuit de gedachte dat de business op voorhand weet wat ze aan geautomatiseerde ondersteuning nodig heeft. Je vraagt eerst hun requirements uit en na goedkeuring kan het ontwikkelteam ze implementeren. De voortgang van het project wordt vervolgens afgemeten aan de reeds geïmplementeerde requirements. Hiermee stel je dus de requirements voorop en ga je ervan uit dat daarmee het behalen van de bedrijfsdoelstelling volgt.
Wat je beter NIET kunt doen
Proberen om in één keer de definitieve requirements te achterhalen
We weten allemaal dat een substantieel deel van de opgestelde requirements gaat wijzigen. De business ontdekt pas wat ze echt nodig heeft, wanneer ze het systeem ‘in handen krijgt’. Probeer daarom niet om meteen de juiste requirements op te stellen, maar doe dat in een aantal validatieslagen. Laat de business steeds feedback geven op de software en ontdek zo samen wat echt belangrijk voor ze is.
Probeer dus niet om het aantal wijzigingen te beperken, maar juich verbeteringen toe en richt je werkwijze daarop in.
Wat je vooral WEL moet doen
Traditionele requirements zien als toevoegingen op je doelgerichte werkwijze
De beste manier om agile en traditionele requirements te combineren is om de voor jouw project noodzakelijke onderdelen van traditionele requirements toe te voegen aan je doelgerichte werkwijze. Let op: niet vervangen, maar toevoegen.
Ik geef een paar voorbeelden:
- In hybride omgevingen is het vaak wenselijk of noodzakelijk om requirements vroegtijdig (geruime tijd voor de sprint) op te stellen. Beschouw dat dan, in ieder geval zelf, niet als de definitieve requirements. Maar anticipeer op voortschrijdend inzicht bij de business.
- Een voorbereidingsteam met analisten die een aantal sprints vooruit werkt, is in veel organisaties een goede toevoeging. Laat dat echter niet een reden zijn om de refinement-sessies kort voor de sprints achterwege te laten.
- Het is prima om bij het sprint ready maken van user stories meer details vast te leggen dan bij agile requirements gebruikelijk is. Tenzij die documentatie voor een belangrijk deel de mondelinge communicatie met het ontwikkelteam vervangt.
- Als de opdrachtgever traditionele voortgangsrapportages wil hebben, doe je (of de projectmanager) dat uiteraard. Dat betekent echter niet dat je intern ook aan traditionele voortgangsbewaking doet. Bewaak zelf de voortgang door hem te relateren aan de mate waarin de bedrijfsdoelstelling al behaald is.
- Om ten behoeve van beheer en onderhoud de requirements toch uitgebreid en gedetailleerd te documenteren is geen enkel probleem. Het gaat pas problemen geven als je de documentatie niet in de definition of done opneemt.
Kortom door op een slimme manier de agile en traditionele requirements aanpak te combineren, profiteer je ook in een hybride omgeving van de belangrijkste verworvenheden van agile requirements. Daarvoor moet je weliswaar een stukje efficiency inleveren, maar je krijgt er betere systemen en tevreden business stakeholders voor terug.
Wat is jouw ervaring met requirements in een deels agile / deels waterval omgeving? Ik ben benieuwd naar je positieve en negatieve ervaringen met het combineren van agile en traditionele requirements. Deels ze alsjeblieft hieronder.
Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.
Gratis e-book ‘Vliegende start als agile analist’
Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart
Requirementstechnieken expert
Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen
Volg Nicole op:
Doelgericht achterhalen van behoeften is volgens mij de enige goede aanpak, ongeacht de methode die je gebruikt (agile, waterval of om het even wat). Mijn advies: gebruik de methodes die best bij je passen, je omgeving aankan maar gebruik de bedrijfsdoelstellingen (dat zijn er maar enkele bv een vijftal, meer kan je toch niet aan) als rode draad en richtsnoer. Wat daarmee niet strookt, gooi je beter weg.
De strekking van het verhaal is wel duidelijk: het achterhalen van requirements die bijdragen aan de bedrijfsdoelstellingen is het belangrijkste doel van de analist, waarbij de methode een middel is. Dat is inderdaad waar. Belangrijk is ook om de behoefte aan documentatie duidelijk te krijgen. In sommige gevallen is het verstandiger om wat uitgebreider te documenteren, alhoewel dat dan betekent dat je deze documentatie vaker moet aanpassen omdat de organisatie leert. Let wel: ik vind de voordelen van agile ontwikkelen groter, alleen al vanwege het feit dat de organisatie meer functionaliteit krijgt geleverd in in minder tijd en de belangrijkste functionaliteit als eerste. Ik vind dus dat je als analist als eerste moet proberen om de agile insteek toe te passen.
Verder klinkt mij het advies om niet oplossingsgericht bezig te zijn, maar alleen requirements te achterhalen mij wat vreemd in de oren. Grofweg heb je als requirements analist bij software ontwikkeltrajecten twee globale taken: 1. de requirements achterhalen ( en deze te relateren naar de bedrijfsdoelstellingen ) en 2. de applicatie alternatieven tegen elkaar afwegen ( met de voor- en nadelen voor de organisatie ). Je toegevoegde waarde als requirements analist is dat je een advies kan geven over de te kiezen oplossingsrichtingen.
Ja, dank voor je reactie. Ons vakgebied is behoorlijk in ontwikkeling sinds de komst van agile. Zelfs de rol van de requirementsanalist en zijn taken en toegevoegde waarde zijn niet meer hetzelfde als vroeger. Sterker nog in Scrum bestaat de analisten-rol helemaal niet meer en in de praktijk zie ik grote verschillen tussen organisaties.