Er zijn nogal eens misverstanden over hetgeen agile van een analist verwacht. Moeten teamleden in agile generalist of specialist zijn?
Maar weinig analisten lijken scherp te hebben wat er van hen verwacht wordt. Zeker in een hybride (deel agile, deels traditionele) omgeving kunnen de verwachtingen nogal uiteenlopen.
Het is dan maar net aan wie je het vraagt. Grote kans dat je van je manager, je projectleider en je teamgenoten een verschillend antwoord krijgt. En soms weet die persoon zelf ook niet goed wat hij van jou als analist mag verwachten.
Geen wonder dat jij niet scherp krijgt wat er van je verwacht wordt.
Daar komt nog bij dat de verwachtingen van je collega’s behoorlijk af kunnen wijken van hetgeen agile erover zegt. Wat doe je dan? Waar ga je van uit als jij en je organisatie beter agile willen gaan werken?
Agile
Agile en vooral Scrum zijn in elk geval duidelijk over wat ze van de verschillende rollen verwachten. Ze noemen de analisten rol alleen niet expliciet. Afgelopen zomer heb ik een e-book geschreven over wat agile van je verwacht en hoe je daar in de praktijk mee omgaat. Ken je mijn e-book ‘Agile Requirements’ al?
Als je niet de rol van product owner of scrum master hebt maak je in scrum onderdeel uit van een multidisciplinaire ontwikkelteam.
Dat betekent niet dat je ook moet programmeren. Dat is een veelgehoord misverstand.
Generalisten en specialisten in agile
Van alle leden van het multidisciplinaire team verwacht agile dat ze ook werkzaamheden buiten hun specialisme (meehelpen) uitvoeren. Maar dat wil niet zeggen dat je een generalist moet zijn. Vooral je houding en bereidheid om in het belang van het team te handelen, is essentieel.
Specialisten zijn bijzonder waardevol, ook binnen agile. Een specialist voert de taken in zijn vakgebied doorgaans sneller en kwalitatief beter werk uit dan een generalist.
Onthoud dit
Een generalist en een specialist-op-één-gebied zijn twee uitersten op de specialisatieschaal. Het hoeft niet zwart of wit te zijn, niet generalist of specialist. Er zijn vele tinten grijs mogelijk.
Een agile team is niet alleen multidisciplinair en gezamenlijk verantwoordelijk voor het resultaat, ze zijn ook zelfsturend. Tijdens de dagelijkse stand up bepalen ze samen welke taken op dat moment de hoogste prioriteit hebben en wie welke taken uitvoert.
Vanzelfsprekend houden ze daarbij rekening met de competenties en voorkeuren van elk teamlid. Maar iedereen moet bijdrage leveren aan het teamresultaat. Wachten totdat een teamgenoot zijn werk heeft afgerond is er niet bij.
Er is altijd werk te doen in het teambelang. De ene keer doe je werk op jouw specialisme. De andere keer help je een teamgenoot die specialist in een ander vakgebied is. Zo leer je al doende nieuwe vaardigheden. En soms zijn er werkzaamheden waar niemand in je team ervaring mee heeft. Dan moet je het jezelf aanleren. Of in sommige gevallen tijdelijk hulp van buiten je team vragen.
Doordat je op deze manier nieuwe kennis en vaardigheden ontwikkeld, word je steeds waardevoller voor het team. En ontwikkel je na verloop van tijd misschien wel een tweede of derde specialisme. Perfect.
Specialisten op één gebied
De traditionele waterval aanpak rust op specialisten. En daar zijn nog steeds veel organisaties op ingericht. Er is dan bijvoorbeeld een afdeling met analisten, een afdeling met user interface designers, een afdeling met Java ontwikkelaars, etcetera.
In dit soort organisaties wordt (onbewust) het specialist-op-één-gebied zijn in stand gehouden. En stappen richting meerdere specialismen of generalist tegengewerkt.
Als analist (of tester of Java ontwikkelaar bijvoorbeeld) maak je vaak onderdeel uit van een afdeling met analisten en word je gestimuleerd om een betere analist te worden. Daar word je op beoordeeld en beloond. Je competenties verbreden of een ander specialisme aanleren doet je carrière (op korte termijn) geen goed.
Als analist (of andere specialist) word je soms in meerdere teams geplaatst omdat er een tekort is aan analisten, of omdat er in één team niet genoeg analysewerk voorhanden is. De achterliggende gedachte hierbij is dat analisten alleen analysewerk kunnen doen en dat al het analysewerk door analisten moet gebeuren. Dezelfde gedachtegang gaat voor ieder specialisme op.
Organisaties die hun teams op deze manier bemensen, houden daarmee zelf hun probleem van het tekort aan specialisten in stand. Ook leidt het tot andere problemen zodra er (tijdelijk) minder werk van een bepaald specialisme te doen is.
Bovendien realiseren zij zich niet dat tegelijkertijd voor meerdere agile teams werken funest is voor de productiviteit van de medewerker en voor de productiviteit van de teams als geheel.
Wat wordt er van jou verwacht?
- Dat je nog beter wordt in je vak?
- Dat je je competenties verbreedt?
Aan het antwoord op deze vraag zie je of de persoon een traditionele of een agile mindset heeft 🙂.
Wat ben jij op dit moment, een specialist, een generalist of ergens er tussenin? Laat het me hieronder weten.
Nicole de Swart
Vermoedelijk neig ik meer naar de generalist dan de specialist.
Mijn specialisme ligt in het ready maken van user stories maar als analist vind ik het ook heerlijk om af en toe door de code heen te neuzen ( = lezen, niet zelf programmeren) en om queries te maken voor het opsporen en oplossen van fouten.
Dat is inderdaad de fijnste combinatie. En bovendien levert het soms ook andere inzichten (en unhappy path’s) op, die je anders misschien niet had opgemerkt.
Wie zorgt er bij jullie voor incidenten opvolging?
Dag Koen,
Zowel het development team (DEVOPS) als de Product Owner zorgen voor de opvolging van incidenten. Daarbij is het team verantwoordelijk voor de afhandeling van errors die in productie optreden. Bij grote fouten wordt dit door de Product Owner geprioriteerd en ingepland.
Overige gevonden functionele fouten die buiten de inhoud van de sprint vallen worden door de Product Owner geprioriteerd.
Ik werk als specialist analist maar in mijn achtergrond heb ik ervaring in de volgende rollen: Oracle ontwikkelaar, testmanager, teamleiding, projectleiding, BI, opleidingskundige rollen (2e opleiding) zoals opzetten opleidingsbeleid, -plannen, ontwikkelen trainingen, geven van trainingen, opzetten opleidingsacademie. Je zou dus kunnen zeggen dat ik eigenlijk een generalist ben.
Als analist ben ik ‘het verlengstuk van de product owner’ van ons ‘domein’. Zij geeft de prioriteiten van de epics en user stories aan en ik werk deze in detail uit. Daarnaast ben ik veelal betrokken bij de bepaling van de business value in de analyse fase.
Afhankelijk van het onderwerp en het systeem waarin iets moet worden gebouwd en of dat systeem een intern of extern gebouwd systeem is, draai ik al of niet mee in het team dat de user stories uitwerkt. Meestal ben ik de persoon die de afstemming doet met ‘de business’ en vanaf het moment dat het probleem duidelijk is, werkt (een deel van) het team mee aan het vormgeven van de oplossing(en).
Tijdens de development fase (als de PO beslist heeft dat we van analyse overgaan op bouw), ben ik vaak betrokken bij het opstellen van de tests en doe ik de communicatie naar de ‘business’ voor feedback en in geval van onduidelijkheden in het proces en ik fungeer als vraagbaak voor het team. Verder ben ik dan meestal bezig met analyse voor een ander epic, vaak voor een ander team.
Ik werk dus voornamelijk als specialist, maar ben, wanneer ‘mijn’ user stories intern gebouwd worden, wel onderdeel van het team en doe ook werkzaamheden die niet sec analysewerk zijn.