Er zijn veel vragen en misverstanden over de verantwoordelijkheid van de product owner. Je hoort en leest bijvoorbeeld vaak dat de product owner verantwoordelijk is voor de requirements. Dat blijkt toch genuanceerder te liggen.
Tijdens het schrijven van de laatste editie van mijn boek Handboek Requirements heb ik de ultieme bron er nog maar eens op nageslagen. In de officiële Scrum guide leggen Ken Schwaber en Jeff Sutherland de verantwoordelijkheid van de product owner als volgt uit:
“De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het ontwikkelteam.
De product owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog. Product Backlog management omvat onder andere:
- Helder omschrijven van product backlog items;
- Ordenen van product backlog items, om doelen en missie op de beste manier te behalen;
- Optimaliseren van de waarde van het werk dat het ontwikkelteam uitvoert;
- Ervoor zorgen dat de product backlog zichtbaar, transparant en duidelijk is voor iedereen, en dat het laat zien waar het scrum team als volgende aan gaat werken; en
- Ervoor zorgen dat het ontwikkelteam de product backlog items begrijpt tot het niveau dat nodig is.
De product owner kan het bovenstaande werk zelf uitvoeren, of het door het ontwikkelteam laten doen. In elk geval blijft de product owner verantwoordelijk.”
Nuancering verantwoordelijkheid product owner
Uit de letterlijke tekst uit de Scrum guide concludeer ik dat de veel gehoorde bewering ‘De product owner is verantwoordelijk voor de requirements’ niet feitelijk onjuist is. Maar het geeft wel een verkeerd beeld van de verantwoordelijkheid van de product owner!
Een product owner is helemaal niet gefocust op requirements, als het goed is. Hij is bezig met het creëren van zoveel mogelijk businesswaarde. Daarvoor probeert hij het systeem dat het ontwikkelteam aan het realiseren is, te optimaliseren.
Helderheid over de requirements is daar belangrijk bij, maar is niet meer dan een hulpmiddel.
Meer hierover lees je in Handboek Requirements. Download hier gratis de uitgebreide preview van Handboek Requirements. Of bestel hier het boek én ontvang als cadeau gratis het e-book ‘Agile Requirements’.
Nicole de Swart
Kleine nuance: De product owner is bezig met het optimaliseren van de bedrijfswaarde door middel van het realiseren van informatievoorziening.
Of daardoor “het systeem” in zichzelf optimaal is weet ik niet zeker. En of het om een “systeem” gaat is in deze tijd ook niet zeker. Het kan ook een verzameling van services zijn. Als een organisatie zoiets als systeem kent, dan kan het realiseren van bedrijfswaarde wel eens betekenen dat de product owner meer dan één systeem laat aanpassen.
Dit is een vreemde gedachtengang. Ik probeer het.
Een organisatie heeft informatie nodig. Requires informatie, dus. Waarom? Simpel: men moet, om de een of andere reden, meer, of beter weten. Wat het is dat men meer moet weten wordt opgeschreven. Als dat goed gebeurd zijn dat de requirements waarmee deze organisatie vertelt wat men hebben wil, nodig heeft. Zij zijn verantwoordelijk voor wat ze opgeschreven hebben.
Als we ervoor kiezen om een product te (laten) maken zouden we ervan overtuigd moeten zijn dat dat product is waar men om gevraagd heeft. De “owner” van dit product is degene die verantwoordelijk is voor wat dit product kan en doet. De product eigenaar is dan ook verantwoording schuldig aan de organisatie die de requirements geschreven heeft, en die daar, zoals gezegd, dus verantwoordelijk voor zijn. Gezien de noodzaak van het scheiden van functies kan een product-owner daarom niet verantwoordelijk zijn voor de requirements.
Dit is gelijk ook de spraakverwarring die steeds rond scrum, agile enz. bestaat. Je kunt immers geen opdracht geven om een of ander product te krijgen voordat je voldoende weet van wat dat product zal moeten zijn, moet inhouden en moet gaan toevoegen. Waarschijnlijk zal/kan de genoemde organisatie niet alle detail in hun requirements verwoorden zodat nadere uitwerking in een, misschien, agile vorm nodig zal zijn. Maar dat laat het bovenstaande onverkort.
Het lastige is dan te weten hoever requirements dienen te gaan, en wanneer men aan een passend “product” gaat werken. Laat me deze vraag met een vraag beantwoorden: hoever zou u gaan tot u uw aannemer werkelijk uw huis laat bouwen? Ik wil zelf meer meegeven dan alleen dat het een bakstenen huis moet zijn, maar zou ik ook de precieze plaats van de stopcontacten vooraf willen vaststellen?
Mijn antwoord is dan feitelijk simpel: ik wil vooraf weten wat ik krijg, waarvoor ik betaal. Een voldoende precieze opdracht voor de aannemer dus. In de praktijk vergeten we dit vaak in de IT.
Ik ga akkoord met Steven, de business moet weten wat die zal krijgen, wat het zal kosten en wanneer het zal klaar zijn. Deze drie dimensies zijn onderling verbonden, je raakt daar niet ongestraft aan. De grote lijnen moeten vast liggen voor Scrum begint, anders loopt het mis, details volgen later.
De stelling dat Agile business waarde oplevert hoor je overal maar is volgens mij fout. IT systemen kosten geld, Scrum laat je toe om je te concentreren op de meest ‘waardevolle’ dingen en reduceert zo de kosten (lees verspilling). Een IT systeem levert nooit zelf waarde op, enkel als de business die goed inzet, ontstaat waarde. Een IT systeem levert het potentieel maar niet de waarde zelf. Bij te weinig potentieel blijven enkel de kosten over (en dat is bij Agile net zo).
Om het met een boutade te stellen: waterval belooft je te leveren wat je vraagt maar je weet niet wanneer of hoeveel het zal kosten. Agile maakt duidelijk wanneer je iets zal krijgen, hoeveel het zal kosten maar wat het zal zijn zal leter blijken.
Requirements zijn niet wat ze vragen maar wat ze nodig hebben (tussen de lijnen lezen is de boodschap), een veelheid aan benaderingen, gezichtspunten en technieken kunnen je helpen. Functionaliteit is maar een deel van het verhaal, het wordt een hinkend systeem. Softwareontwikkeling vraagt 60% van het budget maar levert enkel 30% van de acceptatie. De menselijke factor eist 40% van het budget maar levert 70% van de acceptatie. Functionaliteit is noodzakelijk (zonder geen systeem) maar is niet voldoende.
De PO staat in voor de detaillering, het kader ligt er al.
Leuk zo’n discussie. Bedankt voor jullie reacties.
Steven, het verschil met de huizenbouw is dat daar vrijwel alle specificaties bij aanvang bekend moeten zijn en er tijdens de bouw geen substantiële wijzigingen doorgevoerd kunnen worden. Bij het ontwikkelen van software is dat tegenwoordig veel makkelijker, zeker als het ontwikkelteam de moderne technische practices toepast.
Rik: ‘Agile maakt duidelijk wanneer je iets zal krijgen, hoeveel het zal kosten maar wat het zal zijn zal later blijken.’ Klopt, de business hoeft niet vooraf haar requirements te specificeren. In plaats van vooraf af te spreken wat ze krijgen en hoeveel het kost (waterval), biedt agile aan de business de mogelijkheid om gaandeweg het traject te ontdekken wat voor systeem ze echt nodig heeft. Het grote voordeel hiervan is helaas bij veel organisaties nog niet doorgedrongen.
In agile bepaalt de business zelf wat ze wanneer krijgen en hoeveel budget ze besteden. De business (PO) leidt de zoektocht naar de optimale informatievoorziening (zoals Frans het verwoord) en bepaalt hoe de systeemincrementen zich ontwikkelen. Hierbij is intensieve samenwerking tussen business en IT noodzakelijk. Helaas houden de meeste managers nog vast aan een opdrachtgevers opdrachtnemers relatie, dat in een agile omgeving contraproductief werkt.
Nicole,
Ja, in de bouwwereld moet veel bekend zijn voordat de aannemer er naar gaat kijken. Ik ben met je eens dat in de IT van alles en nog wat aangepast kan worden, maar de ervaring leert dat juist dat aanpassen extreem kost en heel veel ellende brengt. Bovendien: waarom zou zoveel aangepast moeten worden als je organisatie goed weet wat ze wil?
De oplossing is zo simpel (en wordt al jaren verkondigd) dat niemand hem overneemt (niet leuk, lastig enz.): weet voordat je gaat developen/”programmeren” precies wat je hebben wil. Alles, en geverifieerd. Dat voorkomt al die aanpassingen die van “nieuwe” software binnen de kortste keren de grootste ellende maken die nauwelijks beheerbaar is tenzij je er een vermogen aan besteed.
Rond requirements, jouw vak, komen we dan in een soort dubbele situatie terecht. Als de IT-er uiteindelijk een precies ontwerp moet hebben, in hoeverre is een organisatie dan in staat om goed en precies genoeg te vertellen wat ze wil? Dat zal niet tot de precisie kunnen leiden die de developer zou moeten hebben, maar wel zover dat de organisatie, de latere eigenaar, goed genoeg aangeeft wat ze wil. dus een soort 2-stap requirement fase: eerst precies genoeg voor de organisatie, dan de analyse/ontwerp tot de genoemde precisie uitgewerkt is.
Bij het eerste deel gaan IT-ers meestal de mist in, daarvoor zijn specialisten nodig die steeds weer uit de (IT-)markt gegooid worden.
Dit legt ook gelijk de discussie open die tot nu toe alleen door IT gevoerd is: de voordelen van werken volgens Scrum cq. Agile. IT zegt dat het “beginblad” voor hun project feitelijk zo leeg mogelijk moet zijn. Mijn ervaring is dat dat “beginblad” zo vol moet zijn dat de organisatie goed genoeg weet wat zo’n IT-project gaat doen en bereiken. Hoe minder je het laatste doet, zoveel groter is de kans dat je IT-project op de klippen loopt.
Met een vergelijking: vragen wat IT-gebruikers nodig hebben is echt iets anders dan vragen wat informatie eigenaren nodig hebben.
Er zijn blijkbaar nog steeds mensen die in de illusie leven dat opdrachtgevers precies kunnen vertellen wat ze straks nodig hebben. Misschien is dat mogelijk bij kleine, overzichtelijke systemen, maar in de huidige, steeds complexere wereld wordt dat steeds moeilijker, en moet onderweg bijgesteld kunnen worden. Waar denkt men dat de Agile beweging door getriggerd is ? Door mensen die al die regeltjes maar niks vonden, en daar een excuus bij verzonnen hebben om dat niet te hoeven doen ? Natuurlijk moet er een visie zijn, en de eerste stappen moet goed goed over worden nagedacht, maar een half of heel jaar werk vooruit specificeren, levert veel waste op, blijkt maar al te vaak.
Om Paulus verder aan te vullen; zelfs al weet de opdrachtgever precies wat hij wilt, ondanks dat die kans minimaal is, dan duurt een gemiddeld ontwikkeltraject voor een beetje complex systeem jaren. De wereld staat niet stil, de omgeving verandert constant. Het is in het belang van de opdrachtgever dat hij kan bijsturen, zelfs al wordt gedacht dat dat niet nodig zal zijn.