Een groeiend aantal organisaties werkt al volgens een agile methode of is bezig een agile methode in te voeren (meer over agile kan je vinden in eerdere blogs). Bekende voorbeelden zijn Spotify en ING. Zeker in organisaties die nog in de transitie naar agile zitten krijgen projectmanagers en product owners met elkaar te maken, terwijl de besturing (governance) soms nog niet goed is ingericht. In die situatie zag ik een paar keer een krachtmeting ontstaan tussen een projectmanager en een product owner omdat ze het niet eens werden over de prioriteit die een product owner gaf aan een ‘user story’ (het werk) van deze projectmanager. Dat is eigenlijk best merkwaardig en heeft mijns inziens te maken met het ontbreken van heldere afspraken. Dus je kan er wat aan doen: afspraken maken!

Het gaat niet om persoonlijk winnen!

In een ideale situatie zou de projectmanager niet met een product owner moeten wedijveren. Het zou moeten gaan om datgene voorrang te geven dat topprioriteit voor de organisatie heeft. Maar de projectmanager wil zijn project op de afgesproken datum opleveren en de product owner kijkt bij de voorbereiding van een sprint welke user stories de hoogste business waarde opleveren. Dan zie ik het gebeuren dat een project met de hoogste prioriteit (bijvoorbeeld invoering van de AVG) wordt vertraagd, omdat de product owner een andere user story, die volgens hem een veel hogere businesswaarde oplevert, voorrang geeft. Met als gevolg dat de projectmanager het gevraagde niet geleverd krijgt. Met als risico dat het project vertraagt.

Wie grijpt er dan in? De opdrachtgever van het project heeft niet de hiërarchische bevoegdheid om de product owner hierop aan te spreken. In organisaties waarin agile bottom-up wordt ingevoerd krijgt het inrichten van de besturingslaag boven de product owner soms te laat aandacht. De projectmanager en zijn opdrachtgever hebben dan geen logisch aanspreekpunt om te escaleren. Waardoor de product owner te veel speelruimte krijgt met als risico dat hij/zij te weinig oog heeft voor het organisatiebelang. Projecten lopen daardoor onnodig risico op vertraging.

Wat te doen?

Regel het! Bepaal eenduidig aan wie een product owner in jouw organisatie rapporteert. Dat is dan het logische aanspreek/escalatie-punt voor projectmanagers en opdrachtgevers die de prioritering ter discussie willen stellen. In bijvoorbeeld het Scaled Agile Framework (SAFe) vind je handvatten hoe je de besturing kan inrichten.

Zelf vergelijk ik de samenwerking tussen projectmanager en product owner als een soort intern leverancierscontract. Leg een paar afspraken tussen project en product owner vast, bijvoorbeeld dat het op te leveren werk gedurende het benodigde aantal sprints de hoogste prioriteit zal houden. En als je als project sterk afhankelijk bent van een product owner adviseer ik om die product owner op te nemen in je stuurgroep, net zoals je met een belangrijke leverancier kan doen.

Nog een persoonlijke tip: Meet de tevredenheid van de stakeholders

Ook ben ik een groot voorstander van meten en zichtbaar maken. We meten wat klanten van ons vinden, we geven ratings aan leveranciers, scrum teams meten de team-happiness en we vragen bij een sprint-demo wat de product owner van het opgeleverde werk vindt. Mijn tip is om structureel de tevredenheid van alle stakeholders van een product owner te meten, gewoon uitgedrukt in een getal. Onder die stakeholders reken ik ook de projectmanagers die met de product owners samenwerken. Zorg vervolgens voor communicatie van de gemeten resultaten binnen de organisatie.

Uiteindelijk streven we naar een samenspel om de organisatie waar je allemaal voor werkt te laten winnen. Een mooie gedachte toch? Regel dan ook de besturing goed.

Reageren?

Ik ben altijd benieuwd naar reacties van projectmanagers, product owners en porfolio managers, omdat we elkaar op die manier kunnen versterken.