Scrum-productmanagement: complete gids + voorbeelden
Scrum is niets nieuws binnen productmanagement. De meesten van ons gebruiken Scrum in onze bedrijven en proberen de rollen en principes van dit framework te navigeren om onze doelen te bereiken.
Helaas komt het vaak voor dat bedrijven de principes van Scrum verkeerd interpreteren en onjuist toepassen, waardoor gebruikers de vele voordelen van Scrum worden onthouden.
Deze leuke kleine gids is er dan ook helemaal op gericht je te helpen dit framework beter te gebruiken door uit te leggen waar het om draait, waarom er verschillende Scrum-rollen zijn, wat de verantwoordelijkheden binnen productmanagement zijn en hoe je kunt uitblinken in cross-functionele samenwerking.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wat is Scrum binnen productmanagement?
Velen van ons bespreken graag de rol van een productmanager binnen de realiteit van Scrum-processen en de Agile-methodologie (met andere woorden: wat de PM doet in een Scrum-team). In plaats van dit alleen uit te leggen, denk ik dat het eenvoudiger is om je gewoon te laten zien waar de PM zich bevindt in het organigram van het team.
Voor deze gids wil ik dit onderwerp echter vanuit de tegenovergestelde richting benaderen en laten zien hoe Scrum past binnen jouw realiteit als professional in productmanagement en hoe het je kan helpen je productdoelen te bereiken.
Ik wil beginnen met het bespreken van het effect van de kernprincipes van het Scrum-framework op de effectiviteit van ons werk.
Waarschijnlijk is het voortdurend leveren van waarde aan gebruikers het belangrijkste Scrum-principe voor ons. Hoe sneller mensen problemen kunnen oplossen, hoe beter je product zal presteren. Bovendien krijg je vroegtijdige feedback van mensen die de functie in een realistisch scenario hebben gebruikt.
Het tweede voordeel dat Scrum biedt, is flexibiliteit. Als de marktrealiteit verandert, kun je je er snel aan aanpassen door je productbacklog volledig te vernieuwen en nieuwe functies in de volgende sprint aan je team over te dragen (iets waarbij AI bij sprintplanning kan helpen).
Deze twee dingen zijn erg moeilijk (of vrijwel onmogelijk) te doen met traditionele frameworks zoals Waterval, waarbij alles qua scope vastligt en gebruikers pas helemaal aan het einde van de SDLC toegang krijgen tot het product.
Voorbeelden van productsucces dankzij de integratie van Scrum
Omdat ik jarenlang met Scrum-teams heb gewerkt, ben ik volledig bevooroordeeld ten gunste van dit Agile-framework. Neem mijn woord dus niet als absolute waarheid. Laten we in plaats daarvan kijken naar praktijkvoorbeelden waarin de overstap naar Scrum productteams hielp sneller succesvol te worden.
Microsoft Visual Studio: De belangrijkste tool van de technologiegigant voor het bewerken van code stond bekend om zijn zich herhalende cycli van productieproblemen, met releases vol fouten en ongelooflijk weinig releases. Vanaf het moment dat het productteam de voordelen van Scrum begon te benutten, zag het bedrijf een sterke toename in productstabiliteit, samen met veel frequentere releasecycli. Daarmee herstelde het zijn concurrentievermogen op de markt.
Spotify: De adoptie van Scrum door onze geliefde muziekstreamingdienst behoort tot de bekendste voorbeelden in de sector. Spotify had moeite om zich snel genoeg aan te passen en op te schalen om zijn procesproblemen op te lossen... totdat de organisatie Scrum invoerde. Wat Spotify onderscheidt, is echter de ontwikkeling van een eigen model voor Scrum-projectmanagement, gebaseerd op een groep autonome Agile-teams die toegang hadden tot alle expertise die ze nodig hadden om snel te experimenteren en feedback van gebruikers te verwerken.
ING: De Nederlandse bankgigant behoorde tot de eerste financiële instellingen die inzagen dat de toekomst van het bankwezen digitaal is. Ze realiseerden zich ook dat hun zeer traditionele projectmanagementprocessen niet geschikt waren voor softwareontwikkeling. Daarom namen ze snel lean- en Scrum-methodologieën over en werden ze, niet verrassend, leiders op het gebied van e-banking.
Belangrijkste rollen in Scrum-productmanagement
Als je als PM besluit dat Scrum de juiste aanpak is, vind je hier een kort overzicht van de belangrijkste rollen binnen dit framework, zodat je onderscheid kunt maken tussen je rol als productmanager en die van producteigenaar binnen Scrum.
Laat me beginnen met de rollen. Een typisch Scrum-team bestaat uit de volgende personen:
- Scrummaster: Deze persoon helpt het team de Scrumregels te volgen en hun processen te optimaliseren.
- Product Owner: Deze persoon vertegenwoordigt het bedrijf en de gebruikers in het Scrumteam. Product Owners beheren de backlog en stellen sprintdoelen en prioriteiten voor user stories vast.
- Scrumteam: Je ontwikkelaars, ontwerpers, QA-specialisten en andere specialisten die het product bouwen.
Wat het Scrumteam betreft, kunnen daar nog veel andere soorten specialisten deel van uitmaken. Het concept van multifunctionele teams gaat ervan uit dat het team onafhankelijk is wat betreft toegang tot professionele expertise. Dus als je product bijvoorbeeld sterk gericht is op analyses, kun je ook een data-analist in het team hebben.
Productmanager versus Product Owner: Wat is het verschil?
De definitie van product owner die ik gaf, kan je enigszins in verwarring brengen, omdat deze sterk lijkt op wat een productmanager doorgaans doet.
Wat is in dit geval het verschil tussen een productmanager en een product owner?
Om het verschil te begrijpen, bekijken we eerst de belangrijkste verantwoordelijkheden van elk van beide.
Productmanagers
- Productverkenning uitvoeren en de behoeften en pijnpunten van klanten begrijpen.
- De productvisie en de richting bepalen die het team zal volgen.
- Productoplossingen bedenken die aan de behoeften van klanten kunnen voldoen.
- Het productopleveringsproces leiden.
- Het product in kleine stappen verfijnen op basis van feedback van klanten en datagedreven besluitvorming.
- De productvisie en de uitvoering binnen de hele organisatie beheren.
Product Owners
- De productbacklog creëren en onderhouden.
- Optreden als enige bron van waarheid op het gebied van strategie, ontwerp en bedrijfslogica voor het Scrumteam.
- Items in de productbacklog prioriteren en het team duidelijkheid geven over wat belangrijk is.
- Acceptatiecriteria voor functies bepalen en de sprintresultaten op basis daarvan accepteren.
- Teamleden deblokkeren door vereisten te verduidelijken en de daarmee samenhangende problemen op te lossen.
- Deelnemen aan Scrum-events en optreden als de stem van het bedrijf en de klanten binnen het team.
Zoals we kunnen zien, doen de meesten van ons dingen die in beide lijsten voorkomen. Dat is heel normaal en gebruikelijk, omdat velen van ons tegelijkertijd als productmanager en product owner optreden.
Het belangrijkste verschil tussen die twee is dat productmanagement een beroep en vaardighedenpakket is, terwijl product ownership een rol in het Scrumteam is.
Maar wat betekent dat?
Het betekent dat de product owner geen productmanager hoeft te zijn. In een kleine startup, waarin je naast drie ontwikkelaars ook een CEO hebt, neemt de CEO de rol van product owner op zich door de ontwikkelaars een geprioriteerde backlog te geven.
De omgekeerde situatie is ook mogelijk. Je kunt productmanager zijn zonder product owner te zijn. Ik ben daar een goed voorbeeld van, omdat een van mijn oude teams geen Scrum gebruikte. Geen Scrum betekent geen product owner in het team. We volgden wel lean- en Agile-principes.
Om je een beter inzicht te geven in het verschil tussen deze twee, volgt hier een vergelijking naast elkaar van wat ze doen.
Maar wat was nu precies het nut van een speciale rol in het Scrumteam? Hadden ze niet gewoon kunnen samenwerken met productmanagers die geen deel uitmaken van het team? Ik vind het antwoord van Teresa Torres hierop erg goed.
De belangrijkste reden voor een specifieke productrol in het Scrumteam is dus het bijdragen van interne productkennis en expertise en het verder versterken van de multifunctionaliteit.
Hoe de productmanager samenwerkt met Scrumteams
Als je hebt besloten het pad van Scrum te volgen, moet je weten hoe je lid van het team kunt zijn en hoe je met je collega's kunt samenwerken. Laat me daar voor elk Scrum-event en artefact een kort overzicht van geven.
- Dagelijkse Scrum (ook wel dagelijkse bijeenkomsten): Het belangrijkste werk dat je tijdens deze tijdgebonden vergaderingen doet, is het beantwoorden van productgerelateerde vragen van je ontwikkelingsteam en het wegnemen van blokkades.
- Sprintplanningsvergadering: Hier ben jij degene die het doel van de Sprint bepaalt door duidelijk te definiëren wat je verwacht op het gebied van de functies die je wilt opleveren.
- Sprintretrospective: De processen die je gebruikt om prioriteiten en vereisten aan het team over te dragen, kunnen hun effectiviteit maken of breken. Je kunt deze vergadering dus gebruiken om feedback van het team te verzamelen en je processen te verbeteren.
- Sprintreview: Hier is het jouw taak om de voltooide functies van de Sprint te accepteren en het team feedback te geven op hun werk.
- Productverfijning: Jij bent de eigenaar van deze vergadering en moet de tijd die voor jou is gereserveerd gebruiken om de prioriteiten en details van de gebruikersverhalen die je voor het team hebt te bespreken. Moedig het team altijd aan om je vereisten kritisch te bekijken en “productbugs” te vinden die je over het hoofd hebt gezien.
- Productbacklog: Het is jouw verantwoordelijkheid om de productbacklog te beheren en deze overzichtelijk en geprioriteerd te houden, omdat zij hun Sprint daarop zullen baseren.
- Sprintbacklog: Deze is niet van jou. Je belangrijkste samenwerkingspunt is het begeleiden van het team bij het kiezen van de juiste verhalen voor de Sprintbacklog, zodat zij hun Sprintdoel kunnen behalen.
Daarnaast doe je andere soorten productwerk, zoals stakeholdermanagement of productontdekking. Als lid van het Scrumteam is het jouw taak om het team op de hoogte te houden van zowel de behoeften van stakeholders als die van gebruikers, nadat je deze hebt verduidelijkt.
Als je bijvoorbeeld een interview met een gebruiker hebt en ontdekt dat de gebruikerservaring van je inlogproces over het algemeen verwarrend is, is het belangrijk om deze informatie met het team te delen. Zo zorg je ervoor dat zij tijdens volgende sprints aandacht besteden aan dat onderdeel.
Beste werkwijzen voor Scrumproductmanagement
Hoewel productmanagement eenvoudig lijkt wanneer je het bekijkt door de lens van Scrum (en Agile-ontwikkeling in het algemeen), maken we tijdens ons werk binnen zelforganiserende teams veel fouten.
Hier zijn daarom enkele beste werkwijzen voor Scrum die je kunnen helpen deze fouten te voorkomen:
- Stel duidelijke verwachtingen: De grootste fout die je kunt maken, is je team vage prioriteiten en vereisten geven. Onduidelijkheid is een belangrijke oorzaak van vertragingen in de ontwikkeling en spanningen tussen jou en het team. We gaan binnenkort uitgebreid in op hoe je dit kunt bereiken.
- Maak geen misbruik van aanpassingsvermogen: Het is geweldig dat je van koers kunt veranderen, maar dat kun je alleen doen in je productbacklog, niet in de sprintbacklog. Zodra de sprint begint, mag je er geen verhalen aan toevoegen of uit verwijderen. Dat verstoort de plannen en voortgang van je team en leidt tot onafgemaakte sprints.
- Creëer een emotioneel veilige omgeving: Je bent lid van het team, niet hun baas. Zet je team dus niet onder druk om grotere toezeggingen te doen of eerder klaar te zijn. Scrumgidsen overal ter wereld, waaronder die van Scrum.org, leggen sterk de nadruk op het onderhouden van gezonde relaties met je teamgenoten, omdat dit een van de hoekstenen van effectieve samenwerking is.
Op basis van mijn ervaring zijn deze drie beste werkwijzen de belangrijkste. Maar als je meer tips wilt over Agile-werkstromen en beste werkwijzen voor Scrum voor productmanagers, bekijk dan zeker onze aparte gids over Agile productmanagement.
De productbacklog effectief beheren
Zoals ik eerder al aangaf, is duidelijkheid bieden aan je team een van de belangrijkste taken van een productmanager. Het goede nieuws is dat je productbacklog waarschijnlijk het beste hulpmiddel is om dit te bereiken. Hier zijn enkele tips voor het beheren van je productbacklog die je daarbij kunnen helpen:
Verfijningssessies: Hoe goed je je gebruikersverhalen ook schrijft, je zult er “bugs” in achterlaten en je wilt dat je ontwikkelingsteam deze controleert en onder je aandacht brengt. Daarnaast ben je geen ontwikkelaar en schrijf je mogelijk vereisten die moeilijk te implementeren zijn. Ook daar zal je team je tijdens het verfijningsproces op wijzen.
Prioriteringstechnieken: Maak gebruik van de vele prioriteringskaders om te bepalen welke functies belangrijker zijn dan andere. Mijn persoonlijke favoriet is MoScoW vanwege de eenvoud.
Afstemming op routekaart en visie: De epics en verhalen in je backlog moeten de algemene productdoelen en meetwaarden weerspiegelen die je wilt behalen. Zorg er dus voor dat je je routekaart voortdurend bekijkt wanneer je iets aan de backlog toevoegt.
Het meest voor de hand liggende teken dat een organisatie geen duidelijkheid heeft, is wanneer je door de organisatie heen verschillende mensen vraagt wat volgens hen de succescriteria zijn voor wat als volgende grote mijlpaal moet worden opgeleverd, en je verschillende verhalen begint te horen.
Belanghebbenden op één lijn brengen in Scrum
De essentie van de rol van een productmanager in Scrum is dat je in feite de verbindende schakel bent tussen het zelforganiserende team en de buitenwereld, of dat nu gebruikers, belanghebbenden of andere teams zijn.
Naast je reguliere taken op het gebied van stakeholdermanagement als PM, moet je die informatie dus ook terugkoppelen aan je team, en andersom. Er zullen ook gevallen zijn waarin je informatie van het team moet terugkoppelen aan belanghebbenden.
Een goed voorbeeld is het ontstaan van technische uitdagingen, zoals problemen met continue integratie, die invloed kunnen hebben op de planning of scope van een bepaalde functie. Dit is iets wat je met de belanghebbenden moet bespreken, waarna je de nieuwe planning/scope accepteert of met een andere oplossing komt (bijvoorbeeld door het team te versterken met meer expertise op dat gebied).
Er zijn ook gevallen waarin je team een interessant idee voor een functie of oplossing heeft bedacht dat het waard is om aan de roadmap toe te voegen. Ook hier koppel je deze informatie terug aan de belanghebbenden en beslis je of je het uiteindelijk wel of niet aan je plan toevoegt.
Het belang van Agile-roadmapping in Scrum
Hoewel Agile-roadmaps niet direct onderdeel zijn van Scrum, zijn ze wel een van de hulpmiddelen die Scrum mogelijk maken. Wat is immers het nut van iteratieve planning als je voor je product het watervalraamwerk gebruikt in plaats van een Agile-roadmap?
In dat geval zou wat je ook Scrum-productstrategie noemt simpelweg betekenen dat je een vooraf gedefinieerd en vast plan met de klassieke SDLC opdeelt in onderdelen van 2 weken (of hoe lang je sprints ook duren). Om Scrum betekenisvol te maken voor je team, moet je dus interactieve Agile-planning toepassen en een roadmap opbouwen die in de loop van de tijd kan veranderen.
Om je Agile-roadmap goed te laten aansluiten op de Scrum-processen van je team, raad ik je het volgende aan:
- Koppel roadmapitems (meestal Epics) aan userstories in de productbacklog. Zo ontstaat er een directe verbinding tussen je tactische werk (stories) en je strategie (roadmap).
- Presenteer je roadmap aan je Scrum-team. Zo weten zij waar het product naartoe gaat en houden ze rekening met aankomende functies bij het ontwerpen van de frontend- of backendarchitectuur.
- Maak gebruik van gespecialiseerde tools zoals Jira, Monday.com en Clickup om je proces voor roadmapping en backlogbeheer te stroomlijnen.
Wat het laatste punt betreft: deze drie tools zijn de tools die ik in de praktijk heb gebruikt. Er zijn echter nog veel andere productmanagementtools die je in plaats daarvan kunt overwegen.
Uitdagingen in Scrum-productmanagement
Hoewel Scrum een geweldig raamwerk is om je productdoelen te bereiken, brengt het gebruik van dit raamwerk ook zijn eigen uitdagingen met zich mee, zoals:
- Je team of je belanghebbenden begrijpen misschien niet waar Scrum over gaat. Dit kan uiteraard leiden tot aanzienlijke problemen bij de invoering van Scrum, zoals het weigeren om bepaalde artefacten te gebruiken. Ik raad aan dit voor te zijn door de gewenste 'eindsituatie' te illustreren van hoe het team en de workflow eruit zullen zien wanneer het framework volledig is geïmplementeerd.
- Mensen (en jij) kunnen in de war raken over je rol binnen en buiten het team. Elk bedrijf waarvoor ik in mijn carrière heb gewerkt, had zijn eigen opvatting over wat een producteigenaar binnen Scrum doet. Het is het beste om voor je team vast te stellen wat het wel en niet is.
- De omvang van de functies waaraan je werkt, heeft de neiging eindeloos uit te breiden. Niet verrassend maakt dit het erg gemakkelijk om in het gebied van scope creep terecht te komen. Scrumteams moeten meedogenloos zijn in wat ze op zich nemen en waar ze 'nee' tegen zeggen.
- De roadmap kan gemakkelijk ontsporen. Omdat je een relatief onafhankelijk team hebt dat kan kiezen waaraan het werkt, kan het gebeuren dat het dingen bouwt die buiten je roadmap vallen. Het einddoel duidelijk voor ogen houden is essentieel om deze valkuil te vermijden.
Hoewel deze uitdagingen vrij gebruikelijk zijn, is het goede nieuws dat de PM slechts een paar sprints nodig heeft om het Scrum-proces te doorgronden en de overgrote meerderheid ervan te overwinnen. Voor degenen die hun expertise willen formaliseren, kan leren hoe je Scrum Master wordt leiders een geloofwaardige voorsprong geven bij het begeleiden van hun teams door het framework.
Conclusie
Scrum is een van de beste geschenken voor productmanagers. Dankzij de balans tussen op de lange termijn wendbaar zijn en binnen korte iteraties strikt te werk gaan, kun je de chaos van een ontwikkelproces zonder framework vermijden, terwijl je de mogelijkheid behoudt om de koers van je product aan te passen op basis van de reactie van de markt.
We hopen dat je onze gids geweldig vond. Zo ja, vergeet dan niet je te abonneren op onze nieuwsbrief voor meer bronnen en gidsen over productmanagement, plus de nieuwste podcasts, interviews en andere inzichten van leiders en experts uit de sector.
Veelgestelde vragen:
Wat is de rol van een productmanager in Scrum?
Productmanagers, die binnen het Scrumteam doorgaans de rol van producteigenaar vervullen, zijn verantwoordelijk voor het bieden van duidelijkheid aan het team door de productplannen, prioriteiten en benodigde functievereisten met hen te delen.
Waarin verschilt Scrum van andere Agile-methodologieën binnen productmanagement?
In tegenstelling tot Kanban of andere Agile-frameworks is Scrum gestructureerder en bevat het duidelijke regels voor het organiseren van het werk binnen het team met behulp van de Scrum-gebeurtenissen (dagstarts, verfijningssessies enzovoort) en artefacten (sprintbacklog, productbacklog enzovoort).
Wat zijn de meest voorkomende uitdagingen bij productmanagement met Scrum?
De meest voorkomende uitdaging is dat je team en belanghebbenden de regels en artefacten van het Scrum-framework verkeerd interpreteren en de regels ervan proberen aan te passen voordat het bedrijf de kans heeft gehad om zich aan dit nieuwe framework aan te passen.
Kan een productmanager ook producteigenaar zijn?
Ja. Productmanager is een beroep. Producteigenaar is een rol binnen een Scrumteam. Meestal is de producteigenaar in het team een productmanager. Soms, vooral bij kleine start-ups, kunnen CEO’s de rol van producteigenaar in het team vervullen.
