We hebben te weinig werk voor een fulltime Product Owner. Wat maakt het nou uit dat de rol gecombineerd wordt met een andere rol in een persoon? We hebben Bill en die weet wel een beetje van Scrum. Of Fred de CTO kent het product het beste laten we hem Product Owner maken. Of misschien wel Anton de Manager; hij kent de stakeholders het beste.
Uitspraken van bedrijven die pas beginnen met Scrum? Helaas hoeft dat zeker niet het geval te zijn. Oké, bedrijven die met Scrum willen beginnen, hebben vaak nog maar weinig kennis van en zeker ook weinig ervaring met Scrum. Ze kunnen makkelijk redeneren dat het niet altijd nodig is de Scrum Guide zo strikt te volgen. Je mag het per slot van rekening toch aan jouw situatie aanpassen?!
Het is waar, Scrum is als een lightweight framework wat betekent dat je makkelijk dingen kunt toevoegen of kleine aanpassingen kan maken zodat het beter past. Wat je echter niet mag vergeten terwijl je die wijzigingen overweegt, is dat er heel goed is nagedacht en al meer dan 20 jaar gebruik gemaakt wordt van Scrum in de praktijk. De gebeurtenissen (events), artefacten en dus ook de rollen met bijkomende verantwoordelijkheden en scheidingen, zijn er niet voor niks. Dus vooral als je net begint, denk niet dat je het beter weet en blijf binnen het framework zoals het beschreven staat.
Product Owner volgens Scrum Guide
Laten we eerst dus kijken wat de Scrum Guide zegt over de rol van Product Owner. De Product Owner is - naast Scrum Master en developers - volgens de Scrum Guide een duidelijk apart beschreven rol. De Product Owner is één persoon, niet meerdere of een comité. Wat houdt de rol van de Product Owner verder in volgens de Scrum Guide? Hij is verantwoordelijk voor het maximaliseren van de waarde van het product, dat het resultaat is van het werk van het Scrum Team. Hoe dit wordt gedaan, kan sterk uiteenlopen tussen organisaties, Scrum Teams en individuen. De Product Owner is ook verantwoordelijk voor effectief Product Backlog-management, wat het volgende omvat:
- Het ontwikkelen en duidelijk overbrengen van het Product-Doel
- Het creëren en helder overbrengen van Product Backlog-items
- Het ordenen van Product Backlog-items gebaseerd op de prioriteiten van alle stakeholders samen
- Het ervoor zorgen dat de Product Backlog transparant en zichtbaar is en begrepen wordt
Om de Product Owner succesvol te kunnen laten zijn, moet de gehele organisatie hun beslissingen respecteren. Hij moet minimaal een bepaalde mate van mandaat hebben. De Product Owner kan de behoeften van vele belanghebbenden vertegenwoordigen in de Product Backlog. Zij die de Product Backlog willen veranderen, kunnen dat doen door te proberen de Product Owner te overtuigen. Dat betekent dus ook dat hij niet overruled of verordend moet worden. Het blijft daarmee de verantwoordelijkheid van de Product Owner.
Voor- en tegens voor het combineren van de rol van Product Owner.
Over twee artikelen verdeeld, ga ik in op de voors en tegens van het combineren van de rol van Product Owner met verschillende andere rollen. Door een aantal voorbeeldsituaties die op z’n minst geïnspireerd zijn door de praktijk, zullen we deze voors en tegens ondersteunen en verduidelijken.
Voor we naar de mogelijke combinatierollen gaan, wil ik jullie vragen om bij elke beschrijving in gedachte te houden dat Scrum is gebouwd op een aantal waarden: openheid, respect, commitment, focus, moed. Dat gezegd hebbende, in alle gevallen geldt het logische voordeel dat er geen extra medewerker nodig is voor het invullen van de rol. Dat scheelt natuurlijk 1FTE aan loonkosten. Vooral voor kleine teams en kleinere bedrijven is dit een groot voordeel.
Dus nu over naar de Product Owner rol...
... gecombineerd met Scrum Master
Wanneer bedrijven uit een niet-agile manier van werken overstappen naar Scrum, hebben ze mogelijk een productmanager. Zij hebben veel vaardigheden die in Scrum zijn verdeeld over de verschillende rollen. Het kan dus goed zijn dat de productmanager de meest geschikte persoon lijkt voor zowel de PO-rol als de rol van Scrum Master. Daarmee kun je natuurlijk sneller schakelen omdat je dan niet met een ander persoon hoeft te overleggen. Je kunt je echter ook voorstellen dat het geen goed idee is om degene die het team bewaakt tegen te veel werk en inbreuk op de Sprints en degene die denkt vanuit de belangen van het product en de Stakeholders en dus mogelijk meer werk wilt toevoegen, in een persoon te combineren.
Ik ga dieper in op deze combinatie in deel 3 en 4 van deze serie over de combinatierollen voor Scrum. Je kunt die hier vinden en lezen: Deel 3: Scrum-rollen combineren: Scrum Master en Deel 4: Scrum-rollen combineren: Scrum Master
.… gecombineerd met rol van teamlead, manager of C-rollen
Ook hier is het voordeel dat deze personen vaak in hun positie een aantal van de benodigde vaardigheden bezitten die handig zijn als Product Owner. Vooral als de persoon heel erg business georiënteerd is, kan die instelling goed zijn voor de ontwikkeling van het product.
We moeten echter realistisch zijn en moeten onszelf dan afvragen of de manager de tijd kan vrijmaken om zijn taken als Product Owner goed uit te voeren. We mogen niet onderschatten hoeveel tijd en aandacht stakeholder-management vereist. Het voldoende bijhouden van de Product Backlog om deze helder te hebben voor het team waardoor zij vooruit kunnen. Beide rollen zijn fulltimebanen. Het is, zeker vanuit Scrum, niet de bedoeling om 80 uur per week te moeten werken. In de praktijk blijkt daarom ook dat de leidinggevende rollen vaak niet voldoende aandacht kunnen besteden aan bovengenoemde taken waardoor de meerwaarde van Scrum in het algemeen sterk verminderd. Wat de precieze vermindering is, is uiteraard afhankelijk van de ernst van de situatie. Wat ik hieronder beschrijf kan overdreven lijken maar zijn serieuze risico’s die je loopt wanneer er niet genoeg tijd besteed kan worden aan de taken van de Product Owner.
Stakeholdermanagement: een van de belangrijkste taken van de PO is de stakeholders op de hoogte houden en met hen kijken wat de wensen zijn en welke prioriteit deze hebben ten opzichte van de eisen van andere stakeholders. Wanneer hieraan te weinig tijd besteed wordt, voelen de stakeholders zich niet op de hoogte gehouden, worden zij onrustig, voelen zich niet geïnformeerd, worden ze minder flexibel in het prioriteren van de wensen van andere stakeholders en dus zijn ze lastiger te managen. Het kost daarna dus veel meer tijd om hen weer tevreden te krijgen en de band met hen te herstellen. Als ook daarvoor niet genoeg tijd is, kun je je voorstellen dat stakeholders op een gegeven moment niet meer met je willen samenwerken en op zoek gaan naar andere partijen.
Product Backlog-management: onvoldoende uitgewerkte en onduidelijke user stories, kosten meer tijd in refinement of planning. Men zal op dat moment nog moeten kijken wat bedoeld wordt en of alle benodigde informatie aanwezig is. In het beste geval is de Product Owner dan wel aanwezig bij deze vergaderingen en kan hij hopelijk verduidelijking geven – ervan uitgaande dat hij in ieder geval wel weet wat de stakeholder wilde of bedoelde. Het kan namelijk ook zo zijn dat hij daar ook geen tijd voor heeft gehad en eigenlijk niet goed weet wat de stakeholders nou precies wilden of bedoelden met de story. Als hij helemaal niet aanwezig is, kunnen de teamleden de story dus niet inschatten en niet oppakken. Laten we in dat geval hopen dat andere stories wel duidelijk genoeg zijn, anders komt het team stil te liggen, wordt de doorlooptijd van het project meer, komen afspraken rondom budget en kwaliteit in gedrang. Nog een gevolg van meer tijd nodig hebben om stories duidelijk te krijgen, is dat er daardoor meer tijd voor de vergaderingen nodig is en dus minder ontwikkeltijd overblijft. De velocity wordt minder, de planning en het budget voor het project komen ook hierdoor extra onder druk te staan. Vaak zijn managers dan geneigd om te zeggen dat er dan maar minder tijd besteedt moet worden aan de onderdelen; ‘haal de tests maar weg’, ‘doe het maar even wat minder netjes’, ‘laat de documentatie maar zitten’, enz. De kwaliteit van het product wordt snel minder en technical debt wordt heel snel opgebouwd. Die zal ooit terugkomen en geïnd willen worden. Verder is de kans dat iets gemaakt wordt dat niet het belangrijkste was of niet zoals de stakeholder het bedoeld had, veel groter, weggegooide tijd en dus geld. Als er daarna opnieuw begonnen moet worden is dat ontmoedigend voor het team. Blijft deze situatie lang genoeg zo, dan gaan de goede teamleden op zoek naar een andere baan en zul je waardevolle kennis verliezen.
Een ander gevaar is de ongewenste situatie dat het team zich niet openlijk kan uiten. Denk hierbij aan Retrospectives. Het team kan zich minder op hun gemak voelen of zelfs onveilig om te uiten wat er echt speelt, de onvrede over proces of organisatorische punten blijven onuitgesproken. De manager zit erbij en dit zou tot gevolg kunnen hebben dat het team de onvrede niet uit vanwege de mogelijke implicaties voor je beoordeling in functioneren of zelfs je baan. Ondanks dat hij onderdeel is van het team en hij officieel in de rol van de Product Owner aanwezig is, is het onmogelijk om deze rollen volledig te scheiden als het gecombineerd wordt in een persoon. Dit kan de manager ook niet zelf bepalen. Hij kan niet zeggen ‘ik kan dat prima gescheiden houden’. Dat mag hij vinden, maar wat vindt het team?
Het niet durven uiten, zal ook terugkomen in Refinements en planningsmeetings. Wat als de Manager-PO zegt: ‘Dit moet in minder tijd, de stakeholder wordt zenuwachtig’? Wat doet een team dan? Zijn ze sterk genoeg, of volgens de Scrum waarde moedig genoeg om daar toch vast te houden aan hun eigen inschatting? Ook hier blijkt dat de dubbelrol van de Manager-PO er dan vrijwel elke keer voor zorgt dat het team voorzichtig is met hun uitingen en meestal meegaat met de uitspraak van de manager. Vooral wanneer de manager technische achtergrond heeft, kan het zijn dat hij die druk opvoert op het team of zelfs overruled en het team een urenschatting oplegt. Dit ondermijnt de waarden van respect en het zien dat het team de professionals zijn in hun vakgebied en bepalen hoeveel tijd zij nodig hebben om hun hoge standaarden te kunnen garanderen. Ook hier ga je goede werkers met waardevolle kennis verliezen. Een ander bijkomend gevaar is nog dat door de krappe tijdsinschatting de sprint niet gehaald wordt. De gemaakte commitment is niet gehaald en het team moet zich verantwoorden in de Review. Gaat het team en vooral de manager-PO open en eerlijk zijn over de verantwoordelijkheid van de inschatting? Zo niet heeft dit een negatieve impact op de moraal van het team. Zij zijn namelijk gedwongen in een bepaalde tijd werk te leveren, terwijl ze al zeiden dat het onmogelijk was. Toch worden zij er nu op aangekeken. Ook voor de PO betekent dit extra werk aangezien hij de stakeholders nu weer extra moet gaan managen en tevreden moet houden.
Het is makkelijk voor het team om zich te verstoppen achter de keuzes van de manager. Meestal hebben professionals echter een heel zelfstandige houding en kunnen zij zelfstandig (technische) beslissingen maken en willen zij dat ook om zo hun beste werk af te leveren zodat zij daar ook trots op zijn en zich betrokken en verantwoordelijk voelen. Als er steeds een manager aanwezig is die de eindverantwoordelijkheid draagt, voelt het team zich hoogstwaarschijnlijk minder geneigd om zelf eigenaar te zijn van hun werk. Het team kan dus nooit groeien naar een zelfsturend en zelf-organiserend team. Het team raakt steeds meer ontevreden en zal op zoek gaan naar een andere baan. Weer loop je dus het risico op verlies van professional met jaren aan waardevolle kennis.
Samenvattend
Tot nu toe hebben we gezien wat de taken van een Product Owner zijn en of de rol van PO gecombineerd moet worden met teamlead, managers of C-rollen. We hebben gezien dat het zeker niet verstandig is de rollen te combineren. Zoals we gezien hebben, hebben zowel de Product Owner als de andere rollen veel verantwoordelijkheden. Sommige overlappen, maar vooral sommige bijten elkaar. Zelfs met de redenering dat iemand die rollen goed weet te scheiden, blijkt dit in de praktijk altijd tegen je te werken in openheid, respect en moed vanuit het team naar de PO maar ook vanuit de openheid, focus en commitment vanuit zijn rol als PO. Daarnaast zou het betekenen dat twee of meerdere fulltimebanen door een persoon gedaan worden, wat logischerwijs altijd resulteert in werk dat blijft liggen of van mindere kwalitatief is.
In deel 2 ga ik onder andere verder in op de combinaties van PO en stakeholder of Product Manager. Wil je ondertussen meer weten over Scrum of de rol van Product Owner in Scrum meld je dan aan voor een van mijn workshops.