Eind februari was het zover. Ik ging starten als Agile coach en scrummaster bij een opdrachtgever dat sinds een jaar scrum geimplementeerd heeft in de teams. Mijn opdracht is als agile coach het verder implementeren van de Agile mindset, principes en scrum methodieken binnen de afdeling en voor 3 teams als scrummaster fungeren.
In mijn eerste twee weken ben ik bewust alleen maar mee gaan draaien met de teams. Eerst maar eens de manier van werken en de teamdynamieken observeren om zo een goede eerste indruk te krijgen in hoe ver de teams in hun Agile transformatie zijn. Daarnaast wilde ik met iedereen binnen de afdeling individueel kennismaken. Niet alleen met de mensen in de Agile teams, maar ook met de beheerafdelingen. Welke persoonlijkheden zitten er in het team, wat zijn hun ambities en drijfveren en in welke mate is het team op elkaar ingespeeld. En vooral was ik benieuwd hoe zij Scrum ervaarden: Wat vinden zij er goed aan en wat juist niet en hoe gaat de samenwerking tussen de Agile teams en de beheerteams?
Na twee weken heb ik mijn rol als scrummaster en Agile coach actief opgepakt. Het was snel duidelijk dat de scrum ceremonies goed gevolgd werden en dat het team de meerwaarde van de meeste sessies wel ervaren. Een mooi fundament om mee te beginnen. De echte Agile transformatie stond nog aan het begin.
Een van mijn eerste observaties was dat de teams user stories vanuit activiteit (ontwikkelen, testen, etc) werden geschreven en over het algemeen te groot zijn om in een sprint af te ronden. Hierdoor was JIRA een verkapte versie van MSProject en werd de context en het uiteindelijke gezamenlijke doel van alle user stories gemist door het team. Om frustraties vanuit het team te kanaliseren hadden ze al een tijd geleden samen besloten om aan het einde van hun sprint niet afgeronde user stories toch op done te zetten en nieuwe user stories aan te maken (clonen) voor de volgende sprint. Hierdoor had het team toch een resultaat wat aan management gerapporteerd kon worden. Een klassieke misvatting wat ik al zo vaak heb zien gebeuren. Velocity is een feedback voor het team en niet een management KPI. Het team inzicht laten krijgen in hun velocity, of in andere woorden hoeveel werk kunnen we eigenlijk aan in de sprints, is het primaire doel van de storypoints.
Ik had mijn eerste concrete onderwerp gevonden om het team te coachen in hun Agile ontdekkingsreis. Stap 1 wat we samen hebben ingevoerd is dat niet afgeronde user stories niet meer alsnog gesloten worden aan het einde van de sprint, maar in de sprintreview besproken worden. De PO geeft in de volgende sprintplanning sessie aan of deze onafgemaakte user story in de volgende sprint opgepakt dient te worden of dat de prioriteit veranderd is en dat deze dus teruggaat naar de backlog.
Maar dan krijgen we nooit het werk af in een sprint was de reactie van het team. “Onze user stories zijn veel te groot om in 1 sprint af te handelen” en “bij ons werkt dat niet zo, wij zijn anders” waren de opmerkingen... Ok. Hoe begrijpelijk het is om korte termijn pijn te verzachten, maar mijn advies is niet doen! Zachte heelmeesters maken stinkende wonden. Door de pijn te voelen, komt de noodzaak om deze pijn op te lossen. Dit betekent wel dat je als scrummaster geduld moet hebben, het niet erg moet vinden dat het team je op zo een moment waarschijnlijk niet heel aardig vind (of gewoonweg lastig) en goed de visie met deze aanpak moet blijven communiceren (ook naar jezelf).
Dus hoe nu verder? Vragen die ik daarbij heb voorgelegd aan het team waren: Hoe schrijven jullie de user stories eigenlijk? Oh, vanuit takenperspectief. Maar hoe weten julie als team dan dat jullie alle kwalitatieve stappen in het voortbrengingsproces met elkaar hebben afgerond en dus de functionele waarde hebben geleverd aan jullie klant als de user story op done gezet wordt? En is bij het sluiten van de user story een potentially shipable product opgeleverd dat voldoet aan jullie kwaliteitsstandaarden.
Ik zag het team mentaal worstelen met deze onderwerpen. Geen probleem, het is een proces waar we samen doorheen gaan. Het is niet voor niets dat men zegt dat “Scrum is easy to understand, but difficult to master”.
We hebben drie onderwerpen samen geidentificeerd die we als eerste kunnen oppakken (waarbij ik wel het team een duwtje in de juiste richting gegeven heb om deze motor op te starten). De onderwerpen zijn:
- Een standaard flow of work bepalen. Met andere woorden hoe vloeit een business of technisch verzoek bij voorkeur door het implementatieproces en OTAP straat. Door een standaard flow samen te bepalen helpt in de volgende stap in het beter inschatten van de effort door middel van pokeren.
- Nieuwe verzoeken vertalen in user stories die vanuit de klantperspectief worden beschreven. Naast dat dit helpt om de klant vraag context scherp te houden, helpt dit ook in het slicen van user stories naar zo een niveau dat het wel in een sprint past.
- De kwaliteitsstappen van het Agile team bepalen die volgens hen nodig zijn om de user stories op te leveren en in de demo te laten zien aan de klant. Deze kwaliteitsstappen worden door het team vastgelegd in de Definition of Done en geeft houvast om de afgesproken kwaliteitsstandaarden te waarborgen.
Met enige terughoudenheid, afwachtendheid en soms zelf uitgesproken weerstand is het team meegegaan met mij in deze eerste stappen op hun Agile ontdekkingsreis. De eerste aanzet tot de Definition of Done is inmiddels samen bepaald, de eerste user stories zijn beschreven vanuit de klantperspectief en we hebben een eerste goede stap gemaakt in het inzichtelijk maken van de standaard work of flow proces.
Benieuwd naar de resultaten hoe deze eerste stappen verlopen zijn? Ik praat jullie bij na de zomerperiode.
