In deze blog kijken we naar de toegevoegde waarde van business analyse bij agile systeemontwikkeling. Niet alleen mensen met de functie ‘analist’ doen aan analyse. Ook Product Owners, ontwikkelaars, testers, gebruikers en beheerders voeren vaak analysetaken uit. Dit wordt vaak aangeduid met de term T-shaped professionals (verderop meer hierover). Als je verschillende agile frameworks (Scrum, LeSS, SAFe en DAD) eens goed bekijkt, zie je dat er nergens een aparte business-analyserol wordt onderkend. Dat brengt me tot de volgende vraag:
Wat is de toegevoegde waarde van business analyse in een agile team en welke rollen kan een (business) analist daarin vervullen?
In deze blog ga ik op zoek naar het antwoord op deze samengestelde vraag. Om het wat te vereenvoudigen, knip ik de vraag op in twee delen:
- Welke rollen kan iemand met de functie business analist (informatieanalist of requirements analist) spelen in een agile team?
- Vanuit welke rollen in een agile team worden business analyse-activiteiten uitgevoerd?
In deze blog beantwoord ik de eerste vraag en in de volgende blog (deel 2) zal ik terugkomen op vraag 2.
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 en functies worden geplot op de agile rollen van DAD (zie figuur 1). Hoe dikker de lijn, hoe waarschijnlijker de match.
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 voeg daaraan zelf nog een vierde optie toe, namelijk als Subject Matter Expert (SME). Hierna werk ik de opties een voor een verder uit.
Optie 1: De business analist als Product Owner
De meest voor de hand liggende rol die een business analist in een agile team kan vervullen, is die van Product Owner. De Product Owner is immers de persoon die alle product requirements eliciteert bij de stakeholders, ze vervolgens beschrijft en op de Product Backlog (of Work Items List) zet. Daarna prioriteert de Product Owner de requirements en bespreekt ze met alle teamleden. De (business) analist is van oudsher degene die deze activiteiten uitvoert.
Figuur 2 toont de aandachtsgebieden van Product Owners en analisten. Beide rollen zijn sterk gericht op het product in wording met de daarbij horende needs en features, productscope, stakeholderconsensus en het vakgebied requirements engineering.
Zoals blijkt uit de figuur hebben de Product Owner en de business analist veel overeenkomsten. Niettemin zijn hun rollen in de praktijk vaak verschillend. Dit heeft volgens mij twee oorzaken. Ten eerste is de business analist over het algemeen geen eigenaar van het product, waardoor hij of zij geen mandaat heeft voor het nemen van belangrijke beslissingen voor het nieuwe product. Een andere oorzaak is dat de analistenrol in veel gevallen is ondergebracht bij iemand van IT (bijvoorbeeld als informatieanalist of requirements analist), terwijl de Product Owner over het algemeen een afgevaardigde is van de business.
Hoewel Product Owners afkomstig uit de business hun organisatie meestal heel goed kennen (meestal als productmanager), ontbreekt het vaak aan een gedegen achtergrond in IT-development. 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 om met verschillende partijen te praten. Partijen die niet zelden verschillende belangen en achtergronden hebben en die allemaal op één lijn moeten worden gebracht rond de gekozen oplossing. Die specialist is de (business) analist.
Figuur 2 laat naast de overlappingen ook de verschillen zien tussen Product Owner en analist. De Product Owner is meer gericht op eigenaarschap plus de daaraan gekoppelde beslissingsbevoegdheid. Hiertoe heeft de Product Owner een visie nodig over het product (in wording), die vertaald moet worden in een productstrategie. Alles bij elkaar opgeteld is de Product Owner dus niet alleen eigenaar, maar ook de manager van het product. Dit komt vooral tot uiting door de prioritering van de requirements.
Aan de andere kant is de productanalist[1] degene die belast is met modellering en documentatie van alle (gedetailleerde) requirements. Hij werkt de Product Backlog items verder uit (in bijvoorbeeld use case beschrijvingen) en communiceert ze met de Product Owner en het ontwikkelteam.
Onthoud:
1. Een analist kán de rol vervullen van product owner.
2. Iedere Product Owner is (onder andere) een analist.
Optie 2: De business analist als Team Member
Vanwege het ontbreken van mandaat worden veel analisten niet ingedeeld als Product Owner, maar als Team Member. De Team Member concentreert zich op het bouwen plus opleveren van het software product. Teamleden worden soms aangeduid als developer. Deze ‘rolvervaging’ treedt op doordat ontwikkelaars in agile teams naast programmeertaken ook vaak activiteiten uitvoeren die tot andere disciplines behoren, zoals testen, databaseontwerp en -bouw, UX design en integratie. De grondleggers van DAD hebben het over zogenoemde generalizing specialists. Daarmee bedoelen ze dat iedereen weliswaar een eigen specialisme heeft, maar daarnaast andere taken uitvoert. Bij de beantwoording van vraag 2 (in de volgende blog) kom ik hierop terug.
Optie 3: De business analist 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 Scrumtheorie, -praktijk en -regels. Tijdens de Sprint Retrospectives, waarin per Sprint wordt teruggekeken op de kwaliteit van het proces van systeemontwikkeling, speelt de Scrum Master 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 dat de rol van Scrum Master 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.[2]
Hij onderscheidt vier focusgebieden:
- Teamfocus
- Product Owner-focus
- Organization-focus
- Development practices-focus
1. Teamfocus
Initieel zal een Scrum Master relatief veel tijd en energie moeten steken in het ‘op de rails’ krijgen van het ontwikkelteam. Maar naarmate er meer Sprints voorbijgaan, raakt het team meer op elkaar ingespeeld en is hiervoor minder inspanning van de Scrum Master nodig. Het team is inmiddels in staat tot zelfsturing en neemt zelf beslissingen. De grafiek toont aanvankelijk dus een hoge focus en die daalt later aanzienlijk.
2. Product Owner-focus
Dezelfde curve gaat op voor de Product Owner-focus. Tegelijk met de teamfocus is de Scrum Master druk met het ‘coachen’ van de Product Owner. Zoals ik hiervoor al aangaf, zie ik in de praktijk regelmatig mensen opereren als Product Owner die dit voor het eerst zijn en begeleid moeten worden in deze rol. Aangezien de business analist van huis uit gewend is om requirements te eliciteren en in kaart te brengen, kan hij als Scrum Master de Product Owner hierin prima begeleiden. Ook als een persoon niet de juiste Product Owner blijkt te zijn, kan de Scrum Master ondersteunen bij het vinden van een geschikte vervanger.
3. Organization-focus
De curve die hierbij hoort, wijkt af van de vorige twee: aanvankelijk is er veel inspanning nodig van een Scrum Master om een organisatie mee te krijgen in agile projecten, maar dit wordt minder naarmate het meer ingebed raakt in de organisatie. Tot slot is er weer meer organisatorische aandacht nodig op het moment dat development practices organisatiebreed toegepast moeten worden om de organisatie te verbeteren op het gebied van systeemontwikkeling. Uiteindelijk kan wellicht de stap naar een agile enterprise worden gezet. In dat geval wordt er in de hele 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 (de Shufase). De Scrum Master begeleidt de Product Owner 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 – komt de focus meer te liggen op continue verbetering (van de gehele organisatie) door middel van pattern mining en de toepassing van talloze (best) practices. Het is aan de organisatie zelf om te bekijken welke practices er wel en welke er niet werken (in een bepaalde situatie).
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 uitmaken, zijn business analisten over het algemeen erg goed in staat om als Scrum Master te fungeren. Op alle genoemde focusgebieden. Regelmatig heb ik de Scrum Master-rol gecombineerd met de rol van analist. Dit kan een prima combinatierol zijn zolang de werkzaamheden van de business analist als Team Member maar niet in de weg staan van de Scrum Master-activiteiten of andersom.
Optie 4: De business analist als Subject Matter Expert
Last but not least: veel business analisten maken geen deel uit van de primaire, maar van de supplementaire stakeholdergroep42. Dit wil zeggen dat ze niet op dagelijkse basis betrokken zijn in het systeemontwikkelingsproject, maar meer een vraagbaak vormen bij complexe vraagstukken. Met andere woorden: ze stellen niet de vragen (aan stakeholders), maar geven antwoorden vanuit hun expertise (als specialist of domeinexpert).
In de volgende blog zal ik antwoord geven op de andere vraag: ‘Vanuit welke rollen in een agile team worden business analyse-activiteiten uitgevoerd?’
[1] Ik gebruik hier bewust de term productanalist om duidelijk de link te leggen met de rol van Product Owner. In beide rollen werken mensen aan de totstandkoming van een product, de ene als analist en de andere als eigenaar.
[2] Dit kun je dus zien als een vorm van verspilling.
Recente reacties