Agile en Requirements: Gaat dat wel samen?

Agile en requirements gaat dat wel samen

In de praktijk kom je veel misverstanden tegen over het ontwikkelen van requirements in Agile projecten. Zo zei laatst een manager van een ontwikkelafdeling tegen mij: “Wij gaan SCRUM-en, dus wij hebben straks geen requirements meer.”  Er bestaat dus een beeld dat Agile en requirements niet samengaan.

Op donderdag 22 september was ik aanwezig bij de lezing“Agile Requirements: Not an Oxymoron!” van Ellen Gottesdiener, een internationaal bekende Agile Coach en Requirements Expert.

Oxymorons, heb je daar ooit eerder van gehoord? Vast wel. Laten we eens naar de volgende woordcombinaties kijken. Oud nieuws, publiek geheim, georganiseerde chaos, oorverdovend stil. Allemaal voorbeelden van combinaties van woorden die elkaar tegenspreken. Allemaal oxymorons.

Spreken Agile en Requirements elkaar ook tegen? Kun je bij ‘Agile Requirements’ ook spreken van een oxymoron? Immers, requirements staat voor velen van ons synoniem voor zorgvuldige, langdurige analyse vooraf met uitgebreide documentatie in de vorm van modellen en specificaties. Terwijl Agile staat voor flexibiliteit, ontwikkeling in iteraties, korte cycli en krijgen van feedback.

“Nee.”, zegt Ellen Gottesdiener, “Agile en Requirements kun je heel goed samenbrengen.” En moet je zelfs samenbrengen om de complexe (‘wicked’) problematiek van software ontwikkeling op te kunnen lossen. Je hebt nl. te maken met  heel veel keuzemogelijkheden, onzekerheden, belanghebbenden en risico’s.  En dit soort problemen kun je niet (meer) oplossen met alleen klassieke analysetechnieken, want zodra je begint met het oplossen ervan komen nieuwe problemen en nieuwe afhankelijkheden aan het licht.

Maar hoe breng je Agile en Requirements dan samen? Gottesdiener doet dat door het bijeenbrengen van de 3 P’s: Partners, Plan en Preparation, waarbij de requirements de basis blijven voor het ontwikkelen van producten. Laten we eens kijken wat zij onder die 3 P’s verstaat.

1. Partners

Wil je een succesvol product ontwikkelen dan zul je 3 groepen belanghebbenden bij elkaar moeten brengen (de klant, de business en technologie). Als partners zullen zij allereerst een gezamenlijke visie moeten vormen op zowel het eindproduct als de toegevoegde waarde. Waarbij zij beseffen dat de toegevoegde waarde afhankelijk is van de context en kan wijzigen in de tijd. Vervolgens zullen zij continu moeten samenwerken om de requirements te onderzoeken, te evalueren, in te plannen en te valideren. Dit alles om de toegevoegde waarde van de oplossing te maximaliseren.

2. Plan

Onder ‘plannen’ verstaat Gottesdiener het toewijzen van requirements aan een bepaalde oplevering in de tijd. Om complexe problemen op te lossen zul je ergens moeten starten met het oplossen ervan en daarover feedback moeten krijgen. Feedback is essentieel. En zullen de partners bij iedere oplevering goed moeten evalueren.

Welke requirements in de oplossing leveren toegevoegde waarde?  En welke niet? Zo leren zij het probleem steeds een beetje beter te begrijpen. En zo leren zij de juiste manier te vinden om het op te lossen. Om de toegevoegde waarde te maximaliseren. Om deze reden kun je een planning dus niet ‘in beton gieten’.

Daarnaast zullen de 3 partners requirements moeten toewijzen aan 3 verschillende termijnen:
– de ‘big-view’      de product roadmap; 1-3 jaar
– de ‘pre-view’      de releaseplanning; 1-4 maanden
– de ‘now-view’     1-14 dagen

Deze 3 termijnen grijpen op elkaar in. De 3 partners zullen dus continu moeten plannen om te herplannen. Welke requirements komen in aanmerking voor de ‘now-view’, op basis van de gekregen feedback?

3. Preparation

In een Agile werkwijze onderzoeken, evalueren, beperken, plannen en valideren de 3 partners continu en gezamenlijk de requirements om de toegevoegde waarde van de oplossing te maximaliseren. Dit kunnen zij volgens Gottesdiener het beste doen door zgn. ‘gestructureerde gesprekken’ te voeren. Gesprekken die aan de hand van een of ander model worden gevoerd. Dit kunnen zowel snelle informele gesprekken zijn (voor de ‘now-view’) als meer formele bijeenkomsten, zoals bijv. een workshop, (voor de ‘pre-view’ en de ‘big-view’).

In een Agile omgeving worden ‘User Stories’ vaak als gespreksmodel gebruikt Maar ‘User Stories’ alleen zijn niet voldoende om alle requirements, functioneel en niet-functioneel, boven tafel te halen. Daarom adviseert Gottesdiener om de gesprekken aan te vullen met klassieke analysemodellen, zoals bijv. een overzicht van actoren, een stroomdiagram, een datamodel of een beslissingstabel.

Samengevat, Agile en Requirements gaan dus wel degelijk heel goed samen om complexe (‘wicked’) problemen op te lossen. Je zult daarvoor dan wel de 3 groepen belanghebbenden continu moeten laten samenwerken om de requirements op een gestructureerde, modelmatige manier te onderzoeken, te evalueren, in te plannen en te valideren. Of zoals Ellen Gottesdiener de lezing afsloot:

Agile and Requirements form a sensible union. 
We use collaboration for comprehension.
We use feedback for focus.
We balance discovery work with discipline.
We balance exploring with evaluating.
This is really a powerful way to bring Agile and Requirements together.
In fact, we are stopping to go. We are slowing down to speed up.

Reacties zijn welkom!

No comments yet.

Leave a Reply