‘Business Value’ is een belangrijk begrip in Scrum. En niet ten onrechte. In PRINCE2 is het ook een belangrijke pijler onder de methode, maar daar heet het de Business Case: de zakelijke rechtvaardiging. Het mooie, vind ik, van Scrum is dat er nu ook een duidelijk rol aan wordt gekoppeld, namelijk die van een Product Owner.
Maar is er wel 1 Product Owner aan te wijzen? Is een product of service in een bedrijf niet het kindje van velen? De eigenschappen van een product, vooral de niet-functionele, zijn slechts indirect aan hard ‘Business Value’ te koppelen. Ik denk daarbij aan Security eisen, Architectuur eisen, Compliance eisen, en zo kunnen we nog wel even door gaan.
Hoe bewaken we nu dat er een juiste balans is tussen productfocus, op functionele eisen met ‘Business Value’ enerzijds, en focus op de niet (direct) functionele eisen. Volgens Scrum is dat gewoon even iets dat de Product Owner moet doen. Mooi gezegd en lastig gedaan. De Product Owner krijgt zo wel heel veel op haar (of zijn) bordje.
Een oplossing is het regisseren van belangen onderbrengen bij een onafhankelijke en objectieve rol. Die rol bestaat nu nog niet in Scrum, en ook niet in PRINCE2. Hoewel, in PRINCE2 is er Project Assurance. Maar in de praktijk wordt dat meer ingevuld als procesborging. En wordt vandaar uit getoetst of de Project Manager wel goed aan stakeholdermanagement doet. In Scrum is dit 'gewoon' de taak van de Product Owner.
Ik pleit voor het benoemen van de rol 'QualityDirector', of in het Nederlands: 'Kwaliteitsregisseur'. Iemand die de balans bewaakt tussen de realisatie van directe ‘Business Value’ (de belangen van de Product Owner) en die van de realisatie van de niet-functionele eisen (de belangen van het hele bedrijf).
Dit soort denkwijze zijn dus funest voor scrum. Hoe meer verschillende rollen en verantwoordelijkheden je boven op een scrum team gaat zetten, hoe fouter het gaat.
ReplyDeleteJe gaat volledig voorbij aan het aller belangrijkste element van scrum, namelijk het maken van kleine stapjes.
Het voordeel hiervan is dat het risico van fouten heel klein wordt. Fouten worden gemaakt, ook door de product owner, maar door elke 2 of 3 weken op te leveren zijn die ook heel eenvoudig te corrigeren. Vergeet ook niet dat je meer leert van fouten maken, dan van fouten voorkomen.
Het gene wat je hierboven voorstelt resulteert in een board achtige situatie, waarbij problemen blijven liggen tot een volgende vergadering en een team door besluiteloosheid gepacificeerd wordt. Heb het lef om de verantwoordelijkheid bij die ene product owner neer te leggen, en zorg voor een omgeving waar fouten niet meteen kapitaal zijn. Dat leidt tot agility.
Bedankt voor je reactie.
DeleteEn je hebt helemaal gelijk: een stuurgroep boven, of in plaats van, een Product Owner is geen goed plan. Gelukkig heb ik dat ook niet voorgesteld.
Wel blijf ik erbij (ook na twee jaar) dat *alle* belangen vertegenwoordigen een helse klus is voor een Product Ownwer. En dat enige ondersteuning, door een coach of kwaliteitsregisseur, geen slecht plan is.