1

Product owner

powerProduct owner

power

DE 9 VALKUILEN VAN DE PRODUCT OWNER

2

ALLES ZELFWILLEN DOEN

INHOUDSOPAVE:

DE PRODUCT OWNER-ROL ERBIJ DOEN

WAARDE VAN HET RESULTAAT

VERGETEN

GEEN PRODUCT BACKLOG HEBBEN

VERBETERING UITSTELLEN

OP ALLES ‘JA’ ZEGGEN

FEEDBACK UITSTELLEN

PROJECTLEIDER SPELEN

13 4

2

MANDAAT VERONDERSTELLEN56

89

7Het rapportDit rapport is ontstaan omdat Product Owners vaak tegen dezelfde impediments oplopen. De meest voorkomende zijn vertaald naar “De 9 valkuilen van een Product Owner”. Om te ontdekken waar de gemiddelde Product Owner staat, binnen deze valkuilen, hebben wij een onderzoek gestart. Dankzij een survey en een Product Owner Power event, hebben wij data bij Product Owners gehaald en in dit rapport verwerkt. Samen met een toelichting over de valkuilen en tips, kun jij deze valkuilen omzetten in Product Owner power!

De rol van de Product OwnerBewust zijn van je interne en externe omgeving en inspelen op veranderingen wordt steeds belangrijker. Als bedrijf is het belangrijk om je bezig te houden met ‘sense and respond’ in plaats van ‘plannen en voorspellen’. Inspringen op veranderende eisen en nauwe samenwerking met de klant is cruciaal, en Scrum is de ideale eerste stap om dit op een wendbare (Agile) manier te doen. Veel gehoorde voordelen zijn: snelle feedback, kortere time-to-market, lagere kosten en gefocust opleveren van werkende en geteste producten. Wie wil dat niet? Helaas heeft ons vakgebied een historie van ‘silver bullets’: die alle problemen als sneeuw voor de zon doen verdwijnen. Er zitten ook haken en ogen aan Scrum. Een belangrijk knelpunt is: de Product Owner. Vaak wordt verondersteld dat de ideeën en de visie van de Product Owner er gewoon ‘zijn’. Alle ideeën zijn bovendien wonderbaarlijk automatisch geordend. Daarnaast heeft de Product Owner alle ruimte om moeilijke keuzes te maken en gaan alle belanghebbenden hier altijd instemmend en eensgezind in mee. Helaas is de realiteit anders. Het is niet eerlijk om te doen alsof de Product Owner een alleskunner is. Het managen van belanghebbenden, het

inspirerend overdragen van een visie, het helpen bij technische keuzes: er zijn maar weinig Product Owners die dat allemaal beheersen. Product Owner zijn is moeilijk. Punt. Het is dan ook niet vreemd dat velen in de valkuilen stappen die bij deze rol horen.

De dode hoek van ScrumEen Product Owner moet perfecte oplossingen bedenken voor nog niet ontdekte problemen. Maar de Product Owner is bepaald geen alleskunner. Er is geen Product Owner die niet worstelt met het vertalen van het werk naar een roadmap en work items. Immers, je kunt niet in de toekomst kijken. Tegelijkertijd wordt wel van hem verwacht dat hij perfecte oplossingen bedenkt voor nog onontdekte problemen. Scrum zegt hier niets over. Scrum stelt dat er een Product Owner moet zijn en dat hij verantwoordelijk is voor de totstandkoming van een Product Backlog. Maar hoe? Tja, dat mag hij zelf uitzoeken. Echter, als de richting niet klopt, dan kun je nog zo geweldig Scrum gebruiken, je bent nog steeds met het verkeerde bezig. Scrum laat het maken van een visie en Product Backlog helemaal aan de Product Owner over, maar gaat er vervolgens wél vanuit dat deze visie en Backlog perfect zijn. Als dat geen dode hoek is.

INLEIDING

4 5

Als Product Owner heb je een bepaalde verantwoordelijkheid voor het product. Het is één persoon die deze rol heeft en deze beslissingen neemt. Maar dat betekent niet dat hij alles zelf moet doen. Daar is helemaal geen tijd voor. Als de Product Owner te druk is zullen alle keuzes dan goed gemaakt worden? Het zijn van een business facilitator met mandaat is daarom erg belangrijk. Sjoerd Kranendonk is coach bij Prowareness en geeft als voorbeeld dat hij veel projectleiders ziet die Product Owner worden. Als projectleider ben je gewend om alles zelf te doen met een plan voor de lange termijn. Als Product Owner moet je dit loslaten en het team en andere betrokkenen erbij betrekken. Als Product Owner ben je een soort trechter dat alle informatie omzet in een Backlog zodat het team zijn werk kan doen. Het product waar jij eigenaar van bent moet uiteraard zoveel mogelijk waarde brengen bij het bedrijf. Maar moet dit allemaal alleen? Wanneer een team redelijk volwassen is kun je er bijvoorbeeld voor kiezen om hen zelf met de stakeholders te laten praten of hen stakeholdermeetings te laten faciliteren. TipNa duidelijk afspraken gemaakt te hebben met de stakeholders kun je ervoor kiezen om een open Backlog te hebben. Zo kunnen stakeholders zelf alles in de gaten houden en zullen zij minder snel vragen stellen met betrekking tot het

proces. Een valkuil is wel dat zij zich te veel gaan bemoeien met het project en om deze reden moeten er duidelijke afspraken gemaakt worden, zoals; ‘Kijken naar de Backlog mag, maar niets aanpassen!” Wanneer een stakeholder een idee heeft kan hij deze in de icebox opslaan en later bespreken. Het handige is een tool die er voor zocht dat stakeholders toegevoegd kunnen worden, maar die dan niets kunnen aanpassen. Ook een plek om ideeën te noteren is fijn. Dit zorgt voor transparantie en iedereen voelt zich betrokken bij het process. Bij Agile Cockpit is dit mogelijk. Verschillende rollen kunnen toegevoegd worden, en in de icebox kunnen Ideeën makkelijk bewaard worden.

Je bent met Scrum gewend om je te focussen op de korte termijn. Maar als jij je alleen focust op de korte termijn dan is het heel moeilijk om richting te bepalen. En om een goede alignment te hebben met de visie van het bedrijf. Om dit te verbeteren moet je een Backlog hebben die voortkomt uit de bedrijfsvisie en dat de keuzes die jij maakt in lijn zijn met het grote geheel van het bedrijf waar je onderdeel vanuit maakt, of het bedrijf waar je voor werkt. Backlog refinement is daarom een essentiële taak van de Product Owner. Als Product Owner moet jij deze visie communiceren naar jouw teams. Zodat zij, wanneer zij keuzes moeten maken, makkelijker uit de weg kunnen. Deze visie kan gedeeld worden in workshops en Scrum events maar ook in de Backlog zelf. Bijvoorbeeld in work item waar het belangrijk is om de visie nogmaals te vermelden. Vooral bij nieuwe teams is het blijven herinneren van de visie nodig. Voor een Product Owner is Backlog refinement een grote taak maar hierdoor kan het team daarna wel zelfstandig aan de slag. Ze trekken dan minder snel hun eigen conclusies en zullen minder gauw simpele vragen stellen aan jou, omdat ze alle relevante informatie in de Backlog kunnen vinden.

TipEen goede Backlog heeft dus goede Refinement nodig. Tijdens deze taak is het belangrijk om de work items en taken niet te groot te maken. Hierdoor zie je minder gauw zichtbaar voortgang en is het minder helder waar elk teamlid aan werkt. Een fysieke Backlog met post-its of magneten heeft vaak te weinig ruimte om alle benodigde informatie kwijt te kunnen. Om die reden heeft Agile Cockpit een Backlog gecreëerd met genoeg ruimte om alle benodigde informatie op te slaan. In de tool kan je ook een Sprint Goal aanmaken. Wanneer je het goal laat aansluiten op de bedrijfsvisie zal het team meer richting hebben. Teams willen ook nog wel eens een bestand met de visie toevoegen als attachment binnen een work item. Ook binnen de work items kun je gemakkelijk jouw doel en de visie toevoegen bij de discription of acceptance critera.

Als Product Owner ben ik business facilitator met mandaat

Als Product Owner maak ik weinig tot geen gebruik van een Product Backlog

2%

Helemaal mee eens

Eens

Neutraal

Oneens

Helemaal oneens

16%

14%

2%

Helemaal mee eens

Eens

Neutraal

Oneens

Helemaal oneens

68%

1. ALLES ZELF WILLEN DOEN

De meest effectieve Product Owner bereikt zijn doelen samen met zijn teams en belanghebbenden. Dat betekent: faciliteren en niet te veel alleen doen. De Product Owner is geen businessanalist in een nieuwe verpakking, die zeer gedetailleerde hapjes werk aan de teams voert. Dus moet men eraan denken om belanghebbenden en teams bij elkaar te zetten, workshops te faciliteren en gezamenlijk te komen tot een consensus over de koers die wordt ingezet.

2. GEEN PRODUCT BACKLOG HEBBEN

Het is een veel terugkerend probleem dat maar heel weinig Product Owners daadwerkelijk een plan en visie hebben. In de praktijk zien we zelden Product Owners met een Backlog die verder dan twee Sprints vooruit is ingevuld. De Product Owner is dan niet in control. Geen inschattingen, niet vooruitkijken op langere termijn en geen release burnup, dat zorgt er allemaal voor dat je stuurt in het donker. Maak daarom de visie en Product Backlog transparant. Heb je een muur vrij in de projectruimte? Of een overzichterlijke tool waar het werk transparant inzichtelijk is voor de betrokkennen? Bespreek het werk en de visie herhaaldelijk met de teams en belanghebbenden om een goede alignment tot stand te krijgen.

Er is duidelijk te zien dat de meerderheid

het hier mee ‘Eens’ (32%) is of ‘Helemaal

mee eens’ (60%) is. Tijdens een

Cockpit Day event, die wij maandelijks

organiseren, is deze valkuil ook

besproken. Een vraag die toen wel naar

boven kwam was; “Wat is álles?” Stel

daarom altijd de vraag aan jezelf: ‘Waar

zit mijn waarde en waar kan ik mensen

meer bij betrekken?’

In de survey wint ‘Helemaal oneens’

met 68%. Logisch! Want elke Product

Owner, starter of ervaren, weet dat het

gebruiken van een Backlog essentieel

is in Scrum. Maar hoe ‘goed’ is jouw

Backlog? En wanneer jij onverwachts een

aantal dagen afwezig bent, kan iedereen

dan wel echt aan de slag? Vul daarom de

Backlog zo uitgebreid mogelijk is zodat

het team alle relevante informatie direct

kan vinden.

6 7

3. DE PRODUCT OWNER ROL ERBIJ DOENDeze rol is een fulltime baan. Maak niet de fout om te denken dat dit maximaal een uurtje per dag kost. Leid deze Refinement met belanghebbenden en de teams, en ga naar de Scrum events. Vooral de Sprint Review is voor de Product Owner cruciaal.

4. WAARDE VAN HET RESULTAAT VERGETENVeel Product Owners verdrinken in het proces en vergeten dan verantwoordelijkheid te nemen voor de waarde die hun product uiteindelijk levert. Het risico is: operatie geslaagd, patiënt overleden. LeanStartup spreekt over Validated learning: probeer zo snel mogelijk te valideren en te leren. Doen we de juiste dingen? Levert dit de meeste waarde op voor mijn klant? Wil hij mij daarvoor betalen?

Werken als Product Owner zie ik als iets extra’s, maar biedt mij qua werkzaamheden geen volledige werkweek.

Als Product Owner lever en probeer ik zo snel mogelijk te valideren en te leren, waardoor het de meeste waarde oplevertvoor de klant.

De Product Owner rol is niet iets voor ‘er naast’. Het is een fulltime baan die commitment vraagt. Het management moet dit ook erkennen zodat de Product Owner de ruimte krijgt om zijn rol het beste te volbrengen. Deze rol erbij doen helpt jou dus écht niet. Sjoerd Kranendonk vertelt dat hij in een extreem geval heeft mee gemaakt dat er een Product Owner was die één dag in de week voor zijn product beschikbaar was. Dit is een grote valkuil. Je hebt zelf in de hand hoe jij je positioneert en jij bent de eigenaar van het product. Als het product enig belang heeft voor de levensvatbaarheid van het bedrijf, de doelen en ondersteuning van de teams, dan wil jij als Product Owner je hoofd erbij hebben zodat je gefocust beslissingen kunt maken. Het hangt er natuurlijk vanaf hoe zelfstandig jouw teams zijn en wellicht is dat iets waar aan gewerkt moet worden, maar als Product Owner moet jij je kunnen richten op de meest belangrijke taken. Denk hierbij aan stakeholder management, demo’s / Reviews, priotiseren, Backlog Refinement, Roadmaps en meer. Wanneer jij deze dingen allemaal doet zul je al gauw merken dat het een fulltime job is en alle werkzaamheden die je ernaast doet moeten deze punten ondersteunen. Doe jij dit niet, dan doe je iets verkeerd.

TipDe Sprint Review is het meest belangrijke event voor een Product Owner. Hier komen alle betrokkenen bij elkaar en presenteert het team het werk wat zij die Sprint hebben afgerond. Het team moet dit goed kunnen presenteren, iedereen moet tevreden zijn met het resultaat en er wordt feedback opgevangen voor volgende Sprints. In de Agile Cockpit tool is er een Sprint Review app waarbij er een Demo Rating gegeven kan worden samen met een Happiness Rating. Wat vond iedere individue van de Demo en de manier hoe het gepresenteerd is? En hoe tevreden is iedereen met wat er is opgeleverd? Feedback kan hierin ook direct vermeld worden. Zodoende heb je als team of als Product Owner altijd een plek waar je deze informatie kan terug kijken en in een report de groei of daling van deze ratings in de gaten kunt houden.

Als je de waarde van het resultaat vergeet dan ben je eigenlijk alleen maar bezig met het kijken naar de (Sprint) Backlog; is het opgeleverd? Mooi, we zijn klaar! Na de Review pas jij de Backlog aan en op naar de volgende Sprint! Maar wat is er nou écht opgeleverd? Is iedereen tevreden? Als deze vragen niet gesteld worden ben je niet aan het sturen op businessdoelen en waarde. Maar dit is één van de kerntaken van een Product Owner. Je bent dan meer bezig om ervoor te zorgen dat jouw stakeholders blij zijn omdat je iets hebt opgeleverd. “Als het doel is om mensen blij te maken moet je clown worden”, aldus Sjoerd Kranendonk. Uiteraard wil jij mensen blij maken, zoals de gebruikers van jouw product maar wel met als doel dat het waarde moet leveren aan het bedrijf. Een kerntaak van een Product Owner is om de waarde vast te stellen van de Backlog items. Jouw stakeholders hebben eisen/verzoeken en als Product Owner moet jij het gesprek met hun aangaan om er achter te komen wat de waarden is van deze verzoeken. Het meest waardevolle tijdens een project is feedback en waarde is lastig vast te stellen. Met name zonder goede feedback. Uiteindelijk kan dat gekoppeld worden naar: ‘Wat levert het voor het bedrijf op?’ of ’Bespaart het iets voor het bedrijf?’

TipDe waarde van een work item kan bepaald worden op verschillende manieren. Een populaire manier, naast de poker planning kaarten gebruiken, is om te werken met monopolygeld of poker fiches. Zelfs in een tool zoals Agile Cockpit kun je met alle betrokkenen afspreken dat de prioriteit van een work item gekoppeld is aan het resultaat van één van deze spellen. Voordat je een waarde spel start moet de Product Owner wel zeker zijn dat alle work items volledig duidelijk zijn voor de stakeholders.Het monopolyspel heeft bijvoorbeeld briefjes van 1, 5, 10, 20 en 50. Stakeholders kunnen net zoals bij de monopoly regels een aantal briefjes krijgen. Maar wanneer er een stakeholder is die meer geld investeert in het product, dan kan die persoon ook meer briefjes krijgen om uit te geven. En nee, je mag geen geld lenen bij de bank!

14%

84%2%Eens 2%

Helemaal eens 0%

16% Oneens86% Helemaal oneens

Neutraal

68%3%16%29%

Eens Neutraal Eens Helemaal mee eens

Valideren

Een groot aantal van de participanten van de

survey geeft aan er ‘Helemaal oneens’ mee

te zijn. Zij doen de Product Owner rol er dus

niet naast. Tijdens een Cockpit Day event,

waar deze valkuil werd besproken, bleek het

alleen iets anders in de praktijk te gaan. De

deelnemers van het event gaven aan fulltime

in de rol te zitten maar daarnaast toch ook

nog andere werkzaamheden te verichtten.

Zoals het zijn van een Product Owner voor

verschillende klanten/producten. Wanneer je

wel fulltime Product Owner bent en je komt

nog steeds tijd te kort dan is het verstandig

om de eerste valkuil “Alles zelf willen doen”

onder de loep te nemen

Een deel van de Product Owners zijn goed bezig met het op tijd valideren en waarde vast te stellen bij betrokkenen. Maar 29% heeft

toch ‘oneens’ ingevuld. Waarde is ook lastig vast te stellen vooral met een groot aantal stakeholders of ‘lastige’ stakeholders. Praat

open en transparant over de waarde met alle betrokkenen en stel de vraag; ‘Hoe houden wij het bedrijf gaande?’, gerust aan de

betrokkenen en houd deze ook altijd in jouw achterhoofd.

8 9

5. MANDAAT VERONDERSTELLENDe impact van de Product Owner staat of valt met de ruimte om daadwerkelijk beslissingen te nemen. Dit is randvoorwaardelijk aan de rol. Mandaat is geen vanzelfsprekendheid en dat zal de Product Owner zelf moeten eisen, nemen, veroveren.

6. PROJECT LEIDER SPELENEen Product Owner is geen projectleider. Hij maakt waarde inzichtelijk en ordent wat eerst nodig is en wat later. Veel Product Owners maken de fout om werk het team in te duwen. Zij laten niet het team zelf bepalen hoeveel ze kunnen doen en hoe. Zij beslissen voor het team wat er echt af moet komen deze Sprint. Als een soort projectleider. Dat is niet goed. Het team kan zelf verantwoordelijkheid pakken door werk van de Product Backlog te trekken. Geen push, maar een pull dus.

Kwaliteit, waarde en verbetering. Als Product Owner zit jouw rol op ‘waarde’. Maximaliseren en optimaliseren in relatie tot de visie van het bedrijf. De Srum master gaat over de verbeteringen binnen het team, en het team gaat over de kwaliteit. Als Product Owner moet je dit accepteren en het vertrouwen ook leggen bij het Scrum team.

Mijn rol als Product Owner zie ik meer als Projectleider en ik bepaal wat er de komende Sprints van het team verwacht wordt.

Als Product Owner heb ik de ruimte om beslissingen te maken en gebruik ik mijn kennis en impact om het verschil te maken.

Een voorbeeld van het hebben van geen mandaat is dat de Product Owner makkelijk te beinvloeden is door andere in zijn omgeving. Dit kan ook onbewust gebeuren! Een voorbeeld is dat een goede vriend overtuigd is van zijn idee en dit op jouw schoot legt. Als jij dit de volgende dag aan het team voorlegt moet je niet vergeten dat jij wel 100% achter het idee moet staan. Nu zul je denken dat het jou niet zou overkomen, maar dit is vaker voorgekomen dan jij denkt. Het team kan bij dit soort momenten lastige vragen gaan stellen. Het moment dat jij niet met goede argumenten kunt komen, verlies je vertrouwen binnen dat team. Sta achter jouw ideeën en heb mandaat, maar sta wel open voor alle betrokkenen. De Product Owner moet mensen mee krijgen in zijn beslissingen. Alle betrokkenen kunnen verschillende meningen hebben over wat welke Sprints opgepakt moet worden, maar uiteindelijk neemt de Product Owner de eindbeslissing. De Product Owner moet mandaat hebben om het team te kunnen stimuleren om vol energie aan de volgende Sprint te werken. Wanneer jij nieuwe ideeen krijgt

van andere kun je altijd zeggen, ‘Super leuk idee. Ik neem het mee en bespreek het met het team’. Ook kun je mensen uitnodigen om naar de Review te komen. Maar alleen als jij denkt dat het waarde zal brengen. TipAls Product Owner kun je overpowerd worden in de Review door stakeholders. Of een CEO zorgt ervoor dat een prioriteit opeens verandert. Betrek de CEO bij de why en de product visie. Ga een één-op-één gesprek met de CEO aan en bespreek dit met hem. Hierdoor creëer je ook mandaat omdat de CEO ziet dat jij waarde hecht aan zijn mening maar niet het doel / de visie wil verliezen. “Op alles JA zeggen” sluit goed aan op deze valkuil en wordt ook besproken in dit report.

Je verstoort de zelforganisatie van het team als je te veel als projectleider gaat spelen in plaats als Product Owner. Als projectleider wil je eigenlijk overal controle over hebben, wil je zelf alle lijntjes leggen en hierdoor gaan de mensen alleen maar taakjes uitvoeren. Hierdoor krijg je niet de creativiteit, inzet en enthousiasme om het beste product te maken. Als Product Owner moet je daarom echt sturen op waarde. TipAls Product Owner zit jouw rol op ‘waarde’. Maximaliseren en optimaliseren in relatie tot de visie van het bedrijf. De Scrum Master gaat over de verbeteringen binnen het team en het team gaat over de kwaliteit. Als Product Owner moet je dit

accepteren en het vertrouwen ook leggen bij het Scrum Team. Vooral voor nieuwe teams is het wiel hieronder een goede visualisatie van de samenstelling van de mensen binnen het project. Het wiel; kwaliteit, waarde en verbetering, kan uitgeprint worden en opgehangen worden in de ruimte waar het team werkt zodat ieder zich bewust is van zijn hoofddoel.

Helemaal mee eens

Eens

Neutraal

Oneens

43%

46%

8%

3%

Eens Helemaal oneensNeutraal Oneens

14% 37% 17% 32%

Iedere Product Owner die weet wat zijn of

haar rol inhoudt, weet dat het belangrijk

is om de ruimte te hebben voor het maken

van beslissingen. Een klein aantal van de

survey participanten hebben hier helaas

niet alle ruimte voor. Je moet duidelijk

maken aan de stakeholders wat de

gevolgens zijn als deze vrijheid er niet is

en beslissingen vóór de Product Owner

worden gemaakt. Blijft het product trouw

aan de bedrijfvisie? Hoe reageert het

team op de beslissingen? En wat vindt de

eindgebruiker hiervan?

Van alle survey participanten heeft 37%

‘Neutraal’ ingevuld en 14% ‘Eens’. Dit betekent

dat een groot deel nog (deels) projectleider

is in plaats van Product Owner. De kracht

van Scrum is dat je teams zelforganiserend

maakt. Als jij je focused op de ‘why’ (waarde)

en de ‘what’ (work items) dan kan het team

zich focussen op de ‘hoe’ (kwaliteit). Dit zal

dan gebeuren met meer inzet en creativiteit.

Waarde

Product Owner

Verbetering Scrum Master

Kwaliteit

Team Member

10 11

7.VERBETERING UITSTELLENAls teams sneller worden, plukt de Product Owner daar de vruchten van in de volgende Sprints. Voorkom wel dat Sprints niet alleen maar vol zitten met het bouwen van functionaliteit. Reserveer specifiek tijd voor het verbeteren van de technische practices van het team. Pushen op meer functionaliteit, zonder daarvoor de verbeteringen te willen doorvoeren, werkt niet op de lange termijn. Kwaliteit is nooit onderhandelbaar.

8. FEEDBACK UITSTELLENEen bekende fout is om pas feedback te vragen als het ‘klaar’ is, om eerst perfectie na te streven voordat belanghebbenden mee mogen kijken. Het effect is dat feedback te laat komt en het dan meer tijd kost en hierdoor duurder is om op te pakken. Durf vanaf het begin toe te geven dat je het ook niet altijd zeker weet. Experimenteren is noodzakelijk voordat je grote investeringen doet. De Product Owner is het vizier en het experimenteren is het scherpstellen en richten van dat vizier. Feedback vragen en dus de leiding nemen in de Sprint Review is daarom essentieel.

Als Product Owner ligt de focus tijdens een Sprint hoofdzakelijk op het bouwen van de functionaliteit en staat het doorvoeren van verbeteringen op een laag pitje.

Als Product Owner daag ik de belanghebbenden uit door alles wat ze vragen op de Product Backlog te zetten, met als veronderstelling dat al het werk gedaan wordt.

Het puur focussen op nieuwe functionaliteiten en de optimalisatie uitstellen is verleidelijk. Alleen werken aan nieuwe features is korte termijn werk. Optimalisatie binnen het team en het product brengt ook veel waarde en is voor de lange termijn. Alles wat je toevoegt moet ook iets toevoegen voor de gebruiker maar dan kan je vergeten om ook de kwaliteit te verbeteren. Zoals het doen van onderhoud. Dit moet duidelijk gemaakt worden aan stakeholders die vaak alleen maar enthousiast worden bij de gedachte om nieuwe functionaliteiten te bouwen. Als je niet gaat werken aan jouw architectuur en technische verbetering, of het werkproces van het team, dan loop je op een gegeven moment tegen een muur aan. Dan zal het veel tijd kosten om dat allemaal op orde te krijgen. Het team is dan alleen maar brandjes aan het blussen. Het kan dan voorkomen dat dit een aantal Sprints duurt en dat je in die periodes geen tijd hebt voor nieuwe functionaliteiten. Dat is dan lastig om uit te leggen aan de stakeholders.

TipDenk niet alleen aan de korte termijn. Wanneer je een aantal Sprints vooruit plant is het verstandig om alvast een work item aan te maken met betrekking tot het optimaliseren van jouw product. Reserveer elke Sprint wat tijd om hiermee aan de slag te gaan. Ook kan je binnen de work item in de Agile Cockpit tool een acceptance critera uitbouwen tot een uitgebeide checklist die jou hierbij helpt. Ook de DoD (Definition of done) kan hieraan toegevoegd worden. Een DoD is een algemene checklist en acceptance criteria zijn eisen waar een specifiek work item aan moet voldoen. In de Agile Cockpit tool is genoeg ruimte om beide te plaatsen in een work item. In een IT omgeving kan een DoD de volgende regels hebben: Alle code is geschreven, alle functionele tests zijn gedraaid en code heeft een peer Review ondergaan. Als acceptance criteria kan er bijvoorbeeld staan ‘hoe’ het moet functioneren. Deze checklists zijn vaak oppervlakkig waardoor er daarna altijd wel weer iets opgepakt moet worden in de volgende Sprint om iets te ‘fixen’. Maak daarom deze checklists uitvoerig, waarin duidelijk staat wat er gedaan moet worden voordat een work item klaar is.

Waarde voorspellen en valideren is een kerntaak van de Product Owner. Als de waarde is bepaald en de Sprint is behaald dan laat je in de Review zien wat het team heeft opgeleverd. Breng dit naar jouw eindgebruiker en haal de feedback op om te kijken of het de waarde haalt wat voorspelt was. Kijk niet alleen naar de Backlog als een lijst met requirements maar ook als een lijst met hypotheses. Door deze te realiseren kun je verifiëren of de potentiele waarde er daadwerkelijk in zit. Agile is een impirisch proces. Daardoor is Agile groot geworden. Daarom maak je geen plan van een jaar en ga je daarna feedback halen. Elke Sprint weer, tijdens de Review, bekijk je de resultaten kritisch, check je de hypotheses en met die inzichten pas je de volgende Sprint aan. De volgende drie vragen moeten altijd worden gesteld: heeft de klant mijn oplossing nodig? Ten tweede: wil de klant voor de oplossing betalen? En ten derde: wil de klant mij voor deze oplossing betalen? Tot het moment dat er een bewezen

‘ja’ ligt op deze vragen, is investeren te risicovol. Immers, of de investering gaat renderen is dan veel te onzeker. TipFeedback is zo cruciaal dat alleen een Review met stakeholders eigenlijk niet genoeg is. Wat vindt de eindgebruiker er eigenlijk van? De eindgebruiker wordt vaak niet uitgenodigd voor een Review maar is eigenlijk onmisbaar. Leg contacten met verschillende type eindgebruikers en nodig ze uit om deel te nemen aan de Reviews. Laat ze tijdens de Sprint ook eens langskomen om een aantal dingen te testen. Het mooiste is dan dat je tijdens een Review met waardevolle Stakeholders vol overtuiging kan zeggen; “De eindgebruiker is tevreden”, met het bewijs.

Helemaal eens

Eens

Neutraal

Oneens

Helemaal oneens

3%

9%

26%

29%

43%32%10%5%2% 52%

Helemaaloneens

Helemaaleens

Een groot aantal survey participanten zien in dat het

bouwen van nieuwe functionaleiten, en verbetering hierdoor

uitstellen, niet de oplossing is. (43% ‘Helemaal oneens en

29% ‘Oneens’). Toch zijn er een aantal die zich wel meer

focusses op nieuwe features in plaats van bestaand werk

optimaliseren. (26% ‘Neutraal’ en 9% ‘Eens’). Zorg dat jouw

product stabiel is en ‘future proof’. Geef het team daarom

ruimte voor het verbetering van kwaliteit en praat ook met

het team om te kijken hoe je samen nieuwe functionaliteiten

kunt leveren maar ook voor de lange termijn aan

optimalisatie gaat werken.

Dit is een gevaarlijke. Wel 32% geeft aan het hier ‘Helemaal mee eens’ te zijn en 52% geeft aan hier mee ‘Eens’ te

zijn. Hierdoor kan de Product Backlog snel uitpuilen waardoor je als Product Owner geen overzicht meer hebt en ook

beloftes maakt waar jij je misschien helemaal niet aan kunt houden. Feedback krijgen is belangrijk, maar bekijk eerst

goed de waarde van de feedback voordat het op de Backlog gezet wordt.

12 13

9. OP ALLES ‘JA’ ZEGGEN

Een Product Pwner moet belanghebbenden uitdagen: alles wat ze vragen op de Product Backlog gooien, is niet goed. De belangrijkste kwaliteit is ‘nee’ zeggen. Het maximaliseren van het werk dat de teams niet gaan doen, dat is de uitdaging van elke Product Owner. ‘Ja’ zeggen is makkelijk, maar schept wellicht een verkeerde verwachting. Waarom kan het niet? Wat zijn de alternatieven? Kan het simpeler? Wat kan er wel? Dat zijn belangrijke vragen om als Product Owner te stellen.

AGILE COCKPIT

Agile Cockpit onderscheidt zich van andere tools door het gebruik van SAFe (Scaled Agile Framework). De tool is ingedeeld in de 4 levels; Team, Program, Portfolio en Enterprise. Dit zorgt ervoor dat iedereen alleen de informatie ziet die voor hem of haar relevant is. In de tool is ook een 5e level toegevoegd genaamd; Me. Waarin elke gebruikers zijn of haar eigen taken gemakkelijk kan terug vinden. Als Product Owner ben je veel bezig met jouw team binnen het Team level en beheer je jouw gehele product op Program level, als je bijvoorbeeld meerdere teams hebt. Onze software heeft ook een unieke Wolf Pack app, waarmee je in seconden een tijdelijk team opricht om samen te werken in Gildes of aan innovaties! Zodoende boost Agile Cockpit ondernemerschap bij individuen en maakt ze zelfverzekerder en onafhankelijker, wat bijdraagt aan een Responsive mindset.

Als Product Owner streef ik naar perfectie, maar experimenteer ik voordat ik grote investeringen maak. Door continu feedback te vergaren kan ik doelen bijstellen en

scherpstellen met als doel het beste resultaat.

Als het jou niet lukt om nee te zeggen dan wordt jij een Product Owner die één op één gesprekken heeft met iedereen en daarna iedereen teleur moet stellen omdat hij niet iedereen tevreden kan houden. Wanneer je overal ja op zegt en beloftes maakt beperk je jouw keuzes. Nee zeggen is daarom een kunst. Prowareness coach Rob van Lanen geeft als tip dat jij jezelf niet moet laten overpoweren door wat iedereen wilt hebben. Zeg alleen ja als het écht iets is wat jij wil en wat in lijn is met de bedrijfsvisie. Rob praat daarom ook over ‘Fifty shades of NO’. “Goed idee, ik ga er een nachtje over slapen” of “Hartstikke goed maar hoe kunnen we dit van 50 gebruikers naar 50.000 gebruikers omzetten?” of “Goed idee. Kom naar de Sprint Review en dan kijken we wat de andere stakeholders ervan vinden”. Dit is geen ‘valse’ of ‘laffe’ manier om iets te ontduiken maar als een manier om daadwerkelijk echt te kiezen waar je voor wil gaan en er gezamelijke raakvlakken voor te hebben. Zo ben je geen norre Product Owner die altijd nee zegt maar een Product Owner die open staat voor ideeen en er altijd goed over nadenkt. Je zorgt ervoor dat je elke Sprint goed kan bijsturen en de juiste

beslissingen kan nemen wanneer je jouw opties open houdt. Wanneer je overal ja op zegt beperk jij jezelf in deze opties. TipRob van Lanen sprak over een tussenlijstje waar je ideeën kan opzetten en later naar kunt kijken. Dit lijstje is vaak verspreid over verschillende notitieblokken of ergens in een sharepointfolder verstopt. Jij weet het misschien dan altijd goed te vinden maar de rest niet. Alle ideeën komen dan bij jou en jij moet het gaan doorzetten naar jouw lijstje. Al eerder is benoemd dat Agile Cockpit een icebox colomn heeft binnen de Backlog app. Iedereen die toegang heeft tot de Backlog van dat team kan ideeën in de icebox zetten. Plan zo nu en dan een moment om deze ideeën te bekijken en bespreek ze met het team en de stakeholders. Is het een leuk idee? Drag & drop het gemakkelijk naar de Product Backlog en ga er mee aan de slag!

Helemaal mee eens

Eens

Neutraal

Oneens

Helemaal oneens51%

32%13%

3%1%

�

Op alles JA zeggen is een grote valkuil onder

Product Owners. Maar veel experimenteren,

investeringen maken en streven naar perfectie

moet uiteraard wel altijd gebeuren! De grote

meerderheid van de survey participanten is

hier overduidelijk mee eens. Maar om hiervoor

ruimte te creëren moet er nee gezegd kunnen

zeggen. “Goh, ik zet het idee even op een

tussenlijst en als er meer mensen met het idee

komen denk ik er overna”, is een manier van

nee zeggen. Zorg altijd dat je het doel niet uit

ogen verliest.

Als Product Owner is data-driven overzicht belangrijk en is het mooi als er een tool is die jou ook inzichten geeft in de verschillende Releases. Agile Cockpit geeft daarom, op Team level, de mogelijkheid om een Release planning te maken met een forecast. Zo kan het team zelf in de gaten houden of zij op schema zitten of niet. Op Program level is de Release Planning app te vinden waar je, naast de Program Backlog, een Program Release kan inzien met een forecast. De Release Planning app berekent automatisch de pessimistische, verwachte en optimistische release data gebaseerd op data uit eerdere Sprints. Zie hoe de volledige Program er voor staat en stuur bij waar nodig. Zie ook de dependancies van verschillende work items die afhankelijk zijn van elkaar en zorg dat Sprints worden gehaald! Ook kunnen alle betrokkenen in de Sprint Review app hun tevredenheid aangeven met een rating. Zo kun je hun tevredenheid over een bepaalde tijd monitoren en verbeteren als dat nodig is.Het doel van Agile Cockpit is om meer transparant inzicht te creëren om samenwerking, communicatie en alignment te bevorderen. Vandaag de dag tilt Agile Cockpit bedrijven die Agile werken naar een hoger niveau. Dit door als eerste Cloud

Based software de focus te leggen op het Responsive maken van organisaties.TipAgile Cockpit organiseert verschillende events waarbij er altijd wat nieuws te leren valt! Bekijk onze events op agilecockpit.com en zie daar ook meer informatie over de tool zelf. Geintereseert in een demo van de tool? Stuur een mail naar info@agilecockpit.com om iets in te plannen!