Product Management Auckland 15 Oct 2015 - Having Visions – The Deep Dive
•Descargar como PPTX, PDF•
0 recomendaciones•399 vistas
Slide deck from talk given at the Product Management Auckland Meetup on 15 Oct 2015. Talk synopsis: The role of the product owner is probably the least well understood of the Scrum roles. In an attempt to rectify this, Anthony Marter will present an exciting journey through what the heck a Product Owner does in the enterprise, why the role has become distinct to that of the Product Manager and Business Analyst and why the backlog is the least of your worries! About 3 years ago Anthony found himself being offered the role of Product Owner at Fiserv and was somehow crazy enough to take it on, despite not really knowing anything about what the job entailed. Since then with the help of others he's been trying to figure it out. More recently he's moved to Orion Health to try to help them understand and develop the Product Owner role.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Product Management Auckland 15 Oct 2015 - Having Visions – The Deep Dive
Similar a Product Management Auckland 15 Oct 2015 - Having Visions – The Deep Dive (20)
Último
Último (20)
Product Management Auckland 15 Oct 2015 - Having Visions – The Deep Dive
- 1. ANTHONY MARTER/PRODUCT OWNER PRODUCT MANAGEMENT AUCKLAND OCT 2015 HAVING VISIONS – THE DEEP DIVE THE ROLE OF THE PRODUCT OWNER IN THE AGILE ENTERPRISE Product Management Auckland @pmauckland @antzzzm LinkedIn
- 2. Page 2 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Product Ownership at scale – Fiserv: 1 team -> 6+ teams – Orion: Cross organisation release train • Building products • Large, monolithic products* • Multiple teams working on a single release WHERE AM I COMING FROM?
- 3. Page 3 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Represents the stakeholders in delivery team • Establishes shared understanding of work with team • Maintains the backlog for team • Accountable for value delivered by team THE ROLE OF THE PRODUCT OWNER
- 4. Page 4 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE PRODUCT OWNER BASICS Dev Dev Dev Dev QA QA BA Scrum Master The Team Product Owner ‘The Business’ ‘Stakeholders’
- 5. Page 5 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE SINGLE WRINGABLE NECK? VELOCITYBLAME SCAPEGOAT
- 6. Page 6 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE SHARED UNDERSTANDING? WHAT I KNOW WHAT YOU KNOW WHAT WE KNOW • Between the Business and the Delivery Team(s) • Specification by Example • Workshops • Never Assume
- 7. Page 7 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Enable teams to be Agile/Self Organising – shift from build this to solve this problem • Motivate and Empower the team • Speaking the same language • Harness the knowledge and creativity of the teams COMMUNICATING VISION Build This Solve This Problem
- 8. Page 8 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • What is the problem the team(s) are trying to solve? • Did the user need a car? Or just a means of transport? • Tell -> Enable • Don’t assume empowerment WHAT IS VISION?
- 9. Page 9 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • At scale – market is distant • Key stakeholders often also distant • Work comes in chopped up pieces, context is missing • Push back, question, get to the why ENABLING TEAMS WHY?
- 10. Page 10 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Prioritised (by Value) • Sized • EVERYTHING is in the Backlog • There is only 1 Backlog THE BACKLOG Priority Size
- 11. Page 11 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE CREATING THE BACKLOG 'Business' (Prod Mgr?) Idea Product Owner Backlog
- 12. Page 12 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE WHERE DOES THE BACKLOG COME FROM? Backlog Architecture Market/ Features Quality Tech Debt Team Happiness Support Delivery Engineering Innovation UX Security/ Compliance ...
- 13. Page 13 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE CREATING THE BACKLOG Copyright Google Ventures/IDEO
- 14. Page 14 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Biggest bang for the buck (WSJF) • Multiple demands – short vs long term velocity • Product Owner is a role, not a rule book PRIORITISING THE BACKLOG
- 15. Page 15 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Unsized backlog has limited value • Detailed sizing – waste of time • Affinity sizing or similar technique (but revalidate) SIZING THE BACKLOG
- 16. Page 16 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE CONE OF UNCERTAINTY Shipping Roadmap Delivery Grooming Building
- 17. Page 17 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE COMMUNICATING THE BACKLOG – NATURE ABHORS A VACUUM
- 18. Page 18 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Breakdown/Grooming • Answering questions – ‘rightness’ vs speed • ‘Principled Pragmatism’ • Being available to team DELIVERING THE BACKLOG 80/20 (50/50?)
- 19. Page 19 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Everything can be broken down • Barriers: Architecture, Compliance, Delivery Overheads • Creativity/Pragmatism • Goal: Turn shipping into a business decision rather than a technical decision DELIVERING WORKING SOFTWARE Product Owners Scrum Masters
- 20. Page 20 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Launch Planning • Metrics • Learning/Retrospectives FEEDBACK “The value of a metric is proportional to the value of the business decision that can be made using it” - Gojko Adjzic
- 21. Page 21 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE VALUE Value Architecture Market/ Features Quality Tech Debt Team Happiness Support Delivery Engineering Innovation UX Security/ Compliance ...
- 22. Page 22 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE DANGER – ICEBERG AHEAD Hey, Can we just add… Support Integration End of life Testing Customer testing
- 23. Page 23 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Security/Compliance • Architecture/Technical Debt • Minimum Viable Product • Everything has value – how can the value be represented? DEALING WITH ABSOLUTES ROCK HARD PLACE
- 24. Page 24 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Not just the affliction of the Product Manager • Product Owner Credibility/Empowerment • Transparency around Value • ‘Sliders’? ‘DR NO’ Quality Timeliness Team Happiness Technical Debt Reduction
- 25. Page 25 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Product Manager – deep into market (NZ context – not always co-located) • Business Analyst – part of the team finding solutions • YMMV – how big are the roles in your organisation? PRODUCT MANAGER? PRODUCT OWNER? BUSINESS ANALYST? Product Manager (Subject Matter Expert) Business Analyst (part of team) Product Owner Product Owner Business Analyst (part of team) Roadmap Scrum Events Product Manager (Subject Matter Expert)
- 26. Page 26 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE SCALING 1:2
- 27. Page 27 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE SCALING Chief Product Owner (Spotify) Software Product Manager (Fiserv) Solution Product Owner (Orion Health) Capability PO Team PO Component PO Capability PO Team PO Component PO Capability PO Team PO Component PO Capability PO Team PO Component PO
- 28. Page 28 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Team Lead/Architect as Product Owner • Scrum Master as Product Owner (or vice-versa) • Time-poor business stakeholder • Not co-located ANTI-PATTERNS Awesome
- 29. Page 29 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Product Owner as ‘cat herder’ • Role can be only one that has 1:1 mapping to product/client requirements • Gap filler • Symptom of misalignment between delivery org and market ANTI-PATTERNS Awesome
- 30. Page 30 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Just all about the features? Multiple Backlogs/Owners? • Product Owner must balance short and long term velocity – trust/credibility • Non-functional requirements generally impact long term velocity • Transparency is important – facilitator role ANTI-PATTERNS Awesome
- 31. Page 31 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE • Business Analysts (must be ‘converger’) • Technical Product Managers (credibility with developers) • Senior Developers/Testers (‘That guy/girl’) • Energy/Enthusiasm/Positivity WHERE TO FIND PRODUCT OWNERS?
- 32. Page 32 • 2015 © Orion Health™ group of companies THINKING SOFTWARE FOR LIFE QUESTIONS? WHAT?
Notas del editor
- Worked with Fiserv Product Mgmt to scale the role, built PO/BA team Software industry, products (not services) Internal, not client facing Orion – transforming from services led to product led
- Not only applicable to software PO is not the only bridging role, peers can be architects, UX, compliance etc
- Single wringable neck is about maximising velocity, not about being a manager/scapegoat Speed of decision making is key, generally with limited information available
- Go read the Gojko book…
- Everything in a single backlog is key – ultimately everything is for the clients/end users Backlog is not static
- To enable regular delivery this must be a continuous process
- More of an art than a science – but must be transparent Always gotta have a story for why priority is what it is – story may change
- Interplay between prioritisation and sizing (WSJF) Rough is enough – never have enough info so don’t try
- Backlog transparency is critical to getting buy in and adherence, especially in a large org (or one early in Agile transformation)
- Team level participation – prioritise availability Must be able to and be empowered to make swift decisions (forgiveness rather than permission) Gotta stick to guns and maintain independence – but must also maintain credibility with team
- Scrum masters/coaches are your friends – they can influence team behaviour ‘Team leads’ or managers harder to deal with, can skew team behaviour
- Overlap of PO role into Product Mgmt – PO is closer to state of actual delivery PO should be closely involved in retro as their decisions may have critically influenced outcomes (learning opportunity, not whipping!)
- Many factors – not just features Work with stakeholders to establish value Balance is critical to establishing credibility
- ‘Security is a business requirement’ Product Managers can be tough on MVP Must drill into the value of each item, guide stakeholder on journey to understanding tradeoffs
- Mostly a team level thing – PO must be viewed as an enabler, not as a filter Especially must be viewed as impartial – not just a representative of ‘Product Management’ Transparency is key to getting past this – vision helps too
- 1 PO per 2 teams max – generally understood rule. Any more thinly spread and teams have to start organically taking on part of PO role