Het is doorgaans nog best lastig. De hele organisatie op Agile en/of Scrum cursus geweest, iedereen van goede wil, allemaal gemotiveerd om lekker Agile aan de slag te gaan – maar waar halen we de juiste en capabele product-owner (PO) vandaan? Het zal ongetwijfeld ook morgenavond bij de Agile/Scrum masterclass die ik geef weer een punt van heftige discussie zijn.
In veel organisaties is het een pijnpunt en te vaak is de PO rol hetzelfde lot toebedeeld als de stuurgroep uit de Prince2 methodiek – we hebben ‘m, maar of ze weten niet precies wat er van ze verwacht wordt of ze hebben er geen tijd voor. Over die Prince2 stuurgroep ga ik nu even niks roepen maar in het geval van de PO ontstaat dat probleem vaak door een veelvoorkomend misverstand over de rol van die product owner.
Ik trapte zelf een paar weken geleden ook bijna weer in die valkuil rond de rol van product owner. Er is een belangrijk misverstand waarom veel organisaties moeite hebben met het vinden van een goed functionerende product-owner. Die PO moet immers in staat zijn razendsnel prioriteiten te stellen en beslissingen te nemen om te voorkomen dat het team stil komt te liggen. En moet ook nog eens voldoende mandaat en draagkracht vanuit de organisatie hebben om dat met vertrouwen te kunnen doen? Maar is dat wel zo?
Als je van die combinatie uitgaat wordt het inderdaad erg lastig, wellicht bijna onmogelijk om een goede PO te vinden. Zeker bij de wat grotere projecten. Immers – (1) snel, de juiste beslissing kunnen nemen over voor het team blokkerende issues vereist een zekere inhoudelijk kennis. Problemen waardoor het team dreigt stil te komen zitten gedurende een sprint betreffen immers meestal detail problemen. Daarnaast – en dat betreft vaak juist de grotere, globalere problemen rond de prioritering op de backlog – moet de PO dus (2) mandaat hebben (lees: hoog genoeg in de organisatie zitten) om te mogen besluiten over geld en prioriteit. Niks ten nadele van al die ongetwijfeld fantastische product-owners, maar die combinatie – van inhoudelijke kennis/ervaring en bevoegdheden – is doorgaans erg zeldzaam.
Waarom gaat dit dan mis? Welk misverstand ligt hieraan ten grondslag? Het gaat om het eerste punt – in feite de aanname dat de PO uiteindelijk diegene is die alles beslist binnen het project. Dat is pertinent niet waar – maar mede doordat (overigens terecht) in het diverse studiemateriaal, leesvoer en bij de verschillende cursussen het belang van de product-owner flink benadrukt wordt (ik doe dat zelf ook) kan onterecht dat beeld wel ontstaan. Bedenk daarbij dat dat gecombineerd gaat met relatief weinig aandacht die doorgaans wordt besteed aan de rol of de mensen die wel die detail-besluiten zouden moeten nemen en de mythe van fabeltastische PO is geboren.
Het is echter heel logisch – de detail besluiten moeten genomen worden door de mensen waarvoor de software gemaakt wordt. De stakeholders, of – veel beter nog – de uiteindelijk daadwerkelijke eindgebruikers van de software. Vooral in grote organisatie wordt dat belang nog wel eens uit het oog verloren – de uiteindelijke gebruiker zit ver weg van het projectteam en wordt (in de meest absurde gevallen) vertegenwoordigt door 4 lagen van senior-, key-, business-users en/of een demand organisatie. Het is niet specifiek voor Agile werken – het is eigenlijk gewoon gezond verstand maar de uiteindelijke gebruiker van het onderhanden stukje functionaliteit moet de beslissingen nemen… en toch werkt het lang niet altijd zo. Het is echter wel essentieel voor het effectief zijn van een Agile aanpak binnen een organisatie.
Natuurlijk is het voor een team (relatief) makkelijk om de issues buiten het development team te leggen en de PO met deze onmogelijke taak op te zadelen – maar eigenlijk zouden we zonder directe beschikbaarheid en inzet van de uiteindelijke gebruikers; de echte stakeholders niet eens moeten willen starten met een project. Betrokkenheid van gebruikers – door veel aanwezig te zijn, aanspreekbaar en bereikbaar te zijn voor het development team; maar dan ook een team wat niet bang mag zijn om die communicatie aan te gaan – is essentieel voor het succes van het project. Om maar eens een dooddoener te noemen om dit stukje mee af te sluiten.
Oja… natuurlijk is het afhankelijk van het onderhanden werk welke gebruikers je bij welke sprint vraagt – dat hoeven en kunnen vaak niet gedurende het hele project dezelfde gebruikers te zijn (tsss – ze zitten tenslotte niet in het development team ;))
Precies deze problematiek werd behandeld bij een Product Owner training (Zilverline) die ik recent volgde. Daar werd het onderscheid gemaakt tussen wat en hoe. De Product Owner is verantwoordelijk voor het wat, het team doet het hoe. Als het team iets besluit wat verkeerd blijkt uit te pakken, gaat er hooguit een sprint verloren en heeft het team wat geleerd. Zie jij dat ook zo?
Hoi Bart – het onderscheid tussen Wat en Hoe is inderdaad een veel gebruikt en een prima startpunt. Het levert niet helemaal een oplossing voor een Product Owner die teveel met detail vragen lastig wordt gevallen maar maakt wel heel mooi duidelijk welke verantwoordelijkheid het devteam heeft… los daarvan – kennis hebben van en het betrekken van de uiteindelijke gebruikers blijft essentieel.