As presented at the Scrum Gathering 2023 in Amsterdam

1. Product?
What Product?
© 2023 by The ScaleAgility Group, licensed under CC BY-SA 4.0.
• Pierluigi Pugliese
• Simon Roberts
• Colin Bird

2. ScaleAgility: Principles Over Frameworks for Agility at Scale
Jan B. Olsen
Denmark, CTC […]
Matt Roadnight
England, CST […]
Colin Bird
England, CST […]
Pierluigi Pugliese
Germany, CST […]
Simon Roberts
Scotland, CST […]

3. • Are you a Product Owner?
• Are you working on a large-scale development?
• In your company, do you have…
• Chief Product Owner?
• Technical Product Owner?
• Business Analysts?
• Business PO? Business Owner?
• Other “strange” roles?
Our topic today: Product [& Owner]

4. • What is a Product [at Scale]?
• Principles
• Organisational Complexity
• Case study and examples
• Product Ownership at scale
• Principles
• Examples
• Towards an agile organisation at scale
• The importance of the definition of Product!
What are we going to talk about?

5. A Product
Owner is a…
Product Owner
What does it mean
“being owner”?
What is a
Product?
The Secret of the Product Owner

6. • Maximises the value / RoI
• Decides the Product Strategy
• Decides about scope and priorities
The Product Owner - recap
From: Scrum Guide 2020, adapted

7. • Is:
• Entrepreneur
• Innovator
• System thinker
• Mini-CEO
• Is NOT
• Business Analyst
Ken Schwaber on POs
https://www.scrum.org/resources/blog/who-professional-scrum-product-owner

8. Clarification and Prioritisation
Stakeholders Developers
Clarification
Prioritisation
Decides on scope and
priorities:
Product Development
Strategy!
Product
Owner
Product
Backlog

9. What is a
Product?

10. • In groups of 3-4
• Discuss a *structural* definition for a large product:
• What is part of a product?
• What is *not* a part of a product
• Consider cases like:
• Large global e-commerce
• Automotive development
• Big telecom development
• …
What is a Product? (At Scale!)

11. Principle 1:
End-to-End
Product!
Ideally…
“Product
Development
Organisation”

12. • It’s too big/too complex
• Our departments are not organised to work like that
• We cannot work like that
• We have too many sites to make it work in that way
• Our architecture is different and does not support that
• We’ve always done it differently
• [Blah, blah, blah, …]
But…
😬
😭
😢
😤
😵💫

13. Complexity
Complexity
In large companies: CA >>> CE
Essential →CE
Accidental →CA
- Frederick P. Brooks, The Mythical Man-Month, Anniversary edition with 4 new chapters, Addison-Wesley (1995)
- Proceeding of the IFIP Tenth World Computing Conference, H.-J. Kugler, ed., Elsevier Science B.V., Amsterdam, NL (1986)
pp. 1069-76

14. Customer
(needs…)
Customer
Product,
Service,
…
[used somewhere
else in our
company…]
Something coming
from a supplier
Customer
(needs…)
Customer
(needs…)
Customer
Product,
Service,
…
Accidental Complexity in Action…
“Composite Value
Stream”
Product
Owners/
Managers/...
Department
Boundaries
Dept. 1 Dept. 2
Dept. 3
Dept. 4
Dept. 5
Dept. 6
Teams

15. The MAIN cause of Organisational
Dysfunctions is…
Accidental
Complexity
How can we reduce it?

16. Principle 2: Align towards
Business Synergies
If you really need to “split”

17. Principle 3:
Avoid
Components
If you really need to “split”

18. Principle 4:
Architectural
Cohesion
If you really need to “split”

19. Principle 5:
Reduce Factors Increasing
Product Complexity
If you really need to “split”
Constraint Dimensions
• Human Factors
• Internal Politics
• Company Structure
• Technological
• Technical
• Product Size
• Value Stream Complexity

20. Using the Constraint Dimensions -
Example
Complexity
Difficulty in addressing it
⦿ Technological
⦿ Company Structure
⦿ Internal Politics
⦿ Human Factors
⦿ Value Stream Complexity
⦿ Product Size
⦿ Technical

21. Principle 6:
Evolve in the direction
of extending
the de
fi
nition of Product,
avoid Parts
If you really need to “split”

22. Example: Evolving a Product
A telecommunications company
turned their failing consumer cloud
product around by going back to
basics and applying a rigorous and
evolutionary approach to scaling

23. • Long time-to-market for new versions, typically 1-2 major releases
per year.
• Low customer satisfaction, indicated by low user retention rate and
typically 1-2 star ratings in the App stores.
• Low team morale.
• Poor performance and reliability of the product.
• Separate roles for product management, commercial management,
service life-cycle management and project management.
• Development carried out by teams responsible for different layers of
the technical architecture
Example: Initial Situation

24. Workshop Example
Specialisation (if any):
Codec
Team
Specialisation (if any):
IOS
Team
Specialisation (if any):
Android
Team
Specialisation (if any):
Web
Output
Description
Team
Specialisation (if any):
Windows
Desktop
Work
Description
Team
Specialisation (if any):
Backend
Work
Description
Team
Team
Specialisation (if any):
Database
Team
Specialisation (if any):
Acceptance
Testing
Team
Specialisation (if any):
Performance
Testing
Team
Specialisation (if any):
Integration
Team
Specialisation (if any):
Requirements
Work
Description Internal Product
Description
Deliverable Product
Description
Output
Description
Output
Description
Output
Description
Output
Description
Output Description
Work
Description
Work
Description
Work
Description
Work
Description
Work
Description
Team
Specialisation (if any):
Visual
Design
W
o
r
k
D
e
s
c
r
ip
t
io
n
Document Output
Description
Work
Packages for
the Teams
Nat Cos
(UK, GEr,
Hun)
Security/
Data Prot
SVPs Biz
Units
Output
Description
Improve
End-To-End Product
Improve
End-To-End Product Improve
End-To-End Product
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve Business
Synergies
Remove the hand over
of documented work
packages as it cause
product quality isess to
to lack of clarity
A team has all the skills
(one of .. Windows,
Desktop, Web, Android,
IOS) to integrate and
acceptance test their work
Improve inconsistent
journeys across different
product end points
(Windows, IOS, Android,
Web)
Bring together UI
specialists with database
and backend specialists
in the same team
Bring together UI
specialists with database
and backend specialists
in the same team
A team has all the skills
(one of .. Windows,
Desktop, Web, Android,
IOS) to integrate and
acceptance test their work
Many business stakeholder
requests are taken across
different end consumer
products (IoS, Android, Web,
Windows) causing priority
clashes
Improve clarity of
requirements between
different stakeholder
that have differing views
Bring requirements
and visual design
specialists into the
the same team

25. Workshop Example
Team
Specialisation (if any):
Web
Team
Specialisation (if any):
Windows
Desktop
Team
Specialisation (if any):
Backend
Team
Team
Specialisation (if any):
Database
Team
Specialisation (if any):
Requirements
Work
Description
Work
Description
Work
Description
Work
Description
Work
Description
Team
Specialisation (if any):
Visual
Design
W
o
r
k
D
e
s
c
r
i
p
t
i
o
n
Document Output
Description
Work
Packages for
the Teams
Ps Biz
nits
E
Improve
End-To-End Product
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve Business
Synergies
Remove the hand over
of documented work
packages as it cause
product quality isess to
to lack of clarity
Improve inconsistent
journeys across different
product end points
(Windows, IOS, Android,
Web)
Bring together UI
specialists with database
and backend specialists
in the same team
Bring together UI
specialists with database
and backend specialists
in the same team
Many business stakeholder
requests are taken across
different end consumer
products (IoS, Android, Web,
Windows) causing priority
clashes
Improve clarity of
requirements between
different stakeholder
that have differing views
Bring requirements
and visual design
specialists into the
the same team

26. • Starting with one team, the transition was made to cross-functional
feature teams.
• A single product backlog was introduced across all teams.
• Each team was trained and coached in excellent Scrum + key Scrum
patterns + XP development practices.
• Gave the organisation the means to respond quickly to data on
product quality and user satisfaction and drive the product towards
success.
Example: What Changed?

27. • After 6 months, things had improved considerably:
• App store ratings improved from an average of 1-2 stars to 4-5
stars, More active users
• Team morale improved
• Product awarded first place in a review of competitive consumer
cloud products
Example: What Happened?

28. What does it mean
“being owner”?

29. Principle 7:
The Product Owner
is Accountable
for sustained End Value
At Scale…

30. From Larman-Vodde,“Practices for Scaling Lean & Agile Development” - adapted
"Business" "Development"
Authority Responsibility
More! Less!
Product Owner:
Authority and
Responsibility
The “Contract Game”
Some common names:
- Product Manager
- Product Owner
- Product Owner
- Business Owner
- Business Process Owner
Some common names:
- Development Manager
- Tech. Product Owner
- Proxy Product Owner
- Product Owner
- Product Owner

31. Escalation
path
Escalation
path
Escalation
path
Portfolio Management /
Steering Committee /
...
Escalation
path
A Common
Configuration…
?
✘
“Small POs”

32. Better!
Portfolio Management /
Steering Committee /
...
Investment
decision
[ ... ]
Investment
decision
“Big PO”

33. Principle 8:
Minimum Viable
Product Owners
At Scale…

34. Outcome or
Output?

35. Output Outcome
Velocity Customer satisfaction
Person-hours/-days Employees satisfaction
Lines of code Overall product rating
# of bugs
# of bugs reported from the
fi
eld
# of features delivered
Customer-perceived value of
the features delivered

36. Principle 9: Outcome is the primary
measure of success
Principle 10: Output is only relevant in
that it delivers outcomes and impacts
At Scale…

37. Principle 11:
Collective
Accountability
in case of
Product Ownership Group
At Scale…

38. The Path Towards
the Agile Organisation
at Scale

39. Towards a
Large-Scale
Agile Organisation
Towards: End-to-end Organisation
Towards: End-to-end Product
Towards: End-to-end Product Ownership
Craft
Towards: End-to-end Teams
Teams Coordination and Learning
Progressive
Enablement
Leadership provide Vision,
Guidance, grow Capabilities,
Resources, Role models of a
Learning Organisation
Iterate!
The Definition of Product
identifies and enables the
structural changes needed
in the organisation
Technical Excellence,
Coordination structures and
Learning culture enable high-
performing, product-focused
Teams
Synergies
Constraints
Progressive
Enablement

40. Questions?

41. Pierluigi Pugliese
https://connexxo.com
ppugliese@connexxo.com
`
https://scaleagility.org
Simon Roberts
https://scrumcenter.co.uk
simon.roberts@scrumcenter.com
Colin Bird
https://ripple-rock.com
colin.bird@ripple-rock.com