In de vorige blog hebben we gekeken naar de toegevoegde waarde van business analyse bij agile systeemontwikkeling. We zagen dat business analisten alle teamrollen van Scrum kan vervullen. In deze blog draaien we de vraag om:
Vanuit welke rollen in een agile team worden business analyse-activiteiten uitgevoerd?
Voordat ik antwoord geef op deze vraag, beschrijf ik eerst het begrip T-shaped professional. De T-shaped professional is een generalizing specialist, een persoon die enerzijds een specialisme heeft, bijvoorbeeld testen. Over dit vakgebied weet de professional ‘alles’ en hij of zij heeft de ambitie om zich hierin 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 van en ervaring met andere disciplines op. Zo ontstaat de T-vorm. 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.
Figuur 1: T-shaped business analist
Met andere woorden: de programmeur analyseert en de analist programmeert. Je vraagt je nu wellicht af: werkt dit? Het antwoord hangt natuurlijk af van de situatie. In de ene organisatie zal dit makkelijker zijn dan in de andere, 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 organisaties die al lange tijd bestaan is er meestal een functiehuis waarin sprake is van een sterke specialisatie van rollen. Daarnaast is ambitie cruciaal. In veel gevallen wil een programmeur helemaal geen analyses of tests doen of heeft die daar geen tijd voor, en vaak kan of wil een tester helemaal niet programmeren, maar gaat die op zoek 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 is. Je moet doen wat je leuk vindt of waar je ambities liggen.
Figuur 2:T-shaped tester
Natuurlijk kan dat een combinatie zijn van diverse disciplines, maar ik merk in de praktijk dat de meeste mensen gewoon hun ding willen doen, en in de meeste gevallen werkt dit prima. Wat voor programmeren geldt, geldt in mijn ogen ook voor (business) analyse: hoewel de meeste mensen best betrekkelijk eenvoudige analyses kunnen maken, is het toch een apart specialisme; je moet een mindset hebben én het leuk vinden om op continue basis organisaties (of onderdelen daarvan) te verbeteren. En dat geldt niet voor iedereen.
Conclusie
Een analist als Scrum Master of Team Lead is een goed idee, omdat een analist gewend is een procesbril op te zetten en veel energie te steken in het verbeteren van organisaties. Eerst concentreert hij of zij zich op het team en de Product Owner, later op andere delen van de organisaties plus development practices. Ook een analist als Product Owner is een goed idee, omdat hij of zij gewend is met stakeholders te praten om hun behoeften in kaart te brengen. Ook is hij of zij gewend om de stakeholders op één lijn te krijgen. Maar het is het gebrek aan mandaat dat ertoe leidt dat analisten meestal niet de rol van Product Owner krijgen.
In de verreweg de meeste gevallen is de business analist een Team Member die al dan niet in de combinatierol Scrum Master/Team Member de Product Owner helpt met het uitwerken van requirements die de basis vormen voor de ontwikkelaars en de testers uit het agile Development Team. Maar het is niet alleen de (business) analist die business analysewerkzaamheden uitvoert in een agile team. Steeds vaker is er sprake van Tshaped professionals die naast hun eigen discipline, bijvoorbeeld testen, ook andersoortige activiteiten uitvoeren, waaronder business analyse-taken. 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 worden vervangen door de drie hiervoor genoemde Scrum-rollen. Ik denk dat er in agile teams altijd een vorm van specialisme zal blijven bestaan. Dat specialisme is sterk gekoppeld aan het individuele kennis- en ambitieniveau van de medewerkers. In mijn ogen is het genoemde niettemin een zeer bruikbare ‘best role practice’, die niet alleen binnen Scrum-projecten kan worden toegepast, 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!
Recente reacties