Tagcloud

Proxy Product Owner – Doe maar niet!

Een Product Owner kun je beschouwen als ‘directeur’ van een product. Een directeur wordt verantwoordelijk geacht voor de kosten en baten van zijn investeringen en legt verantwoording af aan belanghebbenden. Daarnaast managet hij de organisatie om de doelstellingen van de onderneming te bereiken. En dat we deze verantwoordelijkheid niet delegeren aan een plaatsvervanger, vinden we dan ook meer dan logisch. En gek genoeg zien we kennelijk geen kwaad in een proxy Product Owner. Wat maakt dat deze constructie in de praktijk ontstaat? En belangrijker, waarom werkt het contraproductief? Is er een alternatief op een volwaardige Product Owner?

Waarom er Proxy Product Owners zijn

Werkdruk maakt opdeling van de rol.
Een van de taken van een Product Owner is dat de verschillende, potentieel tegenstrijdige belangen van stakeholders goed gemanaged worden. Met name in  een projectomgeving met meerdere stakeholders vergt dit een substantiële inspanning. Dit kan ten koste gaan van de tijd die de Product Owner nodig heeft in het Scrum Team. Als gevolg gaat het team op basis van eigen inzichten werken aan wat zij belangrijk achten. De Product Onwer zit dan niet meer op de bestuurdersstoel van het proces. De verantwoordelijkheid wordt gedelegeerd aan het team. In zulke situaties ontstaat vaak een proxy PO en wordt het gat gedicht door bijvoorbeeld een projectmanager of business analist. De echte PO richt zich op de stakeholders, en de dagelijkse interactie met de rest van het Scrum Team wordt overgelaten aan de proxy.

PO werkt op afstand van het team.
Een van de agile basis principes van Agile stelt dat mondelinge communicatie het meest effectief is. Het ligt dan ook voor de hand dat het volledige Scrum Team op dezelfde geografische locatie samen werkt. In praktijk is de Product Owner niet voordurend ter plekke. Variërend van zelfde gebouw maar verschillende kamers, tot gescheiden door continenten en tijdzones. Om dit te ondervangen lijkt het aantrekkelijk om een proxy aan te stellen voor de dagelijkse samenwerking met het ontwikkelteam.

Product managers willen niet te veel met de voeten in de klei staan.
In een productenorganisatie is er een belangrijke rol weggelegd voor de Product Manager. Deze is verantwoordelijk voor het definiëren van een strategie voor de lange termijn en het beschrijven van de details in een product roadmap. Deze roadmap en visie vormen de input voor verdere ontwikkeling. Tot zover geen verschil met de Product Owner rol in Scrum. De mate waarin ze met de voeten in de klei staan, en hoe ze invulling geven aan het begrip ‘managen’ bepalen hun rol en betrokkenheid bij het realiseren van een product. Bij de  introductie van Scrum zullen ze zich de herkenbare eigenschappen van een Product Owner toe-eigenen en  aansturen op een business- of productanalist als proxy.  Ze denken dat de Product Owner synoniem staat voor specs schrijven.

SINO, Scrum In Name Only
Bij de introductie van Scrum is het van essentieel belang te beseffen dat het een coherent framework is en geen keuzemenu. Belangrijk advies; probeer het uit zoals het bedoeld is. Helaas gaan startende teams vaak al bij de start op zoek naar mogelijkheden om oude gewoontes een nieuwe plek te geven en maken ze een selectie uit de aanpak. Hoe vaak horen we niet:  ”We doen naar buiten toe waterval  en gaan intern scrummen!”  en een proxy is daarmee een feit.

Klant heeft geen tijd.
Veel klanten leven nog steeds in de veronderstelling dat ze bij projectstart hun wensen en eisen wel kunnen overbrengen en aan het eind van rit het projectresultaat wel komen ophalen. “We hebben geen tijd voor dit project”, is een van de veel gehoorde uitpraken. Hoezo geen tijd? Voor een project dat kennelijke een bepaalde bedrijfsdoelstelling moet ondersteunen? Voor een project waarin flink wordt geïnvesteerd? Bedrijven die “scrummen om het scrummen” slagen er blijkbaar niet in de juiste voorwaarden te scheppen en het belang te communiceren. De oplossing is wederom ‘intern scrummen’.

Product Owner als nevenactiviteit.
In de beginfase van de adoptie van Scrum  is de Product Owner vaak geen full time functie. Er wordt gevraagd dit naast een reguliere functie op te pakken. Zodra ze merken dat ze deze rol niet effectief op kunnen pakken wordt er al gauw gezocht naar een proxy in plaats van te kijken naar de oorzaak van het falen en de rol goed op de kaart te zetten.

Waarom werkt een proxy Product Owner niet?

  • In trainingen refereer ik vaak aan een spelletje dat we allemaal speelden op de kleuterschool; in een kring een verhaal fluisterend in het oor doorvertellen. Dikke pret als het oorspronkelijke verhaal een eigen leven is gaan leiden. Het behoeft geen toelichting dat de directe informatievoorziening van de Product Owner aan het team eronder lijdt bij het gebruik van een proxy.
  • Door het instellen van een proxy voelt de echte Product Owner zich minder verantwoordelijk voor het resultaat.
  • Zelfs als je een Proxy Product Owner het mandaat geeft om beslissingen te nemen namens de échte Product Owner en je de proxy verantwoordelijk houdt voor zijn beslissingen, creëer je geen oplossing. Zo lang de proxy niet zelf kan beslissen over de koers van het product is het mandaat en de verantwoordelijkheid in het geding. Daarnaast zal een proxy ultiem de verantwoordelijkheid toch afschuiven naar de echte Product Owner!
  • Het leidt tot het terugvallen in ‘waterval’-gedrag. Immers met het uithollen van de Product Owner-rol en het creëren van een soort ‘Proxy Product Owner/Business Analist’-rol ontstaat er een tussenpersoon tussen de ontwikkelaars en de persoon verantwoordelijk voor het eindproduct. Was dit nu niet wat we van een gefaseerde aanpak geleerd hadden?
  • De kern van de rol van Product Onwer is waarde te maximaliseren. De Product Owner werkt daarom samen met het ontwikkelteam om te verzekeren dat de klant het maximale rendement uit zijn investering haalt. Het creëren en onderhouden van een Product Backlog is hier slechts een onderdeel van de rol. Om het product te kunnen managen moet de Product Onwer samen met het team werken om de maximale resultaten te boeken. Dit werk is té belangrijk om te delegeren.
  • Beginnende Product Owners hebben zich het belang van de rol vaak nog niet goed eigen gemaakt en beseffen niet dat deze rol cruciaal is voor het slagen van het project. Dat kan een gebrek zijn aan goede training, maar het kan ook een stukje eigenwijsheid, naïviteit of een gebrek aan zelfontwikkeling zijn. Een Product Owner moet beseffen dat deze rol niet iets dat je er ‘en passant’ bij doet. Dit heeft zijn weerslag op commitment en verantwoordelijk. Immers stel dat het Product Ownerschap je primaire job is en je baan en carrière afhangen van een zo goed mogelijke invulling van deze rol, dan is het toch niet voor te stellen dat je deze verantwoordelijkheden zou overlaten aan een proxy?

Is er een alternatief?

Voor het invullen van de rol van Product Owner wordt vaak gezocht naar het schaap met vijf poten. En zeker in de context waar softwaretoeleveranciers kan een lastige opgave zijn een geschikte kandidaat te betrekken in organisatie van je klant. In geval van nieuwe klanten een blijvende uitdaging. Bovendien vergt elke nieuwe Product Owner inwerktijd. Dit neemt niet weg dat het nog steeds noodzakelijk is de rol van Product Owner volwaardig in te richten. Mike Cottmeyer beschrijft in zijn blog het concept van een Product Owner Team. Het idee is om de verschillende ‘poten van het schaap’ te beleggen bij verschillende personen, zonder terug te vallen op delegeren. Lees het artikel om een idee te krijgen wanneer zijn oplossing geschikt en werkbaar is.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution