T-shaped Analisten: de toegevoegde waarde van business analyse in een Agile team

In mijn vorige blog zagen we dat agile system development een groot scala aan best practices kent. Die best practices zijn vaak afkomstig uit populaire agile frameworks waaronder Scrum, LeSS, SAFe en DAD. Opvallend is dat in geen van de frameworks een aparte business analyse rol wordt onderkend. In deze blog ga ik dan ook op zoek naar het antwoord op de volgende vraag:Wat is de toegevoegde waarde van business analyse in een agile team en welke rollen kan een (business) analist daarin vervullen?

Om het wat te vereenvoudigen knip ik de vraag op in twee delen:

Welke rollen kan iemand met de functie ‘business analist’ ( ‘informatie analist’ of ‘requirements analist’) spelen in een agile team?
Welke rollen in een agile team voeren business analyse activiteiten uit?

Ik zal eerst een antwoord geven op de eerste vraag en zal vervolgens vraag 2 beantwoorden.

Vraag 1: Welke rollen kan iemand met de functie (business) analist spelen in een agile team?

De grondleggers van het DAD-framework Scott Ambler en Mark Lines hebben in hun boek ‘Disciplined Agile Delivery’ een prachtig plaatje opgenomen waarin traditionele rollen/functies worden geplot op de agile rollen van DAD (zie onderstaande figuur).

Bron: Disciplined Agile Delivery

Volgens dit plaatje kan een business analist de volgende rollen vervullen:

Optie 1: Product owner (dikste lijn, dus het meest waarschijnlijk)

Optie 2: Team member

Optie 3: Team lead (het equivalent van de Scrum master)

Ik ben het hier voor een groot deel mee eens, maar zou er nog een extra optie aan toe willen voegen:

Optie 4: De BA als Subject Matter Expert (SME)

Hieronder worden de opties een voor een verder uitgewerkt:

Optie 1: De BA als product owner

De meest voor de hand liggende rol die een BA in een agile team kan vervullen is die van de Product Owner. De Product Owner (PO) is immers de persoon die alle product requirements eliciteert bij de diverse stakeholders, ze vervolgens beschrijft en op de Product backlog (of Work Items List) zet. Daarna prioriteert de PO de requirements en bespreekt ze met alle Teamleden. De (business) analist is van oudsher degene die deze activiteiten uitvoert. Hoewel de rol van Product Owner en business analist veel overeenkomsten vertonen, is het in de praktijk vaak zo dat de analist niet de PO-rol vervult. Ik zal de belangrijkste oorzaken hiervoor noemen. Ten eerste is de BA over het algemeen geen eigenaar van het product en heeft derhalve geen mandaat voor het nemen van belangrijke beslissingen die betrekking hebben op het nieuwe product. Een andere oorzaak is dat de BA-rol vaak is ondergebracht bij ICT (bijvoorbeeld als informatie analist of requirements analist), terwijl de PO een afgevaardigde is van de business.

Hoewel PO’s afkomstig uit de business hun organisatie meestal heel goed kennen (meestal als Product manager), ontbreekt het vaak aan een gedegen IT-development achtergrond. Vaak zijn deze mensen niet gewend om zelfstandig requirements te eliciteren bij alle stakeholders om ze vervolgens gedetailleerd uit te werken. Daarvoor is echt een specialist nodig die gewend is met verschillende partijen te praten. Partijen die niet zelden verschillende belangen en achtergronden hebben en die allemaal op één lijn gebracht moeten worden met betrekking tot de gekozen oplossing. Die specialist is de (business) analist. In toekomstige blogs zal ik regelmatig terugkomen op de rol van de BA versus de PO.

Optie 2: De BA als Team member

Vanwege het ontbreken van mandaat zoals aangegeven in de vorige optie, worden veel analisten niet ingedeeld als product owner maar als team member. De teammember rol concentreert zich op het bouwen plus opleveren van het software product. Teamleden worden soms aangeduid als programmeurs. Deze 'rolvervaging' treedt op omdat ontwikkelaars in agile teams naast programmeertaken ook vaak activiteiten uitvoeren die tot andere disciplines behoren zoals testen, databaseontwerp, UX design, integratie, etc. De grondleggers van DAD hebben het over zogenaamde ‘generalizing specialists’, daarmee bedoelen ze dat iedereen weliswaar een eigen specialisme heeft, maar daarnaast ook andere taken uitvoert. Bij de beantwoording op vraag 2 zal ik hierop terugkomen.

Optie 3: De BA als Scrum Master

De Scrum master (of Team Lead in DAD) is ervoor verantwoordelijk dat Scrum/DAD wordt begrepen en goed wordt uitgevoerd. Scrum Masters doen dit door ervoor te zorgen dat het Scrum Team zich houdt aan de Scrum theorie, praktijk en regels. Tijdens de Sprint Retrospectives waarin per Sprint wordt teruggekeken op de kwaliteit van het proces van systeemontwikkeling, speelt de Scrum Master (SM) een belangrijke rol in het faciliteren van de sessies, die als doel hebben het in de volgende sprint een stapje beter te doen.

Craig Larman, een van de grondleggers van LeSS (Large Scale Scrum), stelt op zijn website (https://less.works) dat de Scrum master rol vaak verkeerd wordt geïnterpreteerd en daardoor slecht wordt uitgeoefend. Volgens Larman besteden veel Scrum masters te veel tijd aan hun team, zelfs als dit niet meer nodig is.

Hij onderscheidt 4 focus areas:

Teamfocus
Product owner-focus
Organization-focus
Development practices-focus

Bron:https://less.works/less/structure/scrummaster.html

1. Teamfocus

Initieel zal een SM relatief veel tijd en energie moeten steken in het ‘op de rails’ krijgen van het ontwikkelteam. Maar naarmate de sprints voorbijgaan, raakt het team meer en meer op elkaar ingespeeld en is hiervoor minder inspanning nodig van de SM. Het team is inmiddels in staat tot zelfsturing en neemt zelf beslissingen. De grafiek toont aanvankelijk dus een hoge focus en daalt later aanzienlijk.

2. Product Owner-focus

Dezelfde curve gaat op voor de PO-focus. Tegelijk met de team-focus is de SM druk met het ‘coachen’ van de PO. Zoals ik hierboven al aangaf, zie ik in de praktijk regelmatig mensen opereren als PO die dit voor het eerst zijn en begeleid dienen te worden in deze rol. Aangezien de BA van huis uit gewend is om requirements te eliciteren en in kaart te brengen, kan hij de PO hierin prima begeleiden als SM. Ook indien een persoon niet de juiste PO blijkt te zijn, kan de SM ondersteunen bij het vinden van een geschikte vervanger.

3. Organisatie-focus

De curve die hierbij hoort verschilt met de vorige twee: aanvankelijk is er veel inspanning nodig van een SM om een organisatie mee te krijgen m.b.t. agile projecten, maar daalt naarmate het meer en meer ingebed raakt in de organisatie. Tot slot is er weer meer organisatorische aandacht nodig op het moment dat ‘development practices’ organisatiebreed toegepast dienen te worden met als doel de organisatie te verbeteren op het gebied van systeemontwikkeling. Uiteindelijk kan wellicht de stap naar een agile enterprise worden gezet. Er wordt in dat geval in de gehele organisatie op een agile manier gewerkt. Voor de meeste organisaties is dit echter nog een paar bruggen te ver.

4. Development practices-focus

In het eerste stadium wordt aan ‘development practices’ nagenoeg geen aandacht besteed en worden dingen ‘volgens het boekje’ gedaan (zie de Shu-fase in de blog ShuHaRi). De SM begeleidt de PO en het ontwikkelteam en dat is voldoende. In dit stadium is Scrum-kennis voldoende om een team te begeleiden. Maar als alles op rolletjes loopt - de organisatie bevindt zich inmiddels in het Ha-stadium - zal de focus meer komen te liggen op continue verbetering (van de gehele organisatie) door middel van ‘mining’ en toepassing van talloze (best) practices. Het is aan de organisatie zelf om te kijken welke practices er wel en welke er niet werken (in een bepaalde situatie). Zie ook mijn vorige blog.

Vanwege het feit dat ze sterk gericht zijn op verbeteringen en vaak een bredere focus hebben op een organisatie dan alleen het ontwikkelteam waarvan ze deel uit maken, zijn BA’s over het algemeen erg goed in staat als SM te fungeren. Op alle genoemde focus areas.

Regelmatig zie ik ook dat de SM-rol wordt gecombineerd met de Team Member (TM)-rol. Dit kan een prima combi-rol zijn zolang de BA-werkzaamheden als TM maar niet in de weg staan van de SM-activiteiten of andersom.

Optie 4: De BA als Subject matter expert

Last but not least: veel BA’s maken geen deel uit van de primaire, maar van de secundaire stakeholdergroep (zie eerder genoemde DAD). Ze zijn niet op dagelijkse basis betrokken in het systeemontwikkelproject, maar zijn meer een vraagbaak in geval van complexe vraagstukken. Met andere woorden: ze stellen niet de vragen (aan stakeholders), maar geven antwoorden vanuit hun expertise (als specialist dan wel domein expert).

Vraag 2: Welke rollen in een agile team voeren business analyse activiteiten uit?

Voordat ik antwoord geef op deze vraag zal ik eerst het begrip T-shaped professional beschrijven.

De T-shaped professional

De T-shaped professional is een ‘generalizing specialist’, een persoon die enerzijds een specialisme heeft, bijvoorbeeld testen. Met betrekking tot dit vakgebied weet de professional ‘alles’ en heeft hij/zij de ambitie om zich voortdurend verder te ontwikkelen. Echter, vanuit het agile team worden extra eisen gesteld die ervoor zorgen dat de specialist ook meehelpt met andere disciplines van het team, bijvoorbeeld analyse of programmeren. Naast de diepgaande kennis en kunde bouwt de specialist dus ook brede kennis en ervaring op van andere disciplines. Zo ontstaat de T-vorm.


T-shape voor een business analist	T-shape voor een tester

Het antwoord op vraag 2 kan dus luiden: iedereen! Maar dan wel met een flinke kanttekening. Een team van ‘generalizing specialists’ bestaat uit allemaal T-shaped professionals waarbij sprake is van overlap van disciplines. Met andere woorden: de programmeur analyseert en de analist programmeert. ‘Werkt dit?’ zul je jezelf nu misschien afvragen. Het antwoord hangt natuurlijk af van de situatie. In de ene organisatie zal dit makkelijker zijn dan in de andere organisatie en het kan zelfs van project tot project verschillen. Ik denk dat het eenvoudiger zal zijn in relatief nieuwe organisaties waar iedereen ‘gewoon’ ontwikkelaar is. Maar in grote organisatie die reeds lange tijd bestaan is er meestal een functiehuis waarin sprake is van een sterke specialisatie van rollen.

Daarnaast speelt ambitie een cruciale rol. In veel gevallen wil een programmeur helemaal geen analyses of tests doen en/of heeft daar geen tijd voor en een tester kan of wil helemaal niet programmeren, maar op zoek gaan naar fouten. Dat vinden ze gewoon leuk: foutjes vinden. En hiermee kom ik op een punt waarom ik denk dat de stap naar ‘generalizing specialists’ vaak een hele lastige zal zijn. Je moet doen wat je leuk vindt en/of waar je ambities liggen. Natuurlijk kan dat een combi zijn van diverse disciplines, maar ik merk in de praktijk dat de meeste mensen gewoon hun ding willen doen en dit werkt prima in de meeste gevallen.

Wat voor programmeren geldt, geldt in mijn ogen ook voor (business) analyse: hoewel de meeste mensen best in staat zullen zijn tot het doen van betrekkelijk eenvoudige analyses, is het toch een apart specialisme; je moet een mindset hebben én het leuk vinden om op continue basis organisaties (of onderdeel daarvan) te verbeteren. En dat heeft niet iedereen.

Samenvatting

In deze blog hebben we gezien dat een analist de volgende agile rollen op zich kan nemen:

Scrum Master (of DAD Team Lead)
Product owner
Team member
Subject Matter Expert

Een analist als SM/TL is een goed idee omdat hij/zij gewend is een procesbril op te zetten en om veel energie te steken in het verbeteren van organisaties. Eerst concentreert hij/zij zich op het team en de PO, later op andere delen van de organisaties plus ‘development practices’.

Ook een analist als PO is een goed idee omdat hij/zij gewend is om met stakeholders te praten om hun behoeften in kaart te brengen. Ook is hij gewend om de stakeholders op 1 lijn te krijgen. Maar het is het gebrek aan mandaat dat ervoor zorgt dat analisten meestal niet de rol van PO krijgen. Vaker treden zij op als teamlid die de PO helpt met het opstellen van de juiste requirements en het gedetailleerd en tijdig uitwerken ervan. Op dit onderwerp zal ik in toekomstige blogs regelmatig terugkomen.

In de verreweg de meeste gevallen is de BA een team member die al dan niet in de combirol Scrum Master-Team Member de PO helpt met het uitwerken van requirements die de basis vormt voor de ontwikkelaars en de testers uit het agile development team.

Maar het is niet alleen de (business) analist die business analyse werkzaamheden uitvoert in een agile team. Steeds vaker is er sprake van zogenaamde T-shaped professionals die naast hun eigen discipline, bijvoorbeeld testen, ook andersoortige activiteiten uitvoeren waaronder business analysetaken. En andersom zal de agile business analist geregeld andere werkzaamheden uitvoeren dan uitsluitend business analyse.

Ik verwacht echter niet dat dit betekent dat alle traditionele rollen in de toekomst vervangen zullen worden door de 3 hierboven genoemde Scrum rollen. Er zal in mijn ogen altijd een vorm van specialisme blijven bestaan in agile teams. Dat specialisme is sterk gekoppeld aan het individuele kennis- en ambitieniveau van de medewerkers. In mijn ogen is het bovenstaande niettemin een zeer bruikbare 'best role practice', die niet alleen kan worden toegepast binnen Scrum-projecten, maar in alle soorten agile projecten. Maar let op: dit is slechts een practice: ga vooral zelf op zoek naar wat er wel en wat er niet werkt in jouw organisatie. Succes!

vorige pagina