Wie online zoekt op ‘agile’ komt termen tegen zoals behendig, lenig, vlug, rap, wendbaar en flexibel. De termen impliceren dat met een agile manier van werken productontwikkeling op een snelle, zorgvuldige en flexibele manier tot stand komt. “Ideaal” horen wij je denken, “dat is precies wat ik wil bereiken”. Daar zijn wij het volledig mee eens, maar wij zien in de praktijk ook een keerzijde van de medaille. Met name als het gaat om veranderende requirements, inzichten of prioriteiten.
Een stakeholder verandert zijn of haar mening, het management kiest voor nieuwe prioriteiten of maakt andere beslissingen omtrent budgettering, een nieuwe technologie doet zijn intrede of de veranderende markt leidt tot nieuwe uitdagingen. Er zijn tal van voorbeelden waarbij het valide is dat er flexibiliteit nodig is in requirements of prioriteiten. “Graag de hoogste prioriteit op dit nieuwe initiatief, desnoods laten we de andere trajecten vallen als we daarvoor onvoldoende resources hebben”, hoorden wij de projectleider zeggen in een meeting over het bepalen van de nieuwe jaardoelen.
Het Agile Manifesto leert ons dat we ‘changing requirements’ moeten verwelkomen, zelfs in een laat stadium van ontwikkeling. Zolang het bijdraagt aan het concurrentievoordeel van de klant is het van belang om requirements of prioriteiten te kunnen veranderen. Theoretisch is dit natuurlijk een nobele gedachte. Het heeft minder zin om functionaliteiten te ontwikkelen die er niet voor zorgen dat je concurrentiepositie ten opzichte van de concurrent verbetert. Maar in de praktijk merken wij dat hier behoorlijke haken en ogen aan zitten. Op het moment dat begonnen is aan bepaalde ontwikkelingen en als projecten eenmaal zijn opgestart, gaat het wisselen van prioriteiten en het fundamenteel wijzigen van requirements in (traditionele) organisaties niet zo snel en eenvoudig.
Dit laatste heeft overigens te maken met de maturity van de organisatie met agile werken. Wanneer niet alle lagen en onderdelen van de organisatie volledig zijn ingericht op een agile manier van werken, is het lastig om in te springen op snel wijzigende prioriteiten of requirements. In blog #3 van de reeks Het dagboek van een Agilist, getiteld ‘Out of the Blue’, geven we een aantal tips om hier mee om te gaan.
Toch kan, in nog niet agile-volwassen bedrijven, voor een groot deel voorkomen worden dat er zoveel wisselingen in prioriteiten en requirements plaatsvinden. We zien namelijk geregeld in de praktijk dat het management en/of de business owners onvoldoende helder hebben welke ontwikkelingen de organisatie verder helpen. Of andersom: er zijn zoveel ontwikkelingen die de organisatie verder kunnen helpen dat ze niet weten (of er niet over eens worden) welke ontwikkeling de hoogste prioriteit moet hebben en daarom alles tegelijk willen opstarten. Ook komt het voor dat bepaalde ontwikkelingen worden opgestart zonder precies helder te hebben wat het doel is en waaraan het precies moet voldoen. Het is bijvoorbeeld een technologie die modern is en daar willen ze ook wat mee doen. In dat geval geloven ze wel dat de ontwikkeling bijdraagt aan de visie en doelstelling, maar hoe de functionaliteiten er precies uit moet komen te zien is niet helemaal helder. Gewoon starten is dan het credo. Maar hier komen ze niet veel later dan weer op terug.
Een groot probleem met deze manier van agile werken is dat medewerkers van de organisatie niet weten waar ze aan toe zijn en dat levert weerstand op. Hoe kun je als organisatie een gulden middenweg vinden?
1. Zorg voor een heldere visie en een roadmap
Dit is natuurlijk een open deur, maar daarom niet minder waar. Zorg ervoor dat je als organisatie helder hebt waar je naartoe wil groeien en welke producten daarvoor nodig zijn. Zet deze productontwikkelingen in een roadmap; zo dwing je jezelf om na te denken over welke ontwikkelingen als eerste opgepakt worden. Probeer te voorkomen dat te veel ontwikkelingen tegelijk opgepakt worden.
Daarnaast is het belangrijk om deze visie en roadmap te communiceren met alle stakeholders. Je zal niet de eerste organisatie zijn waarin productontwikkelingen veel vragende blikken krijgen van medewerkers.
2. Maak het visueel
Het zichtbaar maken van de roadmap of de aankomende prioriteiten geeft de stakeholders een duidelijk overzicht van wat er allemaal moet gebeuren. Het geven van dit inzicht aan stakeholders biedt een mate van rust, maar geeft hen ook de mogelijkheid om de discussie aan te gaan om zo prioriteiten beter op elkaar af te stemmen. Er zijn verschillende manieren om een roadmap te presenteren. Dat kan digitaal middels borden als Trello, Kanbanflow of Jira, maar ook niet digitaal door bijvoorbeeld post-its op een muur te plakken.
3. Zorg voor voldoende mandaat bij de Product Owner
Waar het management verantwoordelijk is voor het bepalen van de prioriteiten op producten is de Product Owner verantwoordelijk voor het bepalen van de prioriteiten binnen het product. Het is van belang dat de Product Owner voldoende mandaat heeft en het vertrouwen krijgt om zelf deze prioriteiten te bepalen. Geregeld zien wij in de praktijk dat alsnog het management of een bepaalde stakeholder bepaalt welke product backlog items als eerste opgepakt moeten worden. Dit levert vertraging op doordat stuurgroepmeetings bijvoorbeeld eens per maand zijn en pas daar een keuze gemaakt wordt over bepaalde prioriteiten. Een goede manier om het management en stakeholders mee te laten gaan in de agile werkwijze is het ‘heilig’ stellen van een sprintdoel. Ze zijn van harte welkom om mee te praten over wat er in de volgende sprint opgepakt moet worden, maar na de Sprint Planning hebben ze pech. Op deze manier zullen last-minute prio verschuivingen verdwijnen, omdat ze toch geen zin hebben. Mits de PO mandaat heeft en zijn of haar voet stijf houdt.
Het is aan de product owner om requirements bij de business op te halen, te vertalen naar user stories en deze te prioriteren op de product backlog naar gelang de business value. De product owner is op die manier de linking pin tussen het development team en de stakeholders van de te ontwikkelen (software-)producten. Onder die stakeholders valt ook het management.
4. Ontwikkel zo snel mogelijk een POC of MVP
Om snel feedback te krijgen van klanten en/of stakeholders is het van belang zo snel mogelijk een Proof of Concept (POC) of Minimal Viable Product (MVP) op te leveren. Met een dergelijke POC of MVP krijgen stakeholders een goede eerste indruk van het (toekomstig) product en kan direct bepaald worden of de ontwikkeling doorgezet kan worden of dat we met andere producten aan de slag gaan.
Het Agile Manifesto roept dat: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Wij willen hier graag aan toevoegen dat inderdaad vroeg begonnen moet worden met het ontwikkelen van waardevolle functionaliteiten, maar niet te vroeg om onnodige vertraging of weerstand voorkomen.
---------------------
Jelle Roo en Michiel Beskers werken beiden bij Capgemini en hebben jarenlange ervaring met agile werken in verschillende functies, zoals Product Owner, Scrum Master of agile business/informatie analist. In de reeks ‘Het dagboek van een agilist’ schetsen zij waarnemingen uit hun dagelijkse praktijk die raakvlakken hebben met zowel een digitale transformatie als een transformatie naar een agile en scrum manier van werken.
