Haarlemmerolie in de scrumpolder

Agile Business-informatie analyse

Scrumteams bestaan uit een productowner, scrummaster en een development team.  Een developer voert meerdere taken uit voor het team zoals analyse, design, development en testen. De business analist (Engelstalige benaming) of informatie analist (Nederlandstalige benaming) is formeel geen onderdeel van het agile team. In grote organisaties met complexe software ontwikkeling is dit niet werkbaar. Vaak zijn er meerdere teams aan het werk aan meerdere systemen met afhankelijkheden en integraties tussen de systemen. Dan heb je iemand nodig die over de grenzen van het team heen kan kijken afhankelijkheden in kaart kan brengen en ook voor de start al het nodige voorwerk kan verrichten. Er is immers geen directie of investeerder die een blanco cheque afgeeft en oneindige tijd beschikbaar stelt. Afhankelijk van de complexiteit van de organisatie en software ontwikkeling kan de businessinformatie analist dedicated voor een team werken of voor meerdere teams. De business-informatie analist staat met één been in de business en met het andere been in de IT. Naast veelvuldige interactie met de teams is samenwerking met het management, de business, maar ook bijvoorbeeld de solution architect  essentieel. Het verkrijgen van de juiste requirements is één van de meest kritische onderdelen van software ontwikkeling. De business-informatie analist is de specialist in het verkrijgen van de juiste requirements. Aangevuld met de agile/incrementele software ontwikkeling is dat de beste garantie voor het maken van de juist software.

Indien er sprake is van innovatie, dus echt eigen bouw van nog niet bestaande of vergelijkbare software, dan werkt deze aanpak niet. Kies dan voor een pure incrementele aanpak. In een groot deel van de organisaties is dit niet het geval. Daar is software ontwikkeling niet de core business. In bestaande organisaties zijn er veranderingen in strategie, wetgeving of nieuwe technologische mogelijkheden die de bron vormen voor initiatieven voor software aanpassingen of vernieuwingen. Dus ondanks dat men kiest voor een agile werkwijze zal er voorafgaand aan de sprints werk moeten worden verricht. Denk aan een haalbaarheidsonderzoek, procesanalyse, make or buy afwegingen, pakket- en leveranciersselectie, globale plannen. Indien er wordt samengewerkt met externe leveranciers is een voortraject onmisbaar voor het maken van afspraken. De business-informatieanalist kan deze opties uitwerken en businesscases maken zodat de juiste onderbouwde keuze kan worden gemaakt. Dit indien mogelijk in samenwerking met de productowners en architecten uit de organisatie. De productowner zal een visie hebben met betrekking tot zijn of haar product en de architect heeft een goed beeld van de technologische roadmap.  Samen kan er dan een goede inschatting worden gemaakt van de globale kosten en doorlooptijd. Zo zit het agile team niet in een heel wendbaar stuurloos bootje, maar is er een duidelijke bestemming.

In het incrementele proces zit afstemming met de business ingebakken. Het team kan afstemmen met belanghebbenden uit de business en in de sprintreview kan feedback worden opgehaald. Hier schuilt het gevaar dat het agile team heel wendbaar een speelbal wordt van de business en maakt wat de business wil. De productowner zal dus sterk in zijn of haar schoenen moeten staan. Het helpt indien er bij de start al een bepaalde richting bestaat. Belanghebbende hebben nogal de neiging om vooral naar hun eigen belang te kijken en vaak zie je ook dat men de huidige situatie wil doorvoeren middels de nieuwe technologie. Je krijgt dan oude wijn in nieuwe zakken. De organisatie als geheel is gebaat bij verandering om beter te kunnen inspelen op de marktontwikkelingen. Het is niet zwart-wit en ik wil er niet voor pleiten om de stakeholders links te laten liggen. Het is juist waardevol om met vertegenwoordigers met de in- of externe gebruikers (klanten bij online toepassingen) van gedachte te wisselen over het gebruik van de software. Het moet natuurlijk wel aansluiten bij hun behoeften en werkprocessen. Het is echter lastig voor gebruikers om de nieuwe mogelijkheden goed te kunnen inschatten en hun wensen te vertalen naar concrete functionaliteit. Het iteratieve karakter van scrum kan daar bij helpen en ook de business informatie analist heeft hier een belangrijke rol te vervullen. Soms is het zelfs nodig om processen aan te passen omdat de markt daarom vraagt.

De business-informatieanalist moet enige snelheid in het voortraject inbouwen. Dat was immers het grote nadeel aan waterval projecten. De tijd tussen analyse en gereed product nam dermate veel tijd in beslag dat door de marktontwikkelingen het resultaat al weer achterhaald was. In feite is dit een hybride vorm. De globale requirements uit het voortraject moeten worden omgezet in userstories met heldere acceptatiecriteria. Userstories worden geprioriteerd op basis van relatieve waarde voor de business. De business informatie analist maakt een vertaalslag van de strategische keuze en requirements naar de feitelijke aanpassingen in de applicaties. Hij of zij onderbouwt dit met use cases, activity diagrams en datamodellen. Het gaat daarbij vooral om de informatiestromen. Vaak is ook architectuur betrokken voor de infra- en systeemarchitectuur. Het is belangrijk om die eerder genoemde waarde mee te nemen bij de requirementsanalyse omdat vaak wordt uitgegaan van een MoSCoW prioritering en dit niet gebruikelijk is binnen de agile werkwijze. Userstories gaan uit van storypoints en zijn vaak kleiner qua omvang dan een requirement. Dat betekent dat een requirement moet worden vertaald naar een Epic met meerdere userstories. De business-informatie analist kan het agile team helpen om die vertaalslag te maken en deze userstories verder te verduidelijken of liever gezegd te refinen. De productowner is vaak een vertegenwoordiger van de business en het verschil met het IT gedreven development team kan groot zijn. De business informatie-analist kan in het team deze twee werelden bij elkaar brengen. Het ontwikkelteam heeft vaak helemaal geen tijd voor requirements analyse en is juist goed in development. Het is wel raadzaam om het developmentteam te betrekken bij de afstemming met de business. Het maakt het werk voor het developmentteam leuker indien ze zelf kunnen horen wat de business drijft. Daarnaast kan de business informatie analist helpen bij de afstemming tussen de teams en de productowner ondersteunen bij het backlogmanagement. De scrummaster is de agile coach en facilitator van het team. Dat is een belangrijke rol, maar geen inhoudelijke rol. De business informatie analist is meer inhoudelijk betrokken bij het team. Daardoor kan deze wat gemakkelijker verdiepende sessies organiseren om in te zomen op een specifiek onderwerp. Daar waar de scrummaster bij impediments meer de hierarchie zal ingaan zal de business-informatie analist meer de diepte ingaan om het issue af te pellen om de oorzaak te achterhalen. Samenwerking is natuurlijk te preferen. Het agile proces verloopt net wat gemakkelijker met een business-informatie analist en kan daar bijspringen waar nodig.

Ook de agile werkwijze wordt ondersteund met software. Zo zijn er diverse softwarepakketten zoals Jira van Atlassian, maar ook Microsoft heeft kwalitatieve software voor agile werken. Het voordeel van Jira is dat het naadloos samenwerkt met Confluence waar je documentatie kan koppelen aan de de userstories. Je kan dan bijvoorbeeld vanuit de userstories verwijzen naar requirements op confluence. Bij grote organisaties werken vaak meerdere teams aan software producten. In Jira kan gemakkelijk een hierarchie van Inititiative – EPIC – userstorie worden gevolgd. Het initiatief kan dus in Jira worden opgenomen inclusief alle documentatie en businesscase. Daarnaast kun je EPICS koppelen aan het initiative zodat je kunt zien welke teams aan welk onderdeel werkt. De naamgeving is flexibel. Dus wil jij het initiative een feature noemen dan kan dat ook. Het is maar net wat de organisatie intern heeft afgesproken qua benamingen. Epics en userstories zijn vaak wel algemene termen die voor alle organisaties gelijk zijn. De userstories kunnen weer onderverdeeld zijn in tasks (taken) zodat inzichtelijk is wie wat doet om de userstory afgerond te krijgen. De busines-informatiesanalist heeft dus vaak de taak analyse binnen een userstory of epic. De business-informatie analist moet deze software tot in de finesse beheersen en ook zorgen dat er enige vorm van documentatie beschikbaar is, al is dat ook een teamverantwoordelijkheid.    

Blijf werken aan iteraties met feedback van gebruikers om wendbaar te blijven

Na de voorfase blijft de businessanalist een aantal sprints vooruit lopen om alvast de backlog te refinen op basis van requirements uit de business. Een vastgesteld programma van eisen maakt het team minder wendbaar en dus minder agile. Binnen de agile werkwijze wordt veel mondeling gecommuniceerd en weinig gedocumenteerd. Dat is in grote complexe organisaties niet haalbaar. Het is dan niet meer duidelijk wat waarom op een bepaalde wijze is ontwikkeld. Dat maakt de doorontwikkeling een stuk lastiger. Het team zal in enige mate volgens plan van de organisatie moeten werken anders is er het risico dat het team afdrijft van de rest van de organisatie. Je kunt het vergelijken met een groep schepen die in formatie varen. Indien één bootje een andere koers vaart dan zal die niet dezelfde bestemming  halen of de anderen vertragen. Voor veel bedrijven is software niet de core business. Anders dan commerciële software producten waar de visie rechtstreeks te maken heeft met de visie op de markt voor de software, is de software ondersteunend aan het primaire proces van de onderneming. Die visie heeft dus betrekking op de inzet van de software voor de onderneming. Daarnaast is er product roadmap. Dat is het strategisch plan dat laat zien hoe het product zich de komende tijd globaal zal ontwikkelen. De business informatie analist kan het team helpen op koers te blijven met de organisatiestrategie en in lijn te blijven met de andere teams. Dit is natuurlijk ook een taak van de productowner, maar samen staan ze sterker.

In een agile omgeving worden requirements tot uitdrukking gebracht door middel van userstories. Indien userstories al van te voren globaal uitgewerkt zijn door de business informatie analist dan is er al een goed gevulde backlog opgebouwd en voldoende werkvoorraad voor de developers. Hierbij moet wel goed opgelet worden dat de userstories niet als requirements worden gebruikt. Het incrementele systeem is er op gericht om in een sprint door middel van refinement en review te komen tot de juiste software. Het is belangrijk om ook tijdens de sprint te zorgen dat stakeholders via de sprintreview feedback kunnen geven omdat ze dan een beter beeld van het product krijgen en ook beter in staat zijn om de juiste feedback te geven. Het gevaar is dat in een hybride omgeving de stakeholders niet meer naar de reviews komen omdat ze in het voortraject al hun wensen en eisen kenbaar hebben gemaakt. De business-informatie analist zal de stakeholders ervan moeten overtuigen dat de betrokkenheid tijdens het gehele agile proces van belang is. Tijdens de sprint helpt de business informatie analist met het scherpstellen van de requirements en het afstemmen met de stakeholders. De feedback kan weer resulteren in nieuwe userstories