De afgelopen jaren hebben we massaal agile en Scrum omarmd. We hebben ook ervaren dat agile zijn eigen uitdagingen kent.

Dat geldt des te meer als je in een hybride omgeving (deels agile / deels waterval) werkt. De agile requirementstechnieken zijn dan niet één-op-één toepasbaar. Je moet ze aanpassen aan je specifieke situatie en combineren met traditionele technieken. (In de online masterclass Inspelen op traditioneel denkende stakeholders ga je dat zelf ervaren.)

Het combineren van de agile en traditionele requirementsaanpak lijkt op het eerste gezicht eenvoudiger dan het is. Om je erbij te helpen 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. 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 het bedrijfsdoel
• je gaandeweg ontdekt wat de échte behoeften van de business zijn
• je voortschrijdend inzicht bewust stimuleert en requirements steeds blijft verbeteren
• de voortgang afgemeten wordt aan het te behalen bedrijfsdoel

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. 

Je gaat er impliciet van uit dat de business op voorhand weet wat ze aan geautomatiseerde ondersteuning nodig heeft. Je vraagt namelijk eerst de requirements uit. Die het ontwikkelteam vervolgens (na goedkeuring) mag implementeren. Bovendien wordt de voortgang van het ontwikkeltraject afgemeten aan de hoeveelheid geïmplementeerde requirements.

Op deze manier stel je de requirements voorop. En je gaat ervan uit dat daarmee het bedrijfsdoel gehaald wordt.

> Wat je beter NIET kunt doen

Proberen 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 definitieve requirements op te stellen. Maar doe dat in een aantal validatieslagen.

Laat de (vertegenwoordigers van de) gebruikers steeds feedback geven op de software. Zo ontdek je samen wat echt belangrijk voor de gebruikers is.

Probeer dus niet 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

Houd vast aan een doelgerichte werkwijze en voeg daaraan net genoeg traditionele elementen toe om de stakeholders mee te krijgen in je agile werkwijze.

Toevoegen, niet vervangen!  Dat is namelijk wat ik veel fout zie gaan.

Een paar voorbeelden:

• Vroegtijdig: In hybride omgevingen is het vaak wenselijk of noodzakelijk de requirements lang van te voren op te stellen. Beschouw die requirements dan zelf niet als de definitieve requirements. Maar anticipeer op voortschrijdend inzicht bij de business.
• Vooruit werken: Een voorbereidingsteam met analisten dat een aantal sprints vooruit werkt, is in veel organisaties een goede toevoeging. Laat dat echter geen reden zijn de refinement meetings kort voor een sprint achterwege te laten.
• Detailleren: Het is prima om bij het uitwerken van user stories meer details vast te leggen dan bij agile requirements gebruikelijk is. Tenzij die documentatie voor een belangrijk deel de participatie van het ontwikkelteam bij achterhalen van de requirements vervangt.
• Voortgangsbewaking: 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 het bedrijfs­doel al behaald is.
• Systeemdocumentatie: 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 het opstellen van de systeemdocumentatie niet in de definition of done opneemt.

Slim combineren

Om in een hybride omgeving van de voornaamste verworvenheden van agile te profiteren, moet je de agile en traditionele requirements aanpak op een slimme manier combineren. Dan krijg je een effectieve aanpak en houd je de stakeholders tevreden.

Daarvoor moet je weliswaar een stukje efficiency inleveren. Maar het levert betere systemen en tevreden business stakeholders op. Omdat je software met veel meer businesswaarde realiseert.

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. Wil je ze hieronder delen?