De afgelopen jaren hebben we massaal de waterval­aanpak vaarwel gezegd en agile en Scrum omarmd. Ondertussen is duidelijk geworden dat agile zijn eigen uitdagingen kent. Dat geldt zeker ook 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 blijkt niet eenvoudiger te zijn. Ik zie daar geregeld 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 leaninrichting 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 bedrijfs­doelstelling
• 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 bedrijfs­doelstelling

Dit in tegenstelling tot de oplossings­gerichte 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 ontwikkel­team ze implementeren. De voortgang van het project meet je vervolgens af aan de reeds geïmplementeerde requirements. Hiermee stel je dus de requirements en niet de bedrijfsdoelstelling voorop.

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 (of schermprototype) 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 voortgangs­rapportages 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 bedrijfs­doelstelling 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 langer 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.