Agile werken vraagt om continu keuzes maken. En dus om prioriteiten stellen. Wat moeten we als team nu het eerste oppakken? Met welke backlog items, user stories, of in termen van Agile ABC: benefits, gaan we aan de slag? Wat is voor de belanghebbenden het belangrijkst? Wat levert nu de meeste waarde?
Binnen agile werken heeft de product owner een centrale rol in het prioriteren. Hij of zij maakt de afweging tussen de wensen en eisen van de verschillende belanghebbenden. Maar een product owner kan ook niet alles overzien. Een goede product owner luistert daarom naar het team. In het team zitten per slot van rekening kennis en inzichten die de product owner mogelijk zelf niet heeft.
Er zijn verschillende methoden om te prioriteren. Ik ben teams tegengekomen die werken met met de prioriteitenmatrix van Eisenhower (in hoeverre is iets urgent en/of belangrijk?) of met de MoSCoW-methode (ieder onderdeel is een Must-have, Should-have, Could-have of een Won't-have).
Er kleven echter serieuze tekortkomingen aan deze methodes. De Eisenhower-matrix gaat vooral over prioritering in de tijd, niet om prioritering op inhoud of waarde. Bij MoSCoW bestaat het risico dat aan de meeste onderwerpen een must-have wordt toegekend; het is heel menselijk om aan onderwerpen die op je eigen vakgebied liggen, of die je aan het hart gaan, een hogere prioriteit toe te kennen.
Maar dit soort klassieke methodes heeft nog een ander nadeel. Het komt bij toepassing helaas net te vaak voor dat degene die het hardst roept of de meeste invloed uitoefent, bepaalt wat de hoogste prioriteit is. Dit geldt ook voor een product owner die net te gemakkelijk voorbij gaat aan de inbreng vanuit het team. Te meer wanneer er ook nog een hiërarchische verhouding is met het team, bijvoorbeeld wanneer de product owner ook de manager van het team is.
Met dat vraagstuk ben ik een jaar of 10 geleden aan het sleutelen gegaan. Daar is het zogenaamde Bulk & Gedonder kwadrant [B. Lemaire, Ballen (m/v) op het blok, Kluwer 2013] uit geboren. Sinds die tijd pas ik het in mijn agile werkpraktijk ook met succes en plezier toe en het kwadrant is een vast onderdeel van het Agile ABC geworden.
Bij het Bulk & Gedonder kwadrant draai je de vraagstelling om. Je vraagt je als team niet af wat het belangrijkste is maar je bepaalt met elkaar wat de gevolgen zijn als je een benefit niet realiseert. Je wordt daarmee gedwongen om te denken vanuit de klant en de belanghebbenden, niet persoonlijke overwegingen of macht. Je prioriteert dus op basis van waardecreatie!
Het bepalen van prioriteit doe je aan de hand van twee assen: de Bulk-as en de Gedonder-as. De Bulk-as gaat om de gebruikers of je doelgroep: belanghebbenden als klanten, medewerkers of, in het publieke domein, inwoners. De Gedonder-as betreft de escalatie-as en gaat over belanghebbenden als het verantwoordelijke management, contractpartners of, in het publieke domein, de politiek.
Een voorbeeld. Als agile coach was ik binnen een gemeente betrokken bij een project voor de renovatie van een kanaal dat midden door een woonwijk liep. De doelgroep, de Bulk-as, waren de inwoners rond het kanaal. De Gedonder-as was de politiek: komen er raadsvragen, of komt de wethouder hier boos over de vloer als we deze benefit niet realiseren? Zo ontstond een product backlog met een prioritering op basis van klantwaarde: wat voor de betrokken inwoners en de politiek werkelijk belangrijk is.
Tijdens het prioriteren stel je als agile coach of scrum master bij iedere benefit (of backlog item) de vragen:
- Als jullie deze benefit niet realiseren, hebben daar onacceptabel veel gebruikers (de bulk) last van?
- Als jullie deze benefit niet realiseren, volgt dan escalatie (komt er dan gedonder van)?
Bij tweemaal een ja heb je een prio 1 te pakken. Bij twee keer een nee een prio 3. In de andere gevallen is de prioriteit 2. Wat ik vervolgens persoonlijk doe om de prioriteit te visualiseren, is de post-its met de prio 1 items te voorzien van een rood stickertje. De prio's 2 krijgen een geel stickertje, de prio's 3 groen.
De focus van de inzet van je team komt te liggen op de benefits met prio 1. Wanneer het team onder tijdsdruk komt, vervallen (in ieder geval voor de huidige sprint) de prio's 3 en vervolgens de prio's 2. De toekenning van prioriteiten is overigens dynamisch; er kan in de tijd van alles gebeuren waardoor ze verandert. Tijdens de sprint meetup kun je de prioritering aanpassen.
Basile Lemaire ©2011 ©2013 ©2017
Basile Lemaire
Tel: 06 - 2786 5797
E-mail: info@publiekprojectmanagement.nl
