Ik spreek geregeld analisten die meer agile zouden willen werken. Maar dat lukt niet omdat ze samen werken met stakeholders die traditioneel denken. Niet iedereen in de organisatie maakt immers tegelijkertijd de (cultuur)omslag naar agile.

Als analist heb je met veel verschillende typen stakeholders te maken. De kans is groot dat een deel van hen nog traditioneel denkt.

Misschien heb jij ook wel te maken met:

Elementen uit zowel agile als traditionele requirements

Afhankelijk van het aantal en de macht van de traditioneel denkende stakeholders moet je je werkwijze daarop aanpassen. Zij leggen immers, vaak onbewust, allerlei beperkingen op. Een aanpak die elementen van zowel agile als traditionele requirements in zich heeft is dan een logische keuze.

Zo’n gecombineerde aanpak samenstellen blijkt eenvoudiger gezegd dan gedaan. Het geeft al snel allerlei problemen. Wat ik meestal zie gebeuren is dat analisten onnodig ver terugvallen op de traditionele requirementsaanpak. Dat is jammer want dan blijf je worstelen met de bekende problemen uit de schommelkarikatuur. Terwijl agile daar nu juist een antwoord op heeft gevonden.

Essentiële aspecten

Agile is gelukkig geen strak voorgeschreven methode. ‘Het Scrum raamwerk is doelbewust incompleet en definieert alleen de delen die nodig zijn om Scrum theorie te implementeren.’, is in de officiële Scrum Guide te lezen. En vervolgens ‘Binnen het Scrum raamwerk kunnen diverse processen, technieken en methoden worden toegepast.’ Dat geeft dus volop ruimte om een aanpak op maat te maken.

Maar hoe stel je een aanpak op maat samen? De crux is dat je de essentiële aspecten van agile requirements overeind houdt. En tevens de traditioneel denkende stakeholders tevreden stelt door voor hen extra dingen te doen.

Het kan bijvoorbeeld zijn dat het management van tevoren de scope en de requirements helder wil hebben. Of dat het wenselijk is om meer te documenteren dan agile voorstaat. Prima. Zolang je de requirements op de agile manier blijft achterhalen, is dat goed te combineren.

Houd daarom vast aan de volgende essentiële aspecten van agile requirements:

  • Richt je primair op het realiseren van het productdoel.
    En dus niet primair op het te ontwikkelen systeem en de eisen die daaraan gesteld worden (de requirements).
  • Ontdek gaandeweg het project wat de échte requirements van de business zijn.
    En ga niet zomaar uit van de reeds opgestelde en goedgekeurde requirements.
  • Moedig voortschrijdend inzicht bewust aan en juich iedere verbetering van de requirements toe.
    En probeer dus niet het aantal wijzigingen beperkt te houden door meteen al de juiste requirements boven water te willen halen.

Jouw aanpak op maat

Dus hoe stel je jouw aanpak op maat samen? Door de kern van de agile requirements aanpak te handhaven, en daar de in jouw situatie noodzakelijke traditionele aspecten aan toe te voegen. Als je dat op een goede manier doet, houd je alle stakeholders tevreden en heb je een effectieve werkwijze.

Hoe ik jou daar persoonlijk bij kan helpen, lees je op de informatiepagina van Cocktail van agile en traditionele requirements. Met deze online masterclass help ik je je werkwijze optimaal op jouw praktijksituatie af te stemmen.

Nicole de Swart

Misschien vind je dit ook interessant

3 reacties

  • Vincent

    Dit is momenteel mijn dagelijkse praktijk: een leverancier van een standaard applicatie waarmee contracten worden afgesloten en requirements goedkeuring vereisen. Het functioneel testen in een vroeg stadium door het projectteam en later de gebruikersacceptatietest is dan een middel om te achterhalen in welke mate de inrichting van de applicatie voldoet aan de bedrijfsdoelstellingen. Hierbij proberen we het nieuwe systeem zoveel mogelijk te realiseren op een manier dat we ruimte hebben voor het ’tunen’ van de inrichting zodat het bruikbaar wordt voor de business. Dat vereist wel goede afspraken met de leverancier om niet elke wijziging een change request te laten worden. Tot nu toe lukt dat aardig goed, vereist wel flexibiliteit van beide partijen en een nauwe samenwerking.

  • Anko

    Eerlijk gezegd verrassen we onze stakeholders met werkende software. Zo gauw we de toezegging van de (interne) klant hebben en het budget geregeld is, starten we met een sprint 0 van 2 weken. Daarin doen we een tweetal workshops + zetten de Product backlog op. Dan starten we sprint 1 en leveren meteen iets werkends op bij de Sprint Review. Omdat we standaard BPM-software gebruiken kan dat relatief snel. Binnen een paar sprints hebben we dan echt iets staan waar de klant zelf om gevraagd heeft. We communiceren nl. veel en vaak met hen gedurende dit proces. Voor sommige van onze (overheids) klanten gaat dat te snel, die zijn gewend aan tijdslijnen van 9 tot 18 maanden. Maar op deze manier starten we meteen de dialoog over wat ze willen hebben en niet wat de requirements zijn 😉

  • Rik Manhaeve

    Nicole, je slaat nagels met koppen. Agile zou eigenlijk niet mogen gaan over de software ontwikkeling zelf (wat meestal gebeurt en als een soort excuus voor onzorgvuldigheid wordt gebruikt) maar over het oplossen van een business probleem. Als je het probleem niet begrijpt is creatie van software een verspilling. Het is zeker niet nodig om het probleem in al zijn facetten te begrijpen voor je begint. De situatie verandert, het probleem vandaag is morgen niet meer hetzelfde (de grote lijn zijn vrij stabiel, de details niet). Voortschrijdend inzicht is de weg te gaan. Vele softwareproducenten en opdrachtgevers hebben daar een probleem mee. Ze willen alle details vooraf.

Geef een reactie