Product owner: Domeinkennis is slechts een pré

‘Een veelvoorkomende situatie: Wanneer een organisatie wil transformeren naar een agile manier van werken, is het redelijk eenvoudig om een scrum team samen te stellen. Ontwikkelaars, testers en business analisten worden bij elkaar gezet en omgedoopt tot scrum team. Eén van de teamleden krijgt de deeltaak van scrum master[1] en vanuit de business wordt de persoon met de meeste domeinkennis naar voren geschoven als product owner. Scrum team compleet!!!

De backlog zal wellicht nog gevuld zijn met backlog items die in het verleden al in detail zijn uitgewerkt en opgepakt kunnen worden in de komende sprint(s). Zodra het team echter aan nieuwere items wil gaan werken, blijkt het detailniveau te hoog te zijn om op te pakken. Niet erg, daar zijn uiteindelijk refinement sessies voor. Helaas heeft de product owner een overvolle agenda en kan niet aanwezig zijn. Het team probeert dan maar op basis van aannames de refinement uit te voeren, om vervolgens de backlog items in te plannen in de volgende sprint. Tijdens die sprint, rijzen er vanwege de aannames veel vragen, maar wederom blijkt de product owner te weinig beschikbaar om alle vragen voldoende te beantwoorden. Tijdens de sprint review, of nog erger, na in productie name, blijkt dat het team de plank volledig heeft mis geslagen en opnieuw kan beginnen. Zie je wel dat Agile niet werkt….

Oké, ik overdrijf in bovenstaande situatieschets misschien wat, maar de kern van het verhaal staat als een paal boven water. Zonder product owner die voldoende beschikbaar is voor een scrum team, is het werken in scrum teams gedoemd te mislukken. Toch wordt in veel organisaties domeinkennis gezien als groter belang dan beschikbaarheid voor een product owner, waardoor meestal iemand met veel domeinkennis wordt aangesteld. Echter zijn dit ook altijd personen met overvolle agenda’s, die daardoor het product ownerschap er ‘maar even bij gaan doen voor een paar uurtjes per week’.

Die paar uurtjes zijn niet voldoende voor de taken van een product owner, dus lijkt de “ideale kandidaat” die bovenstaand beschreven wordt niet geschikt voor de rol. Echter is domeinkennis wel nodig om de taken van een product owner uit te voeren en lijken we te belanden in een vicieuze cirkel.

Dit probleem kan verholpen worden door iemand aan te stellen met voldoende tijd om beschikbaar te zijn voor het scrum team, maar wel met vaardigheden om de daarvoor benodigde informatie te verzamelen en dit op een eenduidige wijze kan delen met het scrum team en andere stakeholders. Die informatie kan gehaald worden bij iemand met veel domeinkennis, uit andere lagen van de organisatie, maar ook zeker van buiten de organisatie (lees: klanten en gebruikers). Daarnaast is het belangrijk om zo snel mogelijk feedback te krijgen op features die ontwikkeld zijn, wellicht zelfs voordat ontwikkeling plaats gaat vinden, om de backlog eventueel bij te sturen. Daar ligt ook een belangrijke rol voor de product owner.

Met de groei van Agile zijn er vele technieken en middelen geïntroduceerd om backlog items te bespreken en te beschrijven, zowel tekstueel als visueel, zodat ze voor het scrum team en voor andere stakeholders op een eenduidige manier te begrijpen zijn. Om maar een paar technieken / termen te noemen die ik veel gebruik; ‘User story mapping, ‘Three amigos’, ‘Sketching’, ‘User Feedback’. Iemand die over dit soort technieken en middelen beschikt kan prima zonder domeinkennis de rol van product owner invullen. De domeinkennis zal de product owner zich te zijner tijd eigen maken, maar kan dit eventueel beperken aangezien hij of zij weet waar informatie vandaan te halen en kan zich daarom richten op de belangrijkste taak, beschikbaar zijn voor het scrum team en stakeholders om de juiste informatie op een eenduidige wijze over te kunnen brengen. Door de rol van product owner op deze manier in te vullen, kan de product owner zowel van binnen als buiten de organisatie ingevuld worden.’

Marc Quirijnen
Ingezet bij Philips HealthCare als product owner in bovenstaande context.

[1] Of dit een deeltaak van een van de developers/testers/analisten moet zijn of een dedicated functie is overigens ook een interessant punt van discussie, maar dit voor deze blog terzijde. Mijn collega René de Leijer schreef daar een interessante blogpost over.

1 antwoord

Trackbacks & Pingbacks

  1. […] elkaar gezet en omgedoopt tot scrum team. Eén van de teamleden krijgt de deeltaak van scrum master[1] en vanuit de business wordt de persoon met de meeste domeinkennis naar voren geschoven als product […]

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

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