Wie denkt aan een agile manier van werken, zoals Scrum, denkt niet meteen aan het maken van ‘planningen’. Sterker nog; de flexibiliteit en wendbaarheid van agile lijken op het eerste gezicht moeilijk te verenigen met de rigiditeit van een lange termijnplanning.
Waarom een planning uw grootste vriend is in Scrum (en niet de vijand)
De misvatting over Scrum en planningen
Het tegendeel is waar, volgens Marc Jousma. Als product owner bij Info Support is hij onder meer verantwoordelijk voor roadmapping en het afstemmen van verwachtingen tussen de stakeholders en het ontwikkelteam. “Sommige ontwikkelteams denken dat Scrum gelijk staat aan het niet hebben van deadlines. Maar dat is niet zo. Feitelijk is Scrum een werkwijze om zo snel mogelijk waarde te leveren. Hier hoort altijd een tijdsfactor, planning of deadline bij.”
De kracht van roadmapping
Een plan helpt een ontwikkelteam om te focussen, volgens Marc. “Dat begint bij de visie, missie en strategie van de organisatie. Op basis daarvan bepaal je de jaardoelstellingen van het product. En die kunnen vervolgens weer, als het goed is, worden vertaald naar een portfolio roadmap; dit willen we met ontwikkelteams gaan bereiken dit jaar. Individuele teams werken via hun sprintdoelstellingen dan aan deze roadmap – een lange termijnplanning van verschillende features. Als Product Owner bepaal je vervolgens welke van deze features als eerste kunnen worden opgepakt. En deze worden dan uitgewerkt en in sprints opgepakt.”
Idealiter wordt de planning en prioriteit bepaald op organisatieniveau, en dus niet op productniveau, aldus Marc: “Alleen dan kun je er zeker van zijn dat meerdere ontwikkelteams, met allemaal hun eigen product owners, samen werken aan de doelstellingen van de organisatie. In de praktijk zie je echter vaak gebeuren dat organisaties het moeilijk vinden om te kiezen; eigenlijk is alles even belangrijk. Daar komt bij dat elk team zijn eigen verantwoordelijkheden heeft en die komen niet altijd met elkaar overeen. Daarom moet er eigenlijk op management-niveau worden gekeken naar prioriteiten. Met duidelijke keuzes en een goede prioritering kan je goed sturen op Epics over meerdere teams heen. Hier ligt vaak het probleem. Deze problemen zijn er minder als je de gehele keten in eigen beheer hebt.”
Strategisch denken binnen IT-teams
Voor ontwikkelteams is er echter ook een eigen verantwoordelijkheid, aldus de product owner: “Als je aan de developers vraagt ‘wat zijn onze jaardoelstellingen?’, dan kom je er vaak achter dat ze dat niet weten. Ik denk dat de roadmap bij veel ontwikkelteams niet of te weinig zichtbaar is. Alleen als je weet hoe de roadmap eruitziet, dan kun je de technische oplossing en architectuur kiezen die houdbaar is op langere termijn.”
Het zou goed zijn als IT-teams zich vaker afvragen waarom ze ergens aan werken, aldus Marc: “Het staat vaak buiten kijf dat IT-teams technisch van alles kunnen waarmaken. Dat is het probleem niet. Maar pas als je de waarom-vraag stelt – ‘waarom doen we eigenlijk wat we doen?’ – kun je als team een betere of een andere oplossing adviseren, en dus strategisch te werk gaan. Eigenlijk is het heel simpel: als jij een team een oplossingsrichting geeft, dan gaan ze die oplossingsrichting bouwen. Het is in mijn ervaring beter om ze de probleemstelling voor te leggen, want dan stimuleer je het team om mee te denken om het probleem zo goed en efficiënt mogelijk op te lossen.”
Dit artikel is gemaakt op basis van een podcast uit de serie ‘Business vooruit met IT’. In deze aflevering praten collega’s Kenzo Dominicus en Marc Jousma over roadmaps en deadlines in IT Scrum-projecten.