product ownership challenges
DESCRIPTION
These are the slides from my talk at the LESS 2011 conference in Stockholm, Sweden. Product Ownership is a multi-faceted responsibility that demands a broad set of perspectives combined with deep product and domain knowledge. Effective product ownership requires both an internal and an external perspective. The challenges are amplified for large complex organizations developing large complex products and systems. In different organizations, engineering, product management, user experience and other functional groups can all lay claim to the role with some legitimacy.This talk will describe the challenges of understanding product ownership in large organizations, and of filling the product owner role effectively. We present different models for filling the product owner role, including single product owner, proxy product owner, and product owner teams.TRANSCRIPT
Product Ownership Challenges in Large Organiza7ons
[email protected] @ken_power
• Is responsible for the success of the product
• Represents the user and customer
• Decides what features go into the product
• Writes requirements in the form of user stories
• Maintains the product backlog
• Responsible for priori7zing product backlog items
• Decides the order in which content is delivered
• Works with Delivery Team to determine specific itera7on content
• Communicates expecta7ons
• Defines project goals
• Sets project vision
• Be available to the Delivery Team throughout the Itera7on
• Point of contact for Delivery Team to get ques7ons answered
• Helps team make decisions
• Never (ever, ever) produce es7mates on behalf of Delivery Team
• Engage customer both internal and external
• Accepts user stories using the Defini7on of Done and acceptance criteria
• Remains engaged and responsive throughout the project
• Conducts the Sprint Review
[email protected] @ken_power
Pilot Projects
2008 • Teams • Agile Projects • Organic Growth
Formal Agile Transi7on Program
Launched
2009 • More Teams • Agile Program Management • System Wide Focus • Formal Training Plan • Formal Exec Support • Broader Stakeholder Engagement
Agile Office Established
2010 • Commitment to sustainable and sustained agility • Broad Organiza7on Focus • Focused Stakeholder Engagement
Increased Adop7on
2011
• Expand adop7on across product areas • Improve capability of organiza7on • Specific areas of focus, including architecture in lean/agile organiza7ons • PorYolio Management
Ongoing con7nuous improvement
2012+ • Build on successes • Learn and adapt • Refine and Improve • Expanded adop7on across product areas • New people and teams • Scaling across porYolio
January ‘08 December ‘09 September ‘10
[email protected] @ken_power
Company
Technology Group
Business Unit
People, Products, PorYolios, Systems
• Lots of people • Internal Conferences, Learning • Working Team • Transi7on Team
• ~6000 people • ~150+ Agile Teams • Core Working Team • Transi7on Team
• ~600 People • ~35+ Agile Teams
[email protected] @ken_power
[email protected] @ken_power
Sprint Planning
Delivery
Acceptance Demo
Backlog Management
Build
Test
Design
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
• … are in a single Scrum Team?
• … does it take to build and deliver a product?
• … does it take to ship a product?
• … does it take to ship a system?
• … are affected by the crea7on and delivery of the product?
[email protected] @ken_power
[email protected] @ken_power
Cross-‐Func7onal Delivery Team
Scrum Master
Product Owner
Scrum Team
Product Manager
QA Manager
Development Manager
Program Manager
Alpha
Beta TME
Early Access Program
User Experience
Team
Product Marke7ng
Channel Ramp
Other Business Units
GB
Tech Support Team
Product Owner Team
Extended Delivery Team
Product
System PorYolio Council
Sales Support Engineers
Customer Engagement
Team
UE Lead
Architect
[email protected] @ken_power
• Process Owner • Stakeholder Engagement • Dependency Management • Objec7vity • Con7nuous Inspec7on & Adap7on
• Engineering Investment (People)
• Quality Direc7on • Quality Strategy • Quality Requirements
• Technical Requirements • Technology Direc7on • Technology Strategy • Engineering Investment (People)
• Dependencies
• Priori7za7on • Customer Requirements
• Revenue
Product (Strategic)
Development (Tac7cal,
Opera7onal)
Program (Organiza7on)
Quality (Product Quality,
Con7nuity, Customer Focus)
[email protected] @ken_power
• The Product Owner role can be filled by a collabora7ve Product Owner Team – Typically a Product Manager, Development Manager, UE Lead, Architect, Program Manager
• Meet regularly as a team to manage the backlog
[email protected] @ken_power
[email protected] @ken_power
• Ronica Roth ar7cle iden7fies 6 scenarios for filling the Product Owner role – Scrum 101 (Single Product Owner) – Scrum 1012 (Product Owner per Team)
– Product Manager, aka Uber Product Owner
– Dynamic Duo
– Product Council – Product Owner Team
[email protected] @ken_power
• New Features
• Technical Debt
• Quality Debt
• Spike Tests
• Research
• Planning
[email protected] @ken_power
Investment
Technical Debt
Quality Debt
Features
Spike Tests
Research
Planning
[email protected] @ken_power
Investment
Technical Debt
Quality Debt
Features
Spike Tests
Research
Planning
[email protected] @ken_power
“ Who looks outside, dreams; who looks inside,
awakes.” Carl Gustav Jung
[email protected] @ken_power
Internal & External View of Product Ownership
7me
FCS Sell Install Day 2+
Internal Product Ownership
External Product Ownersip
Product
Customer Engagement
Teams
Delivery Teams
[email protected] @ken_power
Cisco Confidential © 2010 Cisco and/or its affiliates. All rights reserved. 27
User Stories
Epics Themes
Strategy
8.6 9.0 10.0
Projects Management Execs
Product Team
Portfolio Councils
DeliveryTeams Internal focus
Market focus
Projects
Products
Portfolio
MR MR MR ES MR MR 8.5
[email protected] @ken_power
Itera7
on
Product Increment
Full Product Release Release Rhythm
Project Rhythm
Cadence and Sequencing
[email protected] @ken_power
Concept Happy User
Do something cool
As a User I want to do something cool with the product So that I can benefit in some way
[email protected] @ken_power
Product Owner
Team
Level of Focus on the User Story
Concept Start End Ship It Done Accept
Ready
Done
Time [email protected] @ken_power
• User Story defined
• User Story Acceptance Criteria defined
• User Story dependencies iden7fied
• User Story sized by Delivery Team
• Team accepts UE artefacts
• Performance criteria iden7fied, where appropriate
• Person who will accept the User Story is iden7fied
• Delivery Team has reviewed and accepted the User Story
[email protected] @ken_power
SycnhronizaCon Point Defini7ons of Ready & Done act as focusing anchors for teams, Product Owners, and everyone involved
[email protected] @ken_power
[email protected] @ken_power
[email protected] @ken_power
• Consider Product Ownership, not just Product Owner role
• Product Owner Teams bring balance
• Understand and Engage Stakeholders
• Take an Internal and External Perspec7ve
• Think of Product Ownership like managing an investment porYolio
• Understand Your System’s Cadence and Establish synchroniza7on points
[email protected] @ken_power
Thank you.
[email protected] @ken_power