MENU

Hoe bouw je als Product Owner goed presterende Scrum Teams?

De interactie van een Product Owner met het ontwikkelteam is cruciaal voor hun prestaties. Is deze interactie niet goed, dan kan dit een goed presterend team flink de grond in boren. Hier lees je de 10 belangrijkste dingen jij als Product Owner kunt doen om goed presterende Scrum teams te bouwen.
Door: Natasja Spaans op 3 augustus 2020.
Lezen in: 6 minuten.

1. Begrijp de pijn en behoeften van je klant

Upgrade de gebruiker, niet je product. Bouw geen betere camera’s – bouw betere fotografen. – Kathy Sierra 

Je (toekomstige) klanten komen niet bij jou voor je product. Ze willen iets dat hun eigen leven zal verbeteren – de vooruitgang die het biedt. Je moet je concentreren op het begrijpen van de pijnen, verlangens, ambities en problemen van je klant als jij een geweldig product wilt bouwen dat waarde levert. 

Om je te verplaatsen in de klant en zijn of haar pijn en behoeften is de empathy map een mooie tool. Wij hebben hiervoor een template beschikbaar die je direct kan toepassen. Deze vind je onderaan dit blog. 

2. Maak van het leveren van waarde een teaminspanning 

Het leveren van een waardevol product is teamwork! Als Product Owner moet je ervoor zorgen dat het hele Scrum team begrijpt hoe we waarde leveren aan onze klanten en het bedrijf. Dit doe je door het Scrum team actief bij discussies te betrekken om te beslissen wat het juiste is om te bouwen om de beste resultaten te bereiken. 

Je krijgt terug wat je geeft. Betrek je team bij je beslissingen en zij zullen zich betrokken voelen waarmee de inzet omhoog zal gaan. Doe je dit niet dan creëer je afstand en zal het team ook minder geven om de uitkomst.  

3. Creëer een omgeving waarin het veilig is om fouten te maken 

“Als falen geen optie is, dan is succes dat ook niet.” – Seth Godin 

Bij elke sprint bestaat de kans dat je team faalt. De manier waarop je het team behandelt in tijden van mislukking is essentieel voor succes. Falen zou in orde moeten zijn, op voorwaarde dat we hier iets van leren om ons te helpen slagen in de toekomst. 

De vijf disfuncties van een teammodel van Patrick Lencioni laten zien waarom psychologische veiligheid essentieel is voor het creëren van een goed presterend team. Psychologische veiligheid ontstaat wanneer teamleden zich veilig voelen om risico’s te nemen en zich kwetsbaar op durven stellen. 

De 5 disfuncties van een teammodel worden ondersteund door onderzoek van project Aristoteles bij Google. Zij ontdekten dat psychologische veiligheid belangrijker is dan het hebben van een team van supersterren. 

Om Scrum te laten werken, is psychologische veiligheid essentieel. Een procesraamwerk kan alleen leiden tot een beter werkproces als er een basis is van psychologische veiligheid die experimenteren en falen mogelijk maakt. 

4. Richt je inspanningen op het doen van de juiste dingen 

“Eenvoudig kan moeilijker zijn dan complex: je moet hard werken om je denken helder te krijgen om het eenvoudig te maken. Maar uiteindelijk is het het waard, want als je daar eenmaal bent, kun je bergen verzetten. ” – Steve Jobs 

Ik zou zeggen dat de belangrijkste taak van een Product Owner het creëren van focus is. Je moet elimineren wat er niet toe doet, zodat wat er wél toe doet opvalt. Anders verminderen de dingen die er niet toe doen de waarde van jouw product. 

Scrum helpt Product Owners op een natuurlijke wijze zich te focussen, door elke Sprint een duidelijk Sprintdoel te eisen. 

Werken met Sprintdoelen is niet genoeg. Er moet een overkoepelende productvisie en productstrategie aanwezig zijn om de samenhang tussen de verschillende sprintdoelen te waarborgen. 

5. Begin met onderzoek voordat je begint met leveren 

De meeste bedrijven zitten nog altijd vast in de fabrieksmodus en staan te juichen wanneer teams nieuwe functies uitbrengen. Weersta de verleiding om iedere keer een nieuwe functie te gaan bouwen wanneer iemand hierom vraagt. Onderzoek eerst en bouw later. Geef prioriteit aan onderzoeken en leren, zodat je begrijpt wat het belang is van die functie en wat er eigenlijk nodig is om die functie tot een succes te maken. 

Voer experimenten uit en verzamel bewijsmateriaal, zodat je zoveel mogelijk weet over wat de klant nodig heeft voordat je een functie gaat bouwen. Streef naar minder maar beter. Soms is het logisch om tegelijkertijd te bouwen en te leren. Maak eerst een bewuste beslissing als de beste manier is om de kans op het juiste bouwen te vergroten. 

Als een functie eenmaal in je product is opgenomen, hoe waarschijnlijk is het dan dat deze wordt verwijderd? Als de functie er eenmaal inzit heeft deze vrijwel altijd onderhoud nodig. Daarom doe je er goed aan bewust te kiezen bij het bouwen van nieuwe functies. Begin met het maken van een hypothese en evalueer onderweg of je hebt bereikt wat je wilde bereiken. 

6. Hou je Product Backlog kort 

Ga bewust om met de items die je op je Product Backlog plaats. Je wilt voorkomen dat je je Product Backlog vervuilt met ideeën of dingen die je waarschijnlijk niet zult oppikken. Behandel je Product Backlog als melk: heb net genoeg voor de nabije toekomst, maar niet meer. Anders wordt je Product Backlog oud en zal het moeite kosten om weer vers te maken.  

7. Wees lui met het schrijven van Product Backlog Items 

Veel Product Owners besteden veel tijd aan het schrijven van Product Backlog Items. Mijn tip: doe dit niet! Het is een grote tijdverspilling en het is niet de manier om waarde toe te voegen aan het Scrum team. Een uitgebreid beschreven product Baclog Items helpt om de functie goed te bouwen, maar niet de juiste functie te bouwen. Op basis van mijn persoonlijke ervaring mag een Product Owner slechts 20% van zijn tijd besteden aan levering, 80% aan ontdekking en validatie. 

Richt je op het begrijpen van het probleem dat je probeert op te lossen en geef deze informatie door aan het ontwikkelingsteam. Maak vervolgens samen de Product Backlog Items. Op deze manier is het een werkend product van het hele Scrum team, in plaats van alleen jou. Door hier samen aan te werken zal iedereen hetzelfde begrijpen en onthouden wat er moet gebeuren om het product te verbeteren. 

Uiteindelijk doet het er niet toe wat er in het Product Backlog Item is opgeschreven: Dat het Ontwikkelingsteam het begrijpt, is het belangrijkste. 

8. Verwijder ongebruikte en niet-waarde toevoegende functies

Elke functie moet waarde toevoegen aan je product en de contributie betalen. Functies die niet hun eigen gewicht trekken, verminderen de waarde van je product. Ongebruikte functies zijn als parasieten die geld verbranden om in leven te blijven: infrastructuurkosten, kosten als gevolg van productieproblemen en onderhoudskosten om ze aan nieuwere versies te laten werken. Je kunt niet snel inspelen op veranderingen wanneer al deze parasieten je vertragen. 

Verwijder deze functies daarom snel, omdat het capaciteit vrijmaakt om aan waardevollere dingen te werken en in de loop van de tijd veel geld bespaart. 

Het verwijderen van ongebruikte functies is om twee redenen moeilijk: 

  1. Het is moeilijk om erachter te komen welke functies in jouw product er echt toe doen, vooral als je niet begrijpt hoe jij waarde toevoegt aan jouw klanten. 
  1. Mensen hebben er een hekel aan om dingen te verliezen, veel meer dan het verkrijgen van nieuwe dingen. Dit wordt verliesaversie genoemd. Dus zelfs als slechts een paar klanten een zeer impopulaire functie gebruiken, kunnen ze hier veel weerstand tegen tonen, omdat mensen een hekel hebben aan het verliezen van wat ze al hebben. 

9. Laat het team de oplossing bedenken, maar daag ze uit! 

Als Product Owner moet je je concentreren op het uitleggen van het probleem dat je wilt oplossen. Het is niet jouw taak om een technische oplossing te bedenken. Jouw taak is er voor zorgen dat de technische oplossing de meeste waarde oplevert. Daag je team uit als je denkt dat ze met een te ingewikkelde oplossing komen om er zeker van te zijn dat al die complexiteit echt nodig is. Oplossingen moeten zo eenvoudig mogelijk zijn, maar niet eenvoudiger. 

10. Manage je klanten niet, betrek ze erbij 

Ongelukkige stakeholders kunnen jouw baan als Product Owner het leven zuur maken. Daarom is het erg belangrijk dat je een manier vindt om ze tevreden te houden. De beste manier om dit te doen is niet door je stakeholders te managen, maar door ze erbij te betrekken. Een eenvoudige manier om je belangrijkste stakeholders te betrekken, is door ze uit te nodigen voor de volgende Sprint Review.

1. Begrijp de pijn en behoeften van je klant

Upgrade de gebruiker, niet je product. Bouw geen betere camera’s – bouw betere fotografen. – Kathy Sierra 

Je (toekomstige) klanten komen niet bij jou voor je product. Ze willen iets dat hun eigen leven zal verbeteren – de vooruitgang die het biedt. Je moet je concentreren op het begrijpen van de pijnen, verlangens, ambities en problemen van je klant als jij een geweldig product wilt bouwen dat waarde levert. 

Om je te verplaatsen in de klant en zijn of haar pijn en behoeften is de empathy map een mooie tool. Wij hebben hiervoor een template beschikbaar die je direct kan toepassen. Deze vind je onderaan dit blog. 

2. Maak van het leveren van waarde een teaminspanning 

Het leveren van een waardevol product is teamwork! Als Product Owner moet je ervoor zorgen dat het hele Scrum team begrijpt hoe we waarde leveren aan onze klanten en het bedrijf. Dit doe je door het Scrum team actief bij discussies te betrekken om te beslissen wat het juiste is om te bouwen om de beste resultaten te bereiken. 

Je krijgt terug wat je geeft. Betrek je team bij je beslissingen en zij zullen zich betrokken voelen waarmee de inzet omhoog zal gaan. Doe je dit niet dan creëer je afstand en zal het team ook minder geven om de uitkomst.  

3. Creëer een omgeving waarin het veilig is om fouten te maken 

“Als falen geen optie is, dan is succes dat ook niet.” – Seth Godin 

Bij elke sprint bestaat de kans dat je team faalt. De manier waarop je het team behandelt in tijden van mislukking is essentieel voor succes. Falen zou in orde moeten zijn, op voorwaarde dat we hier iets van leren om ons te helpen slagen in de toekomst. 

De vijf disfuncties van een teammodel van Patrick Lencioni laten zien waarom psychologische veiligheid essentieel is voor het creëren van een goed presterend team. Psychologische veiligheid ontstaat wanneer teamleden zich veilig voelen om risico’s te nemen en zich kwetsbaar op durven stellen. 

De 5 disfuncties van een teammodel worden ondersteund door onderzoek van project Aristoteles bij Google. Zij ontdekten dat psychologische veiligheid belangrijker is dan het hebben van een team van supersterren. 

Om Scrum te laten werken, is psychologische veiligheid essentieel. Een procesraamwerk kan alleen leiden tot een beter werkproces als er een basis is van psychologische veiligheid die experimenteren en falen mogelijk maakt. 

4. Richt je inspanningen op het doen van de juiste dingen 

“Eenvoudig kan moeilijker zijn dan complex: je moet hard werken om je denken helder te krijgen om het eenvoudig te maken. Maar uiteindelijk is het het waard, want als je daar eenmaal bent, kun je bergen verzetten. ” – Steve Jobs 

Ik zou zeggen dat de belangrijkste taak van een Product Owner het creëren van focus is. Je moet elimineren wat er niet toe doet, zodat wat er wél toe doet opvalt. Anders verminderen de dingen die er niet toe doen de waarde van jouw product. 

Scrum helpt Product Owners op een natuurlijke wijze zich te focussen, door elke Sprint een duidelijk Sprintdoel te eisen. 

Werken met Sprintdoelen is niet genoeg. Er moet een overkoepelende productvisie en productstrategie aanwezig zijn om de samenhang tussen de verschillende sprintdoelen te waarborgen. 

5. Begin met onderzoek voordat je begint met leveren 

De meeste bedrijven zitten nog altijd vast in de fabrieksmodus en staan te juichen wanneer teams nieuwe functies uitbrengen. Weersta de verleiding om iedere keer een nieuwe functie te gaan bouwen wanneer iemand hierom vraagt. Onderzoek eerst en bouw later. Geef prioriteit aan onderzoeken en leren, zodat je begrijpt wat het belang is van die functie en wat er eigenlijk nodig is om die functie tot een succes te maken. 

Voer experimenten uit en verzamel bewijsmateriaal, zodat je zoveel mogelijk weet over wat de klant nodig heeft voordat je een functie gaat bouwen. Streef naar minder maar beter. Soms is het logisch om tegelijkertijd te bouwen en te leren. Maak eerst een bewuste beslissing als de beste manier is om de kans op het juiste bouwen te vergroten. 

Als een functie eenmaal in je product is opgenomen, hoe waarschijnlijk is het dan dat deze wordt verwijderd? Als de functie er eenmaal inzit heeft deze vrijwel altijd onderhoud nodig. Daarom doe je er goed aan bewust te kiezen bij het bouwen van nieuwe functies. Begin met het maken van een hypothese en evalueer onderweg of je hebt bereikt wat je wilde bereiken. 

6. Hou je Product Backlog kort 

Ga bewust om met de items die je op je Product Backlog plaats. Je wilt voorkomen dat je je Product Backlog vervuilt met ideeën of dingen die je waarschijnlijk niet zult oppikken. Behandel je Product Backlog als melk: heb net genoeg voor de nabije toekomst, maar niet meer. Anders wordt je Product Backlog oud en zal het moeite kosten om weer vers te maken.  

7. Wees lui met het schrijven van Product Backlog Items 

Veel Product Owners besteden veel tijd aan het schrijven van Product Backlog Items. Mijn tip: doe dit niet! Het is een grote tijdverspilling en het is niet de manier om waarde toe te voegen aan het Scrum team. Een uitgebreid beschreven product Baclog Items helpt om de functie goed te bouwen, maar niet de juiste functie te bouwen. Op basis van mijn persoonlijke ervaring mag een Product Owner slechts 20% van zijn tijd besteden aan levering, 80% aan ontdekking en validatie. 

Richt je op het begrijpen van het probleem dat je probeert op te lossen en geef deze informatie door aan het ontwikkelingsteam. Maak vervolgens samen de Product Backlog Items. Op deze manier is het een werkend product van het hele Scrum team, in plaats van alleen jou. Door hier samen aan te werken zal iedereen hetzelfde begrijpen en onthouden wat er moet gebeuren om het product te verbeteren. 

Uiteindelijk doet het er niet toe wat er in het Product Backlog Item is opgeschreven: Dat het Ontwikkelingsteam het begrijpt, is het belangrijkste. 

8. Verwijder ongebruikte en niet-waarde toevoegende functies

Elke functie moet waarde toevoegen aan je product en de contributie betalen. Functies die niet hun eigen gewicht trekken, verminderen de waarde van je product. Ongebruikte functies zijn als parasieten die geld verbranden om in leven te blijven: infrastructuurkosten, kosten als gevolg van productieproblemen en onderhoudskosten om ze aan nieuwere versies te laten werken. Je kunt niet snel inspelen op veranderingen wanneer al deze parasieten je vertragen. 

Verwijder deze functies daarom snel, omdat het capaciteit vrijmaakt om aan waardevollere dingen te werken en in de loop van de tijd veel geld bespaart. 

Het verwijderen van ongebruikte functies is om twee redenen moeilijk: 

  1. Het is moeilijk om erachter te komen welke functies in jouw product er echt toe doen, vooral als je niet begrijpt hoe jij waarde toevoegt aan jouw klanten. 
  1. Mensen hebben er een hekel aan om dingen te verliezen, veel meer dan het verkrijgen van nieuwe dingen. Dit wordt verliesaversie genoemd. Dus zelfs als slechts een paar klanten een zeer impopulaire functie gebruiken, kunnen ze hier veel weerstand tegen tonen, omdat mensen een hekel hebben aan het verliezen van wat ze al hebben. 

9. Laat het team de oplossing bedenken, maar daag ze uit! 

Als Product Owner moet je je concentreren op het uitleggen van het probleem dat je wilt oplossen. Het is niet jouw taak om een technische oplossing te bedenken. Jouw taak is er voor zorgen dat de technische oplossing de meeste waarde oplevert. Daag je team uit als je denkt dat ze met een te ingewikkelde oplossing komen om er zeker van te zijn dat al die complexiteit echt nodig is. Oplossingen moeten zo eenvoudig mogelijk zijn, maar niet eenvoudiger. 

10. Manage je klanten niet, betrek ze erbij 

Ongelukkige stakeholders kunnen jouw baan als Product Owner het leven zuur maken. Daarom is het erg belangrijk dat je een manier vindt om ze tevreden te houden. De beste manier om dit te doen is niet door je stakeholders te managen, maar door ze erbij te betrekken. Een eenvoudige manier om je belangrijkste stakeholders te betrekken, is door ze uit te nodigen voor de volgende Sprint Review.

Door Natasja Spaans

Het mooiste aan mijn rol als verandergids vind ik dat ik iedereen kan helpen weer plezier te hebben in hun werk. Dit doe ik door mensen met elkaar te verbinden, samen successen te vieren en kleine geluksmomentjes te ervaren. Want alleen ga je sneller, maar samen kom je verder!

Geef een reactie

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

Maandelijks inspirerende tips en informatie ontvangen?

Schrijf je in voor onze nieuwsbrief en ontvang iedere maand inspirerende tips en handige informatie.
Nieuwsbrief Footer

Lagant partners

Het is onze missie om klanten te helpen hun veranderambities waar te maken.

Stationsplein 26
3818 LE Amersfoort

Onze locatie in Amersfoort ligt pal tegenover de hoofdingang van het NS-station en is dus eenvoudig per openbaar vervoer bereikbaar.
Kom je met de auto, dan kun je het beste parkeren in de Q-Park P+R Barchman Wuytierslaan op circa 5 minuten loopafstand van ons kantoor.

[email protected]+31 (0)41 322 4106
8.9
 151 beoordelingen
Van AetsveldSLIM-subsidieregelingVerandergidsIPMA CompactPRINCE2 Compact
Deze website draait op 100% duurzame energie, gewonnen uit kooldioxidevrije en milieuvriendelijke waterkracht.
© 1991-2024 Lagant | Alle rechten voorbehouden |