Het agile verandertraject

Het startpunt van een agile verandertraject begint bij het vertalen van de strategische thema’s van de organisatie naar de roadmap. Op de roadmap staan de epics die invulling geven aan de ambitie. Op teamniveau zien wij dat ieder agile traject, na definitie van een epic, een aantal hoofdfasen doorloopt. Aan de hand van het standaard agile (scrum) framework wordt dit inzichtelijk gemaakt , zie figuur 2.

De hoofdfasen zijn:
1. De voorbereidingsfase: bepalen impact op de business- en IT architectuur voor de complete epic c.q. het hele verandertraject (alleen van toepassing bij grotere veranderingen)
2. De pre-sprint fase: definiëren van het minimum viable product (MVP)
3. De ontwikkelsprints: realiseren van de functionaliteit(en) in 1 of meerdere sprints
4. De implementatiefase: releasen van software inclusief de activiteiten rondom organisatieverandering.

In iedere fase kunnen specifieke modellen voor business analyse worden gebruikt om helderheid over de verandering te verschaffen. Natuurlijk bekijk je per keer wat er nodig is. Ieder verandertraject is uniek en daardoor doorloop je een fase de ene keer intensiever dan de andere keer. Dit lichten wij toe aan de hand van het fictieve bedrijf Novischade & Herstel.

Het agile verandertraject van Novischade & Herstel

De voorbereidingsfase
Novischade & Herstel heeft een hoge veranderambitie. Om die te bereiken wordt een roadmap gemaakt met vele epics die door een portfolioboard wordt aangestuurd. Voor iedere epic wordt een business owner benoemd. In opdracht van de business owner werkt de business analist de epic omschrijving uit. Dit is een soort mini business case of rechtvaardiging van het verandertraject, waar de business owner zijn visie beschrijft. Zie in figuur 3 de elementen van een epic omschrijving.

 

Per kwartaal doet de product owner een update van de epic omschrijving en budgetaanvraag. De business analist assisteert bij het opstellen en onderhouden van de epic omschrijving.

⇒ TIP: Maak samen met een architect in sprint 0 een product-, proces- en systeemarchitectuur. Dit zorgt ervoor dat je afhankelijkheden met andere producten, processen en systemen (applicatiecomponenten, system software en devices) tijdig in het vizier hebt en een beter gedeeld beeld van de scope van de verandering hebt. Tevens baken je hierdoor het initiatief af en kun je in het verloop van het traject de afhankelijkheden tussen initiatieven beter managen. De architect identificeert producten, processen, systemen en data objecten. De business analist specificeert deze, meestal op een later moment in de pre-sprint fase.

De pré-sprint fase
Het doel van de pre-sprint fase is het definiëren van de MVP. Hiervoor is het noodzakelijk om inzicht te krijgen in het primaire proces. Samen met business owners en materiedeskundigen is een workshop gehouden waarin aan de hand van het ketenproces de eerste behoefte aan systeemondersteuning is geïnventariseerd. Op basis van deze inventarisatie zijn de eerste user stories gedefinieerd en de MVP bepaald.

Belangrijk om te weten is dat een gedetailleerde uitwerking van het werkproces nodig is om ook daadwerkelijk te kunnen bepalen wat de gevraagde behoefte is. Deze uitwerking volgt in de ontwikkelsprints.

⇒ TIP: Aan de hand van architectuurmodellen kan de business analist inzichtelijk maken welke producten, kanalen, ketenpartijen, processen en systemen in scope zijn. Dit helpt de contouren van de verandering en de discussie hierover scherp te stellen en geeft een eerste beeld voor impactbepaling. Door al vanaf de voorbereidingsfase met de architect samen te werken wordt de toegevoegde waarde hier zichtbaar.
⇒ TIP: Gebruik genoemde architectuurmodellen in de communicatie met de stakeholders. Hiermee creëer je een eenduidige taal over de situatie.

  
⇒ TIP: Aan de hand van een motivatiemodel kan je als business analist scherp analyseren en visualiseren wat de relatie is tussen de strategie en epics. Zie in figuur 4 hieronder een voorbeeld van toepassing van het motivatiemodel, met 1 KSF als uitgangspunt. In het motivatiemodel wordt de strategie expliciet gemaakt door doelen en drijfveren van de stakeholders te formuleren. Daarnaast geeft het model inzicht in de beoogde bijdrage van een epic aan één of meerdere doelen. Door de relatie tussen strategie en epic expliciet te hebben gemaakt kan de business analist scherp krijgen welke epics er uit de gewijzigde strategie voortvloeien.
 

 

Ontwikkelsprints
De ontwikkelsprints richten zich op het ontwerpen en realiseren van informatiesystemen en het ontwerpen van proces- en organisatiewijzigingen. De product-, service- en proces ontwerpen, die binnen de kaders van architectuur zijn gemaakt, zijn hiervoor steeds het vertrekpunt.

Het ontwerpen en analyseren van de processen loopt twee, soms drie sprints voor op de realisatie sprint. Dit geeft ons voldoende tijd om een goed doordacht ontwerp te maken dat inzicht geeft in de nieuwe manier van werken. Vervolgens kan de functionaliteit geïdentificeerd worden die daarvoor nodig is.

Het ontwerp bestaat uit een procesontwerp en daaraan gekoppeld de user stories. Per processtap bepalen we met de stakeholders welke user stories er nodig zijn (voor het MVP en voor de doorontwikkeling). Indien nodig voegen we per handeling een enkele user story toe. Door user stories op deze manier op te stellen, hebben deze een vergelijkbare diepgang (ook wel granulariteit genoemd) en zijn we in staat een betere sprint- en releaseplanning af te geven.

Per user story werkt de business analist samen met materiedeskundigen en ontwikkelaars een activity diagram uit waardoor de interactie tussen gebruiker en systeem zichtbaar wordt. Van daaruit verwijs je naar verplichte en optionele gegevens die in die handelingen opgevraagd, verwerkt of worden uitgestuurd. Zie de relatie tussen procesmodel en het activity diagram met verplichte en optionele gegevens in figuur 5.

 

⇒ TIP: Ons vertrekpunt voor de proces- en informatieanalyse is altijd een procesontwerp. Het ontwerp bestaat uit een procesmodel met een toelichting. De analyse levert een helder geformuleerde user story op, waarvan zowel de inhoud als toegevoegde waarde eenvoudig te begrijpen valt doordat deze is gekoppeld aan de juiste stap in het proces. Het helpt om het procesmodel en de gerelateerde user stories in een Word document op te nemen. Dit kan als communicatiemiddel richting business owners en materiedeskundigen worden gebruikt, tot een 0.9 versie. De user stories hebben een vast format voor uitwerking. Deze opzet vergemakkelijkt de review van de stories door stakeholders. Daarna worden de user stories in één keer overgezet naar JIRA waar ze voorzien worden van labels en onderverdeeld naar epics.
De business analist analyseert, ontwerpt, stelt requirements op en communiceert hierover met de stakeholders.

Er zijn vier type schadeprocessen die gedeeltelijk gebruik maken van dezelfde generieke functionaliteiten. Daarnaast groeit het aantal user stories met de tijd. Om overzicht te behouden is per type schadeproces een overzicht gemaakt met generieke en specifieke functionaliteiten. Aangezien de veelheid aan user stories een dergelijk overzicht juist onoverzichtelijk zou maken, zijn de user stories geaggregeerd weergegeven. Per type schadeproces zijn opeenvolgend alleen de nieuwe user stories toegevoegd.

 

Door met kleur te werken is het MVP overzichtelijk aangegeven, zie figuur 6. We gebruiken de story map als communicatiemiddel naar de business owners en andere stakeholders binnen de organisatie.

 
⇒ TIP: Breng middels architectuurmodellen tijdig in beeld waar raakvlakken zitten met deliverables van andere teams, zodat er afstemming kan plaatsvinden. Product owners kunnen relevante stories selecteren en plannen dat teams hier gezamenlijk aan werken. Zorg ervoor dat de prioriteit goed en gezamenlijk wordt bepaald om te voorkomen dat er te vaak geschoven moet worden in de planning. Hiervoor wordt een gremium ingericht waar alle product owners, architecten en business analisten wekelijks een half uur samenkomen om de afhankelijkheden te monitoren en afspraken voor samenwerking te maken.
  

 

⇒ TIP: Naast de generieke story map maken we twee sprints vooraf een story map op brown paper aan de wand voor het proces in scope. De opzet is hetzelfde als de story map, maar dan gedetailleerder. Het team gebruikt de story map voor de werkverdeling. De product owner gebruikt het als communicatiemiddel richting de stakeholders. De story map is het referentiemodel voor de toekomstige opleveringen.

⇒ TIP: Door de volgende verbeteringen door te voeren is het refinement proces drastisch verbeterd:

  • Bespreek, na de proces- en informatieanalyse, alle user stories binnen de scope van een werkproces met de materiedeskundigen en product owner. De business analist borgt dat alle aspecten aan de orde komen en licht de samenhang tussen de stories toe.
  • Neem, een sprint vooraf, alle stories door en vul deze aan volgens het ‘three amigo’s concept’ (ontwikkelaar, business analist en materiedeskundige, soms ook met een architect of informatie analist voor technische details en koppelingen). Alle teamleden zijn zo tijdig en goed geïnformeerd en betrokken. De business analist zorgt voor voortgang en inhoudelijke begeleiding.
  • Verklein het refinement team, geen ‘Poolse landdag’ van maken. Betrek alleen de ontwikkelaars die daadwerkelijk de software gaan bouwen.

Tot slot willen we meegeven dat de ontwerpen die wij business analisten maken niet altijd door alle stakeholders goed begrepen worden. Daarom maken we wanneer nodig andere visualisaties (gebaseerd op onze modellen) om de betreffende stakeholder te informeren of om feedback te vragen. Denk aan een versimpelde weergave van hoe een case het proces doorloopt. Zeker in een implementatie sprint kan dit goed van pas komen.

Implementatiesprints
In de implementatiesprints worden steeds per werkproces de wijzigingen in de organisatie geïmplementeerd en software in productie genomen. De belangrijkste implementatie activiteiten zijn training en communicatie over de verandering.

Wanneer de user stories voor het minimum viable product gereed zijn, kunnen deze als één geheel geïmplementeerd worden. Hierbij is de grootste uitdaging dat zowel de organisatorische aanpassingen als de ondersteunende software gereed moeten zijn (een minimum viable process).

De ervaring leert dat één werkproces vaak een te beperkte scope is qua implementatie. Bijvoorbeeld het werkproces ‘uitkeren schade’ moet tegelijk geïmplementeerd worden of naadloos aansluiten op het huidige betalingsproces. En het opvoeren van een betrokkene moet mogelijk zijn als het aannemen van een schademelding wordt geïmplementeerd.

Bij Novischade & Herstel zijn gebruikers door de business analist getraind, animaties van het proces en mock ups gemaakt en bleef hij vraagbaak voor na de implementatie. Terwijl de implementatie activiteiten plaatsvinden, is de business analist ook alweer bezig met het sprint ready maken van user stories voor de volgende sprint(s).

⇒ TIP: De story map is een handig instrument om hier grip op te krijgen. Hiermee kunnen stories met potentieel dezelfde functionaliteit geïdentificeerd worden. Deze stories werk je pas, just in time, in detail uit in de sprint voorafgaand aan realisatie. De business analist maakt de story map in overleg met de product owner en werkt op het juiste moment met de juiste stakeholders de user stories uit.

Conclusie

Aan de hand van de fasering voor agile werken laten we zien welke rol de business analist in een agile traject kan spelen. Een belangrijk hulpmiddel voor de business analist is het Novius business-analyse raamwerk. Modellen uit dit raamwerk kunnen in samenhang met elkaar worden ingezet. Hierdoor ontstaat een coherente inrichting van de dienstverlening, het proces en de applicatiefunctionaliteit. We beschrijven welke modellen de business analist bij het Novischade & Herstel inzet en op welke manier de business analist toegevoegde waarde heeft:- Voorbereidingsfase: ondersteuning van de architect en de business owner door het uitwerken van architectuur, uitwerken van de mini business case en het opstellen van formats voor voortgangsrapportages.

  •  Pré-sprint fase: ondersteuning van de product owner bij het initieel vullen van de backlog, het opzetten van de story map en het maken van voortgangrapportages.
  •  Sprintfase: ontwerpen van processen, uitvoeren van informatieanalyse, vastleggen van requirements (user stories in dit voorbeeld), uitwerken van activity diagrams, samenhang tussen de diverse ontwerpen aanbrengen, afstemmen met diverse stakeholders over de inhoud van ontwerpen, geven van toelichting en advies in het refinement traject.
  • Implementatiefase: verzorgen van gebruikerstraining, maken van vereenvoudigde weergave van ontwerpen, oftewel, communicatiemiddelen richting stakeholders en fungeren als vraagbaak na implementatie.

Gedurende het traject zijn een aantal inzichten opgedaan. Deze zijn opgenomen in het artikel, maar voor het gemak lichten we ze er nog eens uit:⇒ TIP: Maak samen met een architect in sprint 0 een product-, proces- en systeemarchitectuur. Dit zorgt ervoor dat je afhankelijkheden met andere producten, processen en systemen tijdig in het vizier hebt en een beter gedeeld beeld van de scope van de verandering hebt.
⇒ TIP: Aan de hand van architectuurmodellen kan de business analist inzichtelijk maken welke producten, kanalen, ketenpartijen, processen en systemen in scope zijn. Dit helpt de contouren van de verandering en de discussie hierover scherp te stellen en geeft een eerste beeld voor impactbepaling. Door al vanaf de voorbereidingsfase met de architect samen te werken wordt de toegevoegde waarde hier zichtbaar.
⇒ TIP: Gebruik architectuurmodellen in de communicatie met de stakeholders. Hiermee creëer je een eenduidige taal over de situatie.
⇒ TIP: Ons vertrekpunt voor de proces- en informatieanalyse is altijd een procesontwerp. Het ontwerp bestaat uit een procesmodel met een toelichting. De analyse levert een helder geformuleerde user story op, waarvan zowel de inhoud als toegevoegde waarde eenvoudig te begrijpen valt doordat deze is gekoppeld aan de juiste stap in het proces. Het helpt om het procesmodel en de gerelateerde user stories in een Word document op te nemen. De business analist analyseert, ontwerpt, stelt requirements op en communiceert hierover met de stakeholders.
⇒ TIP: Breng middels architectuurmodellen tijdig in beeld waar raakvlakken zitten met deliverables van andere teams, zodat er afstemming kan plaatsvinden. Product owners kunnen relevante stories selecteren en plannen dat teams hier gezamenlijk aan werken. Zorg ervoor dat de prioriteit goed en gezamenlijk wordt bepaald om te voorkomen dat er te vaak geschoven moet worden in de planning.
⇒ TIP: Naast de generieke story map maken we twee sprints vooraf een story map op brown paper aan de wand voor het proces in scope. De opzet is hetzelfde als de story map, maar dan gedetailleerder. Het team gebruikt de story map voor de werkverdeling. De product owner gebruikt het als communicatiemiddel richting de stakeholders.
⇒ TIP: Door de volgende verbeteringen door te voeren hebben we het refinement proces drastisch verbeterd:

  • Bespreek, na de proces- en informatieanalyse, alle user stories binnen de scope van een werkproces met de materiedeskundigen en product owner. De business analist borgt dat alle aspecten aan de orde komen en licht de samenhang tussen de stories toe.
  • Neem, een sprint vooraf, alle stories door en vul deze aan volgens het ‘three amigo’s concept’ (ontwikkelaar, business analist en materiedeskundige, soms ook met een architect of informatie analist voor technische details en koppelingen). Alle teamleden zijn zo tijdig en goed geïnformeerd en betrokken. De business analist zorgt voor voortgang en inhoudelijke begeleiding.
  • Verklein het refinement team, geen ‘Poolse landdag’ van maken. Betrek alleen de ontwikkelaars die daadwerkelijk de software gaan bouwen.

⇒ TIP: De story map is een handig instrument om hier grip op te krijgen. Hiermee kunnen stories met potentieel dezelfde functionaliteit geïdentificeerd worden. Deze stories werk je pas, just in time, in detail uit in de sprint voorafgaand aan realisatie. De business analist maakt de story map in overleg met de product owner en werkt op het juiste moment met de juiste stakeholders de user stories uit.

Gezien bovenstaande durven wij te beweren dat ondanks dat business analyse geen formele rol is in Scrum, Safe of andere agile methodieken, de business analist van grote toegevoegde waarde is in een agile verandertraject!

 


Paulien Jans is senior business consultant bij Adviesgroep Novius. Zij heeft ervaring met veranderingen op tactisch-operationeel niveau in de rol van projectleider, business analist, requirements engineer of procesontwerper. Zowel in waterval- als agile verandertrajecten.

Meer te weten komen over business analyse? Neem hiervoor contact op met Adviesgroep Novius via 0343 – 760076, of Office@novius.nl

Lees meer over het Novius business-analyse raamwerk in de whitepaper ‘Agile bedrijfsontwerp’ https://novius.nl/whitepapers/ of download onze Stijlgids via https://novius.nl/procesontwerp/


[3] Zie voor een uitgebreide toelichting het artikel ‘Agile bedrijfsontwerp – vakmanschap in een agile setting

Menu