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
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!)
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”
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?
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…
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