Do’s and don’ts bij het combineren van agile en traditionele requirements
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 cursus 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 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 het bedrijfsdoel 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?
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.