Hands-on Agile Webinar #6: Product Owner Anti-Patterns
•Transferir como PPTX, PDF•
3 gostaram•2,253 visualizações
The sixth Hands-on Agile webinar addresses product owner anti-patterns. Learn 12 ways to improve a product owner’s skill set and when you — as the scrum master or scrum team — should reach out to your product owner and offer support.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Hands-on Agile Webinar #6: Product Owner Anti-Patterns
Semelhante a Hands-on Agile Webinar #6: Product Owner Anti-Patterns (11)
Mais de Stefan Wolpers
Mais de Stefan Wolpers (20)
Último
Último (20)
Hands-on Agile Webinar #6: Product Owner Anti-Patterns
- 2. The product owner according to the scrum guide stefan@age-of-product.com
- 3. The Realm of the Product Owner stefan@age-of-product.com
- 4. Product Owner Anti-Patterns: The Product Backlog stefan@age-of-product.com
- 5. #1: The Oversized Product Backlog stefan@age-of-product.com
- 6. #2 Product backlog items become artefacts stefan@age-of-product.com
- 7. #3: YES – or being everyone’s darling – does not scale stefan@age-of-product.com
- 8. #4: Prioritization by Proxy stefan@age-of-product.com
- 9. 5. The Omniscient Product Owner stefan@age-of-product.com
- 10. Product Owner Anti-Patterns: The Sprint Planning stefan@age-of-product.com
- 11. #6: No Sprint Goal stefan@age-of-product.com
- 12. #7: The Pushy Product Owner stefan@age-of-product.com
- 13. #8: Toying with the Definition of Ready stefan@age-of-product.com
- 15. #9: The Absent Product Owner stefan@age-of-product.com
- 16. #10: The Interfering Product Owner stefan@age-of-product.com
- 17. Product Owner Anti-Patterns: The Sprint Review stefan@age-of-product.com
- 18. #11: The Selfish Product Owner stefan@age-of-product.com
- 19. #12: The Broadcasting Product Ownerstefan@age-of-product.com
- 20. Product Owner Anti-Patterns: Summary stefan@age-of-product.com
- 21. The Age of Product Youtube Channel stefan@age-of-product.com
- 22. Contact Information StefanWolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 17,800-plus peers) Slack: https://hands-onagile.slack.com/ (Join 3,400 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
- 23. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
Notas do Editor
- Welcome to I am your host Stefan Today we talk about product owner anti-patterns… Q&A at the end Please use the Q&A tools that Zoom provides
- Let us start with the Scrum Guide: => slide In other words, the product owner has ideas, or identifies ideas, or at least he or she curates suitable ideas from wherever And validates them whether those ideas are “product backlog worthy” or not Interestingly, the scrum guide also states: „The Product Owner may do the above work, or have the Development Team do it.“ Which is really not helpful to support the understanding the role of the PO, particularly on the management side In my experience, this approach turns the product owner into the Achilles heel — or bottleneck by design — of the whole process. If you "remove" the PO as an independent and respected role, for example, by sticking with your organizations’s stage-gate process, Scrum easily mutates into a Waterfall 2.0 process.
- Hence — in my mental model of agile product development — The product owner covers by far the most extensive ground of all roles.
- My dirty dozen product owner anti-patterns… Let us start with product backlog As the saying goes: garbage in, garbage out.
- NOTE: No more than 4-8 maybe 12 weeks worth of work: Do not dump ideas in the product backlog — it is not random assortment of tickets (=> best use of the scrum team’s resources) No alignment w/ roadmap, strategy or vision Being “busy” ≠ providing value to customers & the organization OUTCOME, not output Delete the rest Objection: We cannot delete them — it is our documentation #LossAversion we put in a lot of work… #SunkCosts
- PBI = Token 4 discussion: co-creation, discussion, shared understanding => if something looks “finished”, there is no feedback! Backlogs = forensic analysis tool for organizational debt User story ≠ jira-based requirement document Make issues in Jira fit to BE DELETED Counter argument: required by Governance / documentation => not the purpose of Jira Apply the Goldilocks principle: just right — find your balance
- The product owner has a noble task: Guardian of the product backlog Again, garbage in, garbage out Aspiring to be everybody’s darling leads to mediocre product => it does not scale Learn how to say “no” w/o burning bridges Move discussions with stakeholders further to the left
- LeSS: ONE product owner No product design by committee => feature factory Conway's law: shipping the org-chart (1967) "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Stage-gate through the backdoor Nice waterfall 2.0
- PO w/o any doubt where to go Does not need the team — collaboration only slows him/her down The PO provides the “Why + How + What” at the same time (=> not uncommon for former engineers who became PO) Thinking in solutions, not problems Dominant PO PLUS submissive team = bad combination (checks and balances gone = the development team is supposed to challenge the PO)
- What comes first: team selects stories from the product backlog => PO wrap a sprint goal around them PO defines a sprint goal => team picks stories to match sprint goal? According to the Scrum guide: “Scrum Team also crafts a Sprint Goal“ Scrum is great to score matchpoints Matchpoints — for example, providing Paypal to customers — always equal simple sprint goals If finding a sprint goal is regularly a problem => for example, your product is late in the lifecycle => consider why you are using Scrum A metric to track could “have a meaningful sprint goal”
- Last time you took on 25 points, now it is only 17 — how come? First of all Scrum guide: “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team“ Utilization fetish by a pushy POs hence creates tensions, a chasm within the team, Sign of distrust: not a team player? Just a classic manager from the factory era — output is what matters? Probably misaligned incentives between PO and the team — is the PO polishing his or her CV for the next career step?
- “Definition of Ready” helpful => sets a quality standard => don’t ignore it What about ”last minute” changes? Okay to be flexible — don’t make it a habit! If everything is a last minute change — the Definition of Ready may become a defensive tool for the team. However, the DoR not a stage-gate => anti-pattern
- My dirty dozen sprint planning anti-patterns…
- No feedback to developers during the sprint => increased risk of not meeting the sprint goal The best product backlog refinement cannot answer all questions in advance — that would be way to granular! Delay in accepting tasks creates an artificial queue (=> nasty if QA is not yet largely automated) NOTE: “potentially shippable product increment at the end of a sprint” does not mean ≠ one deployment per sprint
- You can change the sprint backlog — if the teams agrees (=> adapt to change over following a plan.) However, no changes by the PO single-handedly, e.g. scope (=> sprint cancellation is the exception) Be pragmatic! Sometimes: – the scope needs to be reduced (for example, the team has to deal w/ team members on unexpected sick leave) – more refactoring needs to be accomplished prior to delivering a story – there is room for more
- There is no “I” in team The teams wins, the team loses Sprint review: a moment to shine for the development team and surprise customers & stakeholders Absolutely not a show to praise the product owner.
- The sprint review is a regular, repeating opportunity to realign the scrum team with customers & stakeholders ARE WE STILL ON THE RIGHT TRACK? Hence: • Let the team run the show (Show, don’t tell) • Even better: let the stakeholders or customers take the helm and run the sprint review — that’s the best way to get feedback If feedback is not actively sought after by the PO, the purpose of the sprint review is missed, the sprint review turns into a waste.
- Last webinar before the summer break I am still experimenting with the right format of webinars I am considering AMAs or inviting other speakers to join for specific topic Lastly, the youtube channel is starting to become useful — even if not all episodes are already available
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider