Waarom een Scrum team slechts één Product Owner dient te hebben

scrum-team

“The Product Owner is one person, not a committee.” De Scrum Guide spreekt klare taal over het aantal Product Owners in een Scrum team. Toch komt het in de praktijk nog te vaak voor dat er bij een Scrum project gebruik wordt gemaakt van meerdere Product Owners, met alle negatieve gevolgen van dien. Er kunnen verschillende redenen zijn waarom er met meerdere Product Owners wordt gewerkt. Zo kan het zijn dat de betreffende organisatie totaal geen ervaring heeft met Agile of Scrum en daardoor bij de start van een Scrum project helemaal geen idee heeft wat er zo verkeerd is aan het hebben van meerdere Product Owners. En zelfs wanneer men wel weet dat een Scrum team slechts één Product Owner hoort te hebben, zijn er nog tal van andere praktische bezwaren waar organisaties tegenaan lopen. Tijd om organisaties die aan de slag gaan met de Scrum methodologie te adviseren over deze kwestie aan de hand van een drietal kritische vragen.

De Scrum Guide zegt dat er maar één persoon Product Owner dient te zijn. Maar waarom is het eigenlijk een slecht idee om gebruik te maken van meerdere Product Owners?

Stel dat er met meerdere Product Owners wordt gewerkt in een Scrum team dat zich bezig houdt met de ontwikkeling van een nieuw ERP-systeem. Ieder van deze Product Owners heeft dan een eigen mening over wat hij of zij het belangrijkst vindt. Wellicht vindt de ene Product Owner dat de planfunctionaliteit van het nieuwe ERP-systeem de hoogste prioriteit moet krijgen, terwijl een andere Product Owner van mening is dat de functionaliteit om tijd te registreren juist als eerste ontwikkeld dient te worden. Hoe meer Product Owners er zijn, des te moeilijker het wordt en des te meer tijd het kost om tot een consensus te komen. Daarnaast stijgt ook het risico dat er wordt teruggekomen op al eerder genomen besluiten. Zo kan het zijn dat het ontwikkelteam bijvoorbeeld een blauw loginscherm heeft ontwikkeld omdat dit zo besloten is door een van de Product Owners. Later blijkt dat een andere Product Owner toch vindt dat het scherm rood hoort te zijn en dat het scherm weer aangepast moet worden. Dit soort onnodig rework kan tot grote frustraties bij het ontwikkelteam leiden.

Binnen onze organisatie bestaan meerdere personen die ieder veel kennis hebben over een specifiek onderdeel of een specifieke functionaliteit van het te ontwikkelen product. Er is niet één persoon die over al deze kennis beschikt. Is het in dit geval wel verstandig om met slechts één Product Owner te werken?

Ook in dit geval dient er slechts één persoon Product Owner te zijn. Wie er het best gekozen kan worden als Product Owner hangt van verschillende factoren af. Deze persoon moet in ieder geval in staat zijn om de bedrijfsvisie te begrijpen, de product backlog te onderhouden, duidelijke requirements op te stellen, deze requirements te prioriteren op bedrijfswaarde en te zorgen dat de requirements ook duidelijk zijn voor het ontwikkelteam. Natuurlijk is het handig als deze persoon veel kennis heeft over de onderdelen of functionaliteiten van het te ontwikkelen product, maar wanneer dit niet het geval is, kan dit tekort aan kennis worden opgevangen door een zogenaamd Product Owner comité in het leven te roepen. De personen in dit comité kunnen de Product Owner advies geven over de onderdelen of functionaliteiten van het te ontwikkelen product waar zij veel vanaf weten. De kennis die de Product Owner mist kan hij of zij dus ophalen bij de verschillende comitéleden. Wat de Product Owner doet met de door hen verkregen kennis, mag hij of zij echter helemaal zelf weten. De Product Owner blijft immers degene die de eindverantwoordelijkheid over de product backlog in handen heeft. Hij of zij is degene die beslissingen neemt, niet de comitéleden.

Wat nou als de Product Owner gedurende het project vanwege vakantie, ziekte of een andere reden niet meer in staat is om te werken? Wanneer er slechts één persoon Product Owner is, wordt het lastig om een goede vervanger voor deze persoon te vinden. Dit is een behoorlijk projectrisico. Hoe kan hier het beste mee om worden gegaan?

Dat is inderdaad een van de risico’s die het werken met één persoon als Product Owner met zich mee brengt. Toch is er een manier om dit te voorkomen. Op het moment dat een Scrumteam wordt samengesteld zou niet alleen rekening moeten worden gehouden met wie welke rol gaat invullen, net zo belangrijk is het om na te denken over welke personen als backup kunnen dienen voor de verschillende rollen. Door alvast een persoon aan te stellen als reserve Product Owner wordt er voor gezorgd dat een Product Owner indien nodig gemakkelijk vervangen kan worden. Deze zogenaamde Backup Product Owner maakt geen vast onderdeel uit van het Scrum team en mag geen beslissingen nemen, maar heeft wel korte lijntjes met de echte Product Owner. Door minimaal één keer per week aan kennisoverdracht te doen, wordt de Backup Product Owner op de hoogte gehouden van waar de Product Owner mee bezig is en hoe de product backlog eruit ziet. Komt er een moment waarop de Product Owner verwacht of onverwacht wegvalt, dan kan deze rol direct worden overgenomen door de Backup Product Owner. Vanaf dat moment heeft de nieuwe Product Owner dezelfde verantwoordelijkheden als de vorige Product Owner en is hij of zij degene die bepaalt wat er moet gebeuren. Zodra de echte Product Owner terugkeert neemt ieder weer zijn oude rol in.

scrum-team

Laat een bericht achter

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *