Over de rol van de Product Owner is de Scrum Guide helder. Daarbij zijn er voldoende best practices die de nuances van de rol duidelijk maken. Er is een discussie die volgens ons te weinig gevoerd wordt: van wie komt de PO? Terwijl deze keuze toch echt bepalend is voor het succes van Scrum.
PO van klantzijde
De Product Owner kent de business en de markt, de wensen van de gebruikers, et cetera. Het is dan ook niet meer dan logisch dat de PO iemand is van de klantzijde, al dan niet bijgestaan door een ervaren PO van bureauzijde. Of toch niet helemaal… Op basis van mijn praktijkervaringen zijn er enkele overwegingen die je maar beter meeneemt, als je voor de keuze staat tussen een klantzijde PO of een PO aan bureauzijde.
- Als de uitdaging niet zozeer op productniveau ligt maar vooral op procesniveau (bijvoorbeeld door de complexiteit van meerdere kleine projecten tegelijk) geniet de PO aan bureauzijde altijd de voorkeur. De procesverantwoordelijkheid hoort niet bij de klant te liggen;
- Door het maakproces volledig bij bureau te leggen, is er nooit discussie over procesverantwoordelijkheid;
- Agile kent geen hiërarchie maar die gelijkwaardigheid loopt gevaar als de PO van de organisatie komt die ook de facturen betaalt;
- De PO-rol is onderdeel van het scrum team – en deelnemer aan retrospective – maar teamleden zullen zich minder snel uitspreken als de klant erbij is. Vertrouwen is de basis van Scrum;
- De klant kent het product het beste maar lijdt ook snel aan tunnelvisie. Hij weet het wel waardoor ook de gebruiker vaak buiten beeld blijft. Een krachtige PO is meester in de wisselwerking tussen divergeren en convergeren, in het oplossen van het juiste probleem. Juist daarom is bij de Design Thinking brief het probleem dat de klant ziet (en de eventuele oplossingsrichting) slechts een van de frames;
- De PO vertegenwoordigt de stakeholders, inclusief de klant. Een PO aan klantzijde kent een historie en heeft niet altijd volledig draagvlak in de eigen organisatie;
- Een PO aan bureauzijde is bekend met de cultuur van het ontwikkelteam en zal hiermee een culturele match hebben.
- De PO aan klantzijde zal onder druk van de deadline en/of tegenvallende resultaten al snel de opdrachtgevers-pet opzetten (de betaler bepaalt);
- De organisatie van de PO aan klantzijde werkt niet altijd volgens de mindset – zeker in traditionele sectoren wordt er ook bij innovatie nog volop ‘waterval’ gewerkt – en is niet altijd bekend met Scrum. Hiermee loop je de kans dat de PO zijn/haar rol invult als klassiek projectleider of -manager;
- De PO beschermt het development team tegen de klant, zodat zij gefocust kunnen werken aan de productwensen die in de sprint zijn gesleept. Die rol is lastig als je zelf de klant bent;
- Een PO is dedicated beschikbaar voor het ontwikkelteam en zit op de Agile ‘Individuals & interactions’ afstand. Dat is niet altijd haalbaar voor de klantzijde PO;
- De PO-rol leer je door vlieguren te maken. Dedication en focus op de rol. Dit spreekt in het voordeel van de PO aan bureauzijde.
N.B. In het interdisciplinaire team (waar LSD fan van is, zeker voor design thinking teams) is de klant wel vertegenwoordigt, maar als gelijkwaardig lid van het ontwikkelteam en niet in de rol van projectmanager of product owner.