Waarom het ontwikkelen van product skills een team-verantwoordelijkheid is
In het constant veranderende domein van software productontwikkeling is het gemakkelijk om geobsedeerd te raken door Product Managers en Product Owners. Er zijn talloze workshops, boeken en cursussen ontworpen om deze rollen effectiever te maken. Maar laten we even stilstaan: Een onderzoek van Atlassian liet in 2019 zien dat de succesvolste teams zes keer zo vaak zeiden dat ze goed samenwerkten, vergeleken met teams die minder goed presteerden [1]. Dus, waarom zou je alleen de spits trainen terwijl je een heel team op het veld hebt staan?
Waarom investeren in collectieve product skills belangrijk is:
- Diverse oplossingen: Met meer hersenen in het spel maak je gebruik van een breder scala aan vaardigheden en perspectieven.
- Snelheid en behendigheid: Een collectief eigendomsmodel kan besluitvormingsprocessen aanzienlijk versnellen.
- Verminderde uitval: Het verspreiden van de verantwoordelijkheid voor het succes van een product kan leiden tot een gezondere, duurzamere werkomgeving.
Ooit zoemde in de agile techwereld de principes van Extreme Programming (XP) rond, een softwareontwikkeling methodologie die klanttevredenheid en iteratieve ontwikkeling benadrukte. Misschien gebruik je dagelijks ‘user stories’? Dat concept hebben we te danken aan XP. Een van de ideeën was om een directe communicatielijn te hebben tussen ontwikkelaars en gebruikers. “Het geheim van een succesvol project is om je team te laten praten met echte gebruikers," zei Kent Beck, een van de grondleggers van XP[^2]. In deze tijd was de rol van de Product Owner nog niet breed geïnstitutionaliseerd in organisaties. Ontwikkelaars, in direct contact met gebruikers, verkregen zo inzichten die niet volledig konden worden vastgelegd in documentatie. Deze praktijk leidde tot nauwkeurigere en gebruiksvriendelijkere software producten.
Scrum, een ander agile framework, heeft altijd gepleit voor het concept van het product als een 'gedeelde verantwoordelijkheid'. Het gaat niet alleen om de PO; het gaat om iedereen, van ontwikkelaars tot testers tot ontwerpers. In Scrum zijn ceremonies zoals Daily Standups en Sprint Reviews niet alleen statusupdates of beoordelingen, maar uitstekende kansen voor collectieve besluitvorming [^3].
In het boek "Shape Up" van Ryan Singer wordt het concept van kleine teams die in gerichte cycli werken aan verschillende componenten van een product verder uitgewerkt [^4]. Deze teams zijn niet zomaar 'code-monkeys'. Ze zijn architecten van hun delen van het product, verantwoordelijk voor zowel wat te bouwen als hoe het te bouwen en dat motiveert mensen nou eenmaal [^5]. Voor de meesten onder ons is dit wel bekend, toch zijn we nog steeds niet goed in staat om dit in de praktijk te implementeren.
Laten we het benaderen vanuit een praktijkvoorbeeld. In een bedrijf waar ik actief was, organiseerden we een hackathon. Hierin kregen teams volledige autonomie, en het was alsof we ze superkrachten hadden gegeven! Deze zelforganiserende teams kwamen binnen twee dagen met baanbrekende oplossingen voor realistische klantproblemen. Oplossingen die zelfs de strategische genieën in het bedrijf nooit hadden kunnen bedenken.
Het meest opmerkelijke was dat deze dynamiek eigenlijk de kern van Scrum belichaamt: een 'gedeelde verantwoordelijkheid' voor het product en zelforganiserende teams. In de normale scrum werkwijze kwamen we hier echter nooit aan toe, en de valkuil zat 'm in de rol van de PO en de teamindeling. De PO had te veel verantwoordelijkheden en te weinig tijd om echt naar het team te luisteren. En de teams waren niet ingedeeld met alle disciplines die nodig waren om snel en direct de juiste kennis te verspreiden.
Bij een ander bedrijf, was er een uitzonderlijk talentvolle Product Owner. Deze kerel was doelgericht en had een ongeëvenaard inzicht in de ongerealiseerde waarde die bij Sales op de plank lag. Hij had een hekel aan Scrum; de procesregels waren te beperkend en hij kwam niet genoeg aan strategie werk toe door de constante druk van het tweewekelijks ‘voeren’ van het team met backlog items. In plaats van zich te laten hinderen door de conventionele methodologie, verzamelde hij een klein, toegewijd team en werkte nauw samen met een Sales stakeholder. Binnen één kwartaal wisten ze een volledige automatisering van de advertentieplaatsingen te implementeren, zonder scrum. Het resultaat? Een explosieve toename van het advertentieaanbod dat door Sales kon worden verkocht en een veel efficiëntere operatie.
"Het is tijd om onze focus te verschuiven van individuele briljantie naar collectieve intelligentie"
Concrete tips voor het ontwikkelen van product vaardigheden in jouw team
Ik waardeer Scrum als een flexibel raamwerk, maar te vaak zie ik dat het spaak loopt door een te grote focus op proces en rollen, een gebrek aan focus op strategie en een schaarste aan goede Scrum Masters of Agile Coaches in de markt. Laten we ons richten op het oplossen van echte klantproblemen met het hele team, in plaats van ons te verliezen in procedurele details. Daarom ben ik voorstander van een combinatie van XP, Scrum en Shape-up. Gebruik de Shape-up pitches voor het uitwerken van je strategische briefings en voor de invulling van je portfolio managementproces. Verleng een ontwikkel iteratie naar 4-6 weken, voeg daar een twee-wekelijkse 'cool-down' periode aan toe voor onderhoud en refinement, en je hebt een model dat niet alleen flexibel is, maar ook op strategische waarde en operationele duurzaamheid is gericht. Dit geeft PM's en PO's meer focus om dieper in de strategie te duiken. En als je dan toch bezig bent, vergeet dan niet om die relevante stakeholder, business analist of klantenservice medewerker aan je team toe te voegen.
Voor Product Owners en Product Managers die hun game willen verbeteren, is er veel te leren van Extreme Programming (XP), Shape-Up en Scrum. Neem een pagina uit het XP-handboek en ga direct in gesprek met je gebruikers samen met je team; er is niets waardevoller dan firsthand feedback voor het creëren van nuttige user stories. Uit de Shape-Up methode, overweeg om je team een "shaped" probleem voor te leggen in plaats van een voorgeschreven oplossing. Dit geeft je team de autonomie om creatieve en effectieve oplossingen te vinden. En uit het Scrum-framework, vergeet niet dat het product een "gedeelde verantwoordelijkheid" is. Gebruik Daily Standups en Sprint Reviews niet alleen als statusupdates, maar als platforms voor collectieve besluitvorming. En als het nodig is, plan dan een strategische ‘brainstorm of design’ sprint. Niets is minder waardevol dan je team druk te laten zijn met werk om een proces te volgen. De volgende keer dat je een product training gaat volgen, neem je team dan mee of lees en bespreek samen een boek. Met deze tips ben je niet alleen een spelverdeler, maar ook een productleider.
Terwijl PM's en PO's cruciale componenten zijn in de machine van productontwikkeling, zijn ze niet de hele machine. Een auto rijdt niet alleen op een motor; het heeft wielen, tandwielen en tal van andere onderdelen nodig. Het bouwen van een geweldig product is een collectieve inspanning. Het is tijd om onze focus te verschuiven van individuele briljantie naar collectieve intelligentie.
Referenties:
[^1]: Atlassian. (2019). The Atlassian Team Playbook.
[^2]: Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2nd ed.). Addison-Wesley.
[^3]: Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
[^4]: Singer, R. (2019). Shape Up: Stop Running in Circles and Ship Work that Matters. Basecamp.
[^5]:Ryan, R. M., & Deci, E. L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American Psychologist.
Afbeelding Header: by Quino Al on Unsplash
