Als je met anderen samenwerkt kun je niet in je eentje bepalen hoe jullie werkwijze eruit ziet. Maar als analist heb je daar wel veel invloed op. En meer dan je denkt.
Hoe je jouw invloed aanwendt laten we graag zien met een praktijkvoorbeeld van Marco. Hij vertelt openhartig hoe hij de ontwikkelaars, die aanvankelijk de details 100% gespecificeerd wilde hebben heeft meegenomen in een agile werkwijze en welke stappen hij heeft gezet.
Wie is Marco?
Marco Huiskens is van oorsprong functioneel beheerder en werkt nu als informatie analist in een multidisciplinair agile team. Hij ondersteunt tevens de product owner. Marco werkt in de energiebranche en zijn organisatie zit midden in de transitie van een traditionele naar een agile werkwijze.
De afgelopen tijd heeft hij verschillende stappen gezet om het team mee te krijgen in de agile manier van werken. Marco volgde ons online trainingsprogramma. Tijdens de 1-op-1 begeleiding deelde hij wat er in zijn project gebeurde en welke inzichten hij kreeg. Zijn doel was om zijn werkwijze te verbeteren en daar zijn teamgenoten in mee te nemen.
Jouw praktijksituatie ook stapsgewijs verbeteren?
Wil jij de business en/of de ontwikkelaars meekrijgen in de agile werkwijze? Wil je de requirements op een agile manier opstellen en de samenwerking tussen business en IT verbeteren?
Dan zul je dat stap voor stap en in afstemming met je collega’s moeten doen. Je bent als analist immers niet bij machte om een werkwijze af te dwingen. Bovendien zou dat niet passen in de agile gedachte 🙂.
Laat ons je daarbij helpen. Volg net als Marco het trainings- en coachingsprogramma Daadkracht met agile requirements. En bereik net als Marco mooie resultaten door de invloed die je hebt slim te gebruiken.
Zijn praktijksituatie bij de start van het programma
Marco: “De praktijk is tot nu toe dat er vooral veel schriftelijk vastgelegd wordt. Binnen onze organisatie zijn we geneigd allerlei details in de user story vast te leggen om die maar zo gedetailleerd mogelijk te krijgen.
Op zich is dat niet vreemd. De ontwikkelaars geven namelijk aan pas een goede inschatting te kunnen doen van de hoeveelheid werk, als ze gedetailleerd weten wat de wens is. Het doel is om later als een item wordt ontwikkeld, geen vragen meer te hebben. Maar in de praktijk pakt dat natuurlijk toch weer anders uit.
Voor ons team bleek het de kunst om niet meer te focussen op alle details voor de sprint, maar verdere detaillering tijdens de sprint. De angst bij de ontwikkelaars is vooral dat ze straks constant met de business zitten te overleggen in plaats van te ontwikkelen. Dat lijkt mij niet nodig. Die angst wil ik wegnemen door het langzaam uit te proberen.”
Eerste stap
“We hebben de eerste stap inmiddels gezet. We proberen nu voor het eerst om meer mondeling af te stemmen. In onze huidige sprint hebben we een wijzigingsverzoek opgenomen dat niet al vooraf gedetailleerd is ingevuld. Afgesproken is juist dat de ontwikkelaar en de indiener de detaillering tijdens de sprint afstemmen.
In een eerder stadium was de ontwikkeltijd voor deze wijziging op ca. 3 dagen ingeschat. De wens van de ontwikkelaars was om deze toch nog een keer te refinen. Dat doen we deze keer dus niet. Het effect dat ik zag was dat het aantal ingeschatte punten, ineens tweemaal zo hoog werd. Toch weer wat koudwatervrees dus.
De afstemming hoeft echt niet 3 dagen permanent naast elkaar zitten te zijn. Maar elkaar opzoeken als er vragen zijn of als er iets ontwikkeld is (korte feedback loops). Ik denk dat er niets mis zal gaan. Ik verwacht dat we langzamerhand steeds vaker op deze manier gaan samenwerken.”
Vervolgstappen
“Ik ben met de product owner bezig de mondelinge afstemming steeds verder uit te breiden. We zijn nu de product backlog aan het opschonen. Zo werken we toe naar een situatie waarbij de refinement en ontwikkeling veel dichter op elkaar zitten. Dan is er dus nog minder noodzaak om veel vast te leggen.
Wat betreft inschattingen van user stories gaat het ons helpen als we de stories ophakken in behapbare brokken. De INVEST criteria helpen daar goed bij. Maximaal drie dagen ontwikkeltijd per individuele user story. Er blijft dan voldoende tijd over in de sprint om af te stemmen en eventueel aanpassingen door te voeren.
Als we deze slag maken, komen we ook meer los van de mini-waterval. Dan zijn we pas echt aan het sprinten. Doordat de user stories nu nog vaak te groot zijn, zijn de ontwikkelaars er de hele sprint mee bezig.”
Geboekte resultaten
“Het team heeft ervaren dat het helemaal niet nodig is om de requirements volledig te specificeren. En ze hebben gemerkt dat rechtstreeks contact met de business ook voordelen heeft.
De grootste winst is dat er nu ook vanuit het team actie wordt ondernomen om effectiever te werken. Ze gaven bijvoorbeeld zelf aan dat de user stories te groot zijn, en dat er teveel wordt doorgeschoven naar de volgende sprint. En dat dat suboptimaal is.
Het team stelde ook voor om de inschatting voortaan op basis van eerdere user stories te doen. Dus niet meer vanuit hun eigen inschatting van de uren die nodig zijn om iets te realiseren. Dat haalt wat druk weg van de inschatting. Het schatten blijkt in de praktijk ook makkelijker als het over kleine user stories gaat.
Ik heb gemerkt dat het verstandig is om mijn voorstellen een paar keer te herhalen en ze rustig te laten bezinken in het team. Dan landen ze beter dan wanneer ik de boel probeer te forceren. Het gaat trager dan ik zou willen, maar het werkt wel.”
Conclusie
Dit verhaal van Marco laat zien hoe je ook teamleden die vasthouden aan hun oude manier van werken toch meekrijgt. Je geeft ze dan de ruimte om geleidelijk de voordelen van agile requirements te ervaren. Na verloop van tijd krijgen ze de smaak te pakken en dragen ze zelf ook verbeterpunten aan. En dat is precies waar je heen wilt.
Dan ben je echt agile bezig. Jullie passen dan gezamenlijk jullie manier van werken aan jullie (dynamische) praktijksituatie aan. Stapsgewijs en proefondervindelijk.
Wil jij dat ook? Lees hier hoe wij je daar met het praktijkprogramma ‘Daadkracht met agile requirements’ bij kunnen helpen.
—
Dit artikel bevat grotendeels de letterlijke tekst van Marco. Wij hebben het alleen geanonimiseerd en kleine tekstuele aanpassingen gedaan, zodat geen kennis van zijn praktijksituatie nodig is.
Nicole de Swart & Priya Soekhai
