Er zijn veel mislukkingen van Product Owner. Gezien het feit dat Scrum een raamwerk is met een precieze en beknopte maar korte “handleiding”, zou dit effect niemand moeten verbazen.
Ontdek met mij drie wijdverspreide voorbeelden van hoe Product Owners hun team in de steek laten in drie korte videoclips van in totaal 6 minuten en 9 seconden.
De Scrum-gids over de Product Owner
Laten we onze herinneringen aan het werk van de Product Owner opfrissen:
De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product als resultaat van het werk van het Scrum Team. Hoe dit wordt gedaan, kan sterk verschillen tussen organisaties, scrumteams en individuen. […] Om Product Owners te laten slagen, moet de hele organisatie hun beslissingen respecteren. […] De Product Owner is één persoon, geen commissie. De Product Owner kan de behoeften van veel belanghebbenden vertegenwoordigen in de Product Backlog. Wie de Product Backlog wil veranderen, kan dit doen door te proberen de Product Owner te overtuigen.
Bron: De Scrum-gids over de Product Owner.
Drie wijdverbreide mislukkingen van producteigenaren
Laat me je door de vaak waargenomen antipatronen van Product Owner ‘leiden’, van te grote Product Backlogs tot prioritering per proxy tot de alwetende Product Owner:
Te grote productachterstanden
De Product Backlog van uw team bestaat uit honderden inzendingen, van gebruikersverhalen tot ideeën tot hypothesen en experimenten tot documentatiefragmenten – noem maar op. Alles in de Product Backlog dumpen – waarschijnlijk in naam van transparantie – vormt om verschillende redenen een enorme uitdaging:
- Garbage in, garbage out: het vergroten van de hoeveelheid input verhoogt niet de uitkomst van het werk van het Scrum-team. Met andere woorden: “bezig” zijn ≠ waarde bieden aan klanten en de organisatie.
- De Product Backlog is de beste kans van het Scrum Team om voor elke Sprint de beste manier te vinden om het leven van uw klanten gemakkelijker te maken. Daarom heb je signalen nodig, geen ruis. Te veel inzendingen kunnen ervoor zorgen dat teamgenoten minder geneigd zijn om actief deel te nemen aan de verfijning van de Product Backlog.
Tip: Pas het Goudlokje-principe toe – “precies goed” – en vind je balans als team. Gooi dan de rest weg. U wilt een actiegerichte Product Backlog die acht tot misschien twaalf weken werk omvat. Wees echter gewaarschuwd: typische bezwaren tegen het verwijderen van onnodige Product Backlog-items variëren van “we kunnen ze niet verwijderen – het is onze documentatie zoals vereist door het bestuur” tot “we hebben zoveel werk geïnvesteerd in het creëren ervan”. (Het eerste is een vorm van verliesaversie, het tweede een manifestatie van het sunk cost-syndroom.)
Prioritering door proxy – Fouten bij producteigenaar
Product Owners vertegenwoordigen geen commissie – zie hierboven – en zijn daarom uitsluitend verantwoordelijk voor het maximaliseren van de waarde gecreëerd namens de klanten. Desalniettemin zien belanghebbenden in veel organisaties Product Owners vooral als een tactische rol, waarbij ze vereiste documenten in Jira-taken veranderen.
Er zijn veel redenen voor die houding, van een vroege fase van een transformatie – dus minder bedreven zijn in Scrum – tot een algemeen gebrek aan vertrouwen in de capaciteiten van het Scrum-team. Ongeacht de reden, producteigenaren in deze situatie moeten samenwerken met hun Scrum Masters en proberen de rol op de beoogde manier te vervullen. Anders kunt u ernstige gevolgen ondervinden:
- Je komt waarschijnlijk in een feature factory terecht.
- Waarschijnlijk verzendt u het organigram in plaats van echte waarde voor de klant te creëren. (Conway’s wet: “Elke organisatie die een systeem ontwerpt (breed gedefinieerd), zal een ontwerp produceren waarvan de structuur een kopie is van de communicatiestructuur van de organisatie.”)
- Als je gemeten financiering voor het Scrum Team oefent, is het alsof je Waterfall 2.0 via de achterdeur introduceert.
Ik weet wat ik moet bouwen – volg mij!
In dit PO-antipatroon weten Product Owners het beste waar ze heen moeten om waarde te creëren voor de klanten. Ze geven het ‘waarom, wat en hoe’ en twijfelen er niet aan dat ze het meest geschikt zijn om investeringsbeslissingen te nemen. Ze verwachten dat de rest van het Scrum-team in de rij zal vallen en hun voorbeeld zal volgen.
Het probleem is dat deze houding succeskritische checks & balances nutteloos maakt. De ontwikkelaars moeten de producteigenaar uitdagen: “PO, is dit echt het beste gebruik van onze tijd?” Als Scrum-team willen we dat onze producteigenaren verliefd worden op de problemen van onze klanten, niet op hun oplossingen.
De conclusie: drie wijdverbreide mislukkingen van producteigenaren
Toegegeven, de rol van Product Owner is de meest uitdagende Scrum-verantwoording, en hoe hoger de verwachtingen, hoe gemakkelijker het is om ze te falen. Toch is het concept van continue verbetering ook van toepassing op de rol van Product Owner. De bovenstaande voorbeelden van Product Owner-antipatronen kunnen een startpunt zijn. Neem als Product Owner gewoon contact op met je teamgenoten en vraag om ondersteuning. Scrum is tenslotte een teamsport.
Welke mislukkingen van Product Owner heb je opgemerkt? Deel ze met ons in de comments.
CreditSource link
