Enterprise Agile – Een praktijkinvulling

Over de voordelen van Agile en Scrum is al veel gepubliceerd. Helaas is de toepassing ervan op grote projecten soms weerbarstig en levert het een aantal uitdagingen en dilemma’s op. In dit artikel laten we hier een voorbeeld van zien, hoe dit is aangepakt en met welk resultaat.

 

Het voorbeeld betreft een meerjarig project bij de Nederlandse Overheid, waarbij een centraal systeem wordt gebouwd dat zal worden gebruikt door meer dan 1500 partijen, zowel overheidsorganen als bedrijven. Het betreft een nieuwbouwtraject (maatwerk), waarbij het oude systeem wordt vervangen, inclusief de bijbehorende migratie. Het volume aan gegevens is groot (orde grootte 50-100 miljoen items in een complex datamodel).

Uitdagingen / dilemma’s

portfolioIn het project is gekozen voor de Scrum-methodiek, waarbij twee Scrumteams parallel aan verschillende delen van het systeem werkten. Elk team bestond uit een domeinspecialist (voor het specificeren), plus een aantal ontwikkelaars en testers.

Toen wij in dit project betrokken werden, liep het project niet soepel. Bij het verbeteren van het voortbrengingsproces kwamen we de volgende uitdagingen en dilemma’s tegen die te maken hadden met de keuze en de toepassing van Scrum in dit project:

1. Lange termijn planning vs agile backlog

Omdat het een meerjarig project betreft waarin diverse partijen betrokken moeten worden, is er behoefte aan een mijlpalen- en tijdsplanning. Volgens de Scrum methodiek is de backlog de manier om de realisatie aan te sturen. De backlog bestaat uit een door de Product Owner op afnemende prioriteit gesorteerde lijst Epics en per Epic een lijst User stories. Binnen de methodiek is het mogelijk om Epics en User stories te markeren voor een bepaalde Release. In elke sprint worden de bovenste User stories van de backlog gebundeld opgepakt en afgerond.
Waar het lastiger wordt is dat wanneer een ruwe Release planning wordt gemaakt, in elk geval voor een groot deel bekend moet zijn welke Epics er zijn en wat de omvang daarvan is. Het schatten van de omvang van Epics is geen onderdeel van de standaard Scrum methodiek. Hier loop je ook tegenaan wanneer een gedetailleerde planning gemaakt dient te worden op User story niveau (om afhankelijkheden tussen de teams te adresseren). Dan moet in elk geval grotendeels bekend zijn welke Stories het betreft en welke omvang (Story Points) deze hebben. Dit wordt pas bekend tijdens de backlog refinement (Grooming) en Planningsessie, die niet langer dan 1 sprint voordat de realisatie start, plaatsvindt en waarbij meestal slechts een deel van een Epic ingeschat wordt.
De uitdaging is dat het ontbreken van een planning het adresseren van afhankelijkheden met de buitenwereld en tussen de teams bemoeilijkt.

2. Specificaties maken duurt te lang

Het komen tot specificaties in afstemming met veel verschillende partijen kost (veel) meer tijd dan een sprint. Dit heeft tot gevolg dat specificaties niet tijdens dezelfde sprint gemaakt kunnen worden als dat ze gebouwd worden.

3. Er is geen goede Product Owner aan te wijzen

De rol van de Product Owner is beperkt: alle (wettelijk bepaalde) functionaliteit moet gerealiseerd worden, en gegeven het grote aantal partijen heeft niemand mandaat als het gaat om het maken van functionele keuzes. Hierdoor wordt ook de volgorde van realisatie veel minder door business value gedreven.

4. Het incrementeel bouwen van een volledig nieuw, complex en groot informatiesysteem is inefficiënt

Doordat van te voren niet voldoende is nagedacht over het totaalproduct en hoe dat samenhangend opgebouwd kan en moet worden, maar direct gestart wordt met de ontwikkeling van User story’s, zijn er steeds vaker en grotere refactorings noodzakelijk, met name door de omvang en complexiteit van het systeem en het landschap van systemen waar het onderdeel van gaat uitmaken. Dit vergroot de hoeveelheid ontwikkelwerk significant.

5. Voor acceptatie en inbeheername door een externe partij wordt meer documentatie verlangd dan het scrum proces nodig heeft

Het scrum proces heeft als voordeel dat er minimaal wordt gedocumenteerd doordat alle betrokken disciplines in één sprint gericht en in nauwe samenwerking een beperkt aantal wensen realiseren. In dit overheidsproject moet de beheerpartij door middel van een formele aanbesteding worden geselecteerd, waarbij juist hoge eisen gesteld worden aan de volledigheid en kwaliteit van documentatie. Consequentie is dat er later alsnog fors gewerkt moet worden aan deze documentatie, waarmee dit voordeel van Scrum volledig verdwijnt en zelfs een nadeel wordt.

Oplossingen

Om de genoemde uitdagingen te adresseren en toch een aantal voordelen van de Scrum methodiek te kunnen blijven benutten is in dit project gekozen voor de volgende aanpak:

1. Planning

Om afhankelijkheden toch te kunnen adresseren wordt met behulp van een paar niet Scrum gerelateerde activiteiten toch een planning gemaakt. Als eerste wordt project opgedeeld in releases. Voor de start van het werk aan een release wordt vooraf bepaald welke Epics het betreft, en deze worden door het scrum team, aangevuld met architecten en domeinspecialisten, ruw geschat ten opzichte van elkaar. Naarmate er meer Epics zijn gerealiseerd, ontstaat voortschrijdend inzicht over de omvang van de rest van het werk. Hetzelfde gebeurt binnen een Epic met User stories: de Scrum methodiek kent het begrip Velocity, waarmee een detailplanning (over meerdere sprints) kan worden gemaakt op basis van geschatte Stories, en ook op basis van ruwe schattingen die pas bij de Grooming/Planning worden opgehard.
Verder wordt aan de opdrachtgever, stuurgroep en andere stakeholders  uitgelegd dat projecten van deze omvang niet van te voren volledig uitgepland kunnen worden, zonder forse investering in vooraf alles specificeren. De behoefte aan een harde planning moet worden gebalanceerd met de behoefte aan kunnen wijzigen van requirements gedurende het traject, wat voor een dergelijk langlopend traject ook erg belangrijk is.

2. Specificaties: mini-waterval in combinatie met Scrum

Een apart Analyseteam is opgezet om specificaties te maken, op de hiervoor beschreven wijze, van grof naar fijn. Dit gebeurt zoveel mogelijk aan de hand van de Scrum methodiek, met een eigen backlog en Stories. De Stories resulteren in concrete deliverables: documenten en nieuwe Stories. Belangrijke documenten zijn een lijst Epics per release en per Epic een high-level requirements document. Uit het high-level requirements document volgen detail analyse Stories voor het Analyseteam, die leiden tot detail specificaties en gekoppeld daaraan Stories voor het Bouwteam. Hierbij worden de Stories voor het Analyseteam zo ingestoken dat per sprint een bruikbaar (deel)resultaat wordt opgeleverd, voor een verdieping in de volgende sprint van het Analyseteam, of voor realisatie in de volgende sprint van het Bouwteam.
De sprints van het Analyseteam en het Ontwikkelteam zijn ten opzichte van elkaar verschoven, waarbij de demo van het Analyseteam de Grooming van het Bouwteam vormt en de demo van het Bouwteam de terugkoppeling is naar het Analyseteam.

3. De rol van de Product Owner

Omdat een echte Product Owner ontbreekt wordt de totale scope van een release en de volgorde van de realisatie bepaald in een wekelijks overleg dat deze rol daarmee feitelijk invulling geeft. Dit overleg bestaat uit de Domein Architect (functioneel eindverantwoordelijk), de Technisch Architect (technisch eindverantwoordelijk), de Scrummaster van het Analyseteam (waar het geheel samenkomt), en de projectmanager (verantwoordelijk voor planning en budget). Op basis van punten als release doelstellingen, afhankelijkheden met de buitenwereld, functionele en/of technische samenhang en efficiency worden uitgangspunten voor prioriteitstelling en de primaire volgorde van de Epics bepaald. Vervolgens wordt iteratief de backlog op Story niveau in prioriteit gerangschikt en ruwweg in sprints ingedeeld, rekening houdend met de laatste zichten en de Velocity van beide teams.

4. Beperken refactoring

Producten van het Analyse team zijn ook het Functioneel en Technisch Ontwerp. Deze worden eerst globaal en later in detail uitgewerkt, in onderlinge samenhang en daarna in stukjes die binnen één sprint passen. De samenhang tussen FO, TO en Epics wordt ook uitgewerkt. De detailuitwerking gebeurt in de sprint voorafgaand aan de sprint waarin bijbehorend Epic voor het eerst wordt opgepakt. De afstemming op detailniveau tussen het Analyseteam en het Bouwteam blijft intensief, ook als de analyse is afgerond en de bouw is begonnen. Hier wordt rekening mee gehouden in de sprintplanning van het Analyseteam.

5. Documentatie

Documentatie wordt opgesteld in twee aparte stromen: als input voor Bouw en als input voor Acceptatie en Inbeheername. Daarbij wordt een gemeenschappelijk raamwerk gebruikt van Use Cases, waaraan Epics zijn gekoppeld, evenals de bijbehorende FOs en TOs. Door de reguliere voortbrenging wordt de input voor het Bouwteam gerealiseerd, waarna in een tweede slag na de realisatie de uitwerking voor Acceptatie en Inbeheername volgt, ook weer als Stories op de backlog van het Analyseteam (en soms ook van het Bouwteam).

Resultaat

Het resultaat van bovenstaande aanpak is een combinatie tussen het traditionele watervalmodel en de Scrummethodiek: waterval van Analyse naar Bouw, maar iteratief (kortcyclisch) en binnen elk team wel volgens de Scrummethodiek. Dit heeft geleid tot een meer solide lange termijn planning met daarbinnen ruimte voor het wijzigen van requirements. Daarnaast is de hoeveelheid refactoring flink afgenomen en wordt documentatie efficiënt en voldoende voor zowel Bouw als Acceptatie opgeleverd.

Meer weten? Neem contact op met ons voor een verkennend gesprek!

Blogdetails

05-06-2015
Artikelen

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 088 266 28 70 Stuur ons een bericht