Sustainable Agility at Scale

© 2023 Scrum WithStyle scrumwithstyle.com
Sustainable Agility at Scale
The Sustainable Agility at Scale that New Zealand is Missing
with Rowan Bunning CST

© 2023 Rowan Bunning, Scrum WithStyle scrumwithstyle.com
About Rowan Bunning
• 25+ year involvement in software and product
development.
• Background in O.O. & web dev. with vendors, enterprise
product development, start-ups & consultancies
• Started Agile journey in 2001 (eXtreme Programming)
• Australia’s
fi
rst Scrum Master - 2003
• Introduced Scrum+XP organisation-wide
• Co-founder and Product Manager at a software startup
• Agile Coach at Ken Schwaber’s European partner in 2008
• Have delivered >500 certi
fi
cation courses on Scrum
• Management consultant on Agile adoption choices
• Organiser of Regional Scrum Gatherings®
• Married with a toddler and spoodle.
2005
2006
2008
2018
2017
2015
2010

Agenda
1. What does your organisation want?
2. Why we’re not working on the right things
3. Taking the pain out of dependencies
4. Maximising value at scale
5. Creating change theatre
6. Questions to unlock org. Performance
7. Scaling for adaptiveness and highest customer value
8. Want to learn more?
Many thanks to
Cesario Ramos
Craig Larman
Bas Vodde

What does your
organisation want?

Rowan Bunning @rowanb
What’s this optimised for?
Source: caterpillar.com

What’s this vehicle optimised for? And the people?
Source: forbes.com

“Speed” can be achieved through reducing batch size
Batch 1 Batch 2 Batch 3 Batch 4 Batch 5 Batch 6 Batch 7 Batch 8 Batch 9 Batch 10
Batch 1
Batch 1 Batch 2
Batch 1
Batch 2 Batch 3 Batch 4 Batch 5
Time

Optimising goal choice
Closer to the customer or highest customer value?
Time to market or product adaptiveness?
Employee engagement or
employee self-management
and intrapreneurship?
Renting a copied
operating model rigidly
or organisational adaptiveness?
While we value the item on the left, it can be achieved with Agile, Scrum or Lean!
Focusing on them will deny the organisation the Agile promise and will likely make
Agile methods high overhead and dif
fi
cult to sustain.
What should our IT enabled business project / product organisation be
optimised for in order to succeed given the competitive landscape, business
strategy and degree of change that we anticipate?

The intended point of Agile is agility
“We considered a bunch of names, and agreed eventually on “agile” as we felt
that captured the adaptiveness and response to change which we felt was so
important to our approach."
- Martin Fowler
“Agile does not mean delivering faster. Agile does not mean fewer defects or
higher quality. Agile does not mean higher productivity. Agile means agile - the
ability to move with quick easy grace, to be nimble and adaptable. To embrace
change and become masters of change - to compete through adaptability by
being able to change faster and cheaper than your competition can.
Perhaps faster delivery and higher quality will be achieved with an agile method
such as Scrum, but it is vital for business and engineering leaders to appreciate
that the raison d’être of agile methods is…agility.
- Craig Larman and Bas Vodde

Optimising for the Agile promise
shorter cycle time
in order to have
Adaptiveness (agility)
Discovery and delivery of highest customer value
in order to have
high order capability
low order capability
lower cost of change
Assumption: this is not
optimisable solely through
up-front analysis
business success
learning (how)
learning (what)

Why we’re not working
on the right things

Insurance company
Product de
fi
nition
Insurance
Sales
Underwriting
Solution
Premium
Billing
Claims
System
Quoting engine
Leads and
Opportunities
Policy provider
application
Rules engine
Premium
system
Insurance
booking system
Premium
payment
system
Claim checker
Pay back
engine
Underwriting
work
fl
ow
manager
Thanks to: Viktor Grgić for the example
The Market I see a Get Insurance
system
…and a Handle Claim
system
Insured Customer
Head of
Department
No,
This is a
product
Architect
No,
This is a
product
Project Manager
This is a
product

Q: Why is a high agility capability achievable
with a single team product but really dif
fi
cult
with multiple teams working on a product?

How Agile Transformations often start
Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Team 7 Team 8
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app

Local optimisation
Senior leader
End customers/users Other stakeholders
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app
PMO / Tribe

Capacity silos
Senior leader
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app
PMO / Tribe

Unable to maximise value
.
.
.
gap
Overall priorities
Senior leader
?
! !
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app
PMO / Tribe

Single function line management
.
.
.
gap
Overall priorities
Senior leader
?
! !
Function A
Line manager
Function B
Line manager
Function C
Line manager
Function D
Line manager
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app
PMO / Tribe

Component Teams cannot maximise value of the whole
Item 1
Item 2
Item 3
...
Item 8
…
Item 12
System
Comp A
Team
Comp B
Team
Comp C
Team
Component
A
Component
B
Component
C
With component teams, there is a tendency to select
goals familiar for people, not for maximizing customer
value. For example, Component A Team does Backlog
Item 3 because it mostly involves Component A work.
www.craiglarman.com
www.odd-e.com
Copyright © 2009
C.Larman & B. Vodde
All rights reserved.

Taking the pain out of
dependencies

Planning time dependency management

Component teams lead to waterfall
Backlog Item 1
Backlog Item 2
...
Comp A
Team
Comp B
Team
Comp
C
Team
Analyst System
Engineer
System
Testers
Iteration 1 Iteration 2
(probably later)
Iterations 3-5
(probably later
and more)
At least
iteration 6
(probably later)
Item 1
requirement
details
for Item 1
'backlog' by
component
not all teams start Item
1 at the same iteration;
they are multitasking
on multiple features system testers
cannot start
immediately on
Item 1; they are
multitasking on
multiple features
not available
until the analyst
is finished
Analysis
Design
Implementation
Test
Component teams lead to a sequential life cycle with handoff, queues, and
single-specialist groups and not true cross-functional teams without handoff.
code
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Misalignment
Org. structure
Customer/user Value
Business Process
and/or Architecture
Work
design
Mismatch…
• reduces transparency
• creates planning time dependencies
• creates need for big batch planning
• extra co-ordinator roles
• reduces agility of the whole
• at risk of regression
e.g. User Story
e.g. work on CRM only
Waste = “moments or actions that do not add value but consume resources.”

Shifting the dependency problem
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required
to finish a customer-centric feature.
These dependencies cause waste
such as additional planning and
coordination work, hand-offs
between teams, and delivery of
low-value items.
Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…
Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-
centric items. The dependencies
between teams are related to shared
code. This simplifies planning but
causes a need for frequent
integration, modern engineering
practices, and additional learning.
Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Objection: “It’s too dif
fi
cult for developers to
learn every technology and component”
Image credit: https://www.linkedin.com/pulse/how-
fi
nancial-advisors-
can-overcome-client-objections-holtman-rrc/
A: False dichotomy. No individual needs to know
and do everything.
Just more to reduce the skills demand vs. capacity
gap.
Everyone is capable of learning more.

Paint drip skills pro
fi
les over T-shaped
Example for a Leader

Maximising value at
scale

The solution in 2 sentences
“If Scrum Teams become too large, they should consider
reorganising into multiple cohesive Scrum Teams, each
focused on the same product. Therefore, they should share
the same Product Goal, Product Backlog, and Product
Owner.”
- The Scrum Guide (2020)

Scaling by distributing Product Backlog management workload
Does not scale Scales well

Scaling by delegating clari
fi
cation
PO
Users Market / domain experts
Prioritisation
Content and order of
Product Backlog
Clari
fi
cation
Splitting, acceptance
criteria, suf
fi
cient detail
etc.
💡 $
😀
“Yes”
“No”
“A little now, rest later”
“Sooner”
“Later”
☸
Requesters

Creating change theatre

“We want a changed capability but we
don’t want to change any signi
fi
cant
organisational systems.”
Wanting change without change
Leaders
“Let’s hire Agile coaches to
make the delivery teams Agile.”
“Agile is just a project
delivery approach, right?”

Delivery
With Agile practices, delivery
should be so frequent and
reliable as to be a non-event.
Language of the business-IT
hand-o
ff
, not of the core
work: learning.

Optimising for agility is a systemic change
People
Strategy
Structure
Rewards Processes
information
motivation
power
skills/mindsets
direction
We need to rethink and make changes to all elements of the Galbraith Star Model™ for it to be
sustainable.

Containing a
fi
re

Organisational systems
Containing Agile
Delivery
Agile?
People
Strategy
Structure
Rewards Processes
information
motivation
power
skills/mindsets
direction
individual performance reviews
specialist career paths
senior leaders without
organisational design skills
many middle managers tasked with
resource allocation and tracking
fi
rst level managers without
development skills
shareholder value
project based funding requires
negotiation of
fi
xed scope and date
project organisation not accountable
for bene
fi
ts realisation
defend power of supplier and guard
against new entrants
management by
objectives / OKRs
annual budgeting cycle
fi
nancial performance of
product not shared with
development group
fi
xed skills mindset
job insecurity
higher pay further from
value cretation
narrow specialisation

When leaders don’t change the surrounding org.

Relabelling

Organisational control systems
Market system
Bureaucratic
system
Clan system
• Prices drive very ef
fi
cient decision making
• Measure Input and Output
• Formal rules, roles, processes, compliance
• Supervision, direction and hierarchy
• Specialisations enable clearer comparison with
like workers
• Informal value based rules
• Allows innovation and collaboration
• Most suitable for unique, interdependent or
ambiguous work e.g. software development
Reference: A Conceptual Framework for the Design of Organizational Control Mechanisms, William G. Ouchi, Management Science, Vol. 25, No. 9. 1979.

Which did your organisation scale up?
Market control
Clan control
Bureaucratic
control

Who would like less bureaucratic control?
Market control
Bureaucratic control
Clan control
Market control
Clan control
• self-managing
teams
• self co-ordination
across boundaries
• decisions at level of
richest information
Simpler organisation

Alignment …
Market control
Clan control
self-managing
teams
self co-ordination
decisions at level of
richest information
PO
≪component≫
Publishing
≪component≫
Scheduling
≪component≫
Expenses
≪component≫
KPI Dashboards
Direct co-ordination
Communities for knowledge sharing and agreements Architecture, UX, Testing etc.
💡 $
😀 ☸

Same org structure relabelled with process tweaks
Delivery Delivery
Delivery
Scrum is put into these boxes
Team
Program
Portfolio

SAFe contains pseudo Scrum
pseudo
Scrum
pseudo
Scrum
Team
Program
Value Stream
Portfolio

– Dean Le
ffi
ngwell
“We don’t typically mess with your organisational
structure because that is a pretty big deal…”
See: https://www.keystepstosuccess.com/2016/05/safe-market-share-increase-rapid-growth-what-is-the-recipe/

Questions to unlock 95%
of org. performance

Defending the culture bubble

“I visualise Scrum as a rocket. Pushing that rocket
forward is the power of its engines. But pulling it back
are the forces of gravity. If the rocket it able to push far
enough, it can enter into orbit. But if it cannot, it will
inevitably get pulled back to earth, right where it started.
The implications of Scrum must be pushed far enough
into other parts of the organisation so that the entire
transition is not pulled back by organisational gravity.”
- Mike Cohn, Succeeding with Agile
Escape velocity

– W. Edwards Deming, Introduction to The Team Handbook
“95% of variation in the performance of a
system is caused by the system itself; only
5% is caused by the people.”

Leadership questions (1 of 2)
1. Would we like to rent or own our own management innovations?
2. Is our top executive team prepared to invest time and effort to learn
about systems thinking and organisational design?
3. What should we optimise our organisation for to succeed into the
probable long term future?
4. What is our speci
fi
c vision for an unachievable excellent realisation of our
optimising goals?

Leadership questions (2 of 3)
5. Can we commit to assessing every organisational change choice in
terms of our optimising goals and perfection vision?
6. Can we commit to job security but not role security?
7. Are we prepared to redesign incentives away from extrinsic motivation,
status and competitive reward systems to intrinsic motivation and
collective rewards?
8. Are we prepared to restructure around end customer/constituent value
creating vehicles such as broad customer-centric product offerings?
9. Are we prepared to formulate a perfection vision used to guide every org.
change decision?

Example Perfection Vision (1/2)
1. The perfection goal is to have a releasable product all the time. Release
stabilisation periods need to be reduced and eventually eliminated.
2. Co-located, self-managing, cross-functional, Scrum teams are the basic
organisational building block. Responsibility and accountability are on team
level.
3. The majority of the teams are organised as customer-centric feature teams.
4. Product management steers the development through the Product Owner role.
Release commitments are not forced on teams.
5. The line organisation is cross-functional. The functional-specialised line
organisations are gradually integrated in the cross-functional line organisation.

Example Perfection Vision (2/2)
6. Special coordination roles (such as project managers) are avoided and teams are
responsible for coordination.
7. The main responsibility of management is improvement—improve team’s learning,
ef
fi
ciency, and quality. The content of the work always comes from the Product Owner.
8. There is no branching in development. And product variation is not to be re
fl
ected in
the version control system.
9. All tests are automated with the exception of (1) exploratory test, (2) usability test, and
(3) tests that require physical movement. All people must learn test automation skills.
10.Adoption is gradual and evolutionary. These principles are considered in every
decision.
- Source: Larman, Craig; Vodde, Bas. Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) . Pearson Education.
Kindle Edition.

Scaling for adaptiveness
and highest customer value

Which question should we explore?
How can we do agile at
scale whilst keeping
our pre-agile
organisation as is?
How can we be agile
by simplifying the
organisation?
A B
Other scaling methods
Craig Larman and Bas Vodde

Scaling method comparison
Criteria SAFe “Spotify Model” LeSS
Fully cross-functional teams ✘ ✔ ✔
Local Sprint-to-Sprint agility ✘ ✔ ✔
Eliminates waste of co-ordination roles ✘ ✘ ✔
Learning incentive from long lived teams ✘ ✘ ✔
Whole customer product focus ✘ ✘ ✔
Avoids “capacity silos” ✘ ✘ ✔
Enables whole product value maximisation ✘ ✘ ✔
Free from agility constraining planning wrappers ✘ ✘ ✔
Eliminates problematic dependencies ✘ ✘ ✔
Aligned with cross-skilling / “multi-learning” ✘ ✘ ✔
Aims to eliminate The Contract Game ✘ ✘ ✔
Aligned with The Scrum Guide ✘ ✘ ✔

LeSS has broad applicability
LeSS
LeSS Huge
2 teams
thousands of developers
working on a single product
>8 teams

It started with 648 experiments
2009 2010
•Systems Thinking
•Lean Thinking
•Queueing Theory
•False Dichotomies
•Be Agile
•Feature Teams
•Teams
•Requirement Area
•Organisation
•Large-Scale Scrum
•Scrum
•Large-Scale Scrum
•Test
•Product Management
•Planning
•Coordination
•Requirements & PBIs
•Design & Architecture
•Legacy Code
•Continuous Integration
•Inspect & Adapt
•Multisite
•Offshore
•Contracts

Frameworks, guides and principles
10 principles
are made actionable through
28 rules* connected in the form of
2 frameworks
Whose adoption is guided by
101 guides
* 40 rules in LeSS Huge
2016

LeSS is Scrum
Team
Program
Value Stream
Portfolio

fi
cation
PO
Users Market / domain experts
Prioritisation
Content and order of
Product Backlog
Clari
fi
cation
Splitting, acceptance
criteria, suf
fi
cient detail
etc.
💡 $
😀
“Yes”
“No”
“A little now, rest later”
“Sooner”
“Later”
☸
Requesters

Some of the management literature that informs LeSS
Evidence based
management
The thinking that
led to Lean
Unlocking the
potential of people
Lean
management
Systems thinking Team leadership

Want to learn more?

LeSS Experience Report
Sam Peacock Rowan Bunning
The Game Changing LeSS
Adoption at Findex Digital
scrum.com.au

LeSS Lunch anyone?
Free 1 hour overview of LeSS
Online via Zoom
Wednesday 22nd March 2023 at 12pm NZT / 10am AEDT
Register at:
https://bit.ly/lessmar23
Please extend the invite to friends and colleagues.

@rowanb au.linkedin.com/in/rowanbunning
Rowan Bunning
rowan@scrumwithstyle.com scrumwithstyle.com

Sustainable Agility at Scale

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Sustainable Agility at Scale

Similar to Sustainable Agility at Scale (20)

More from Rowan Bunning

More from Rowan Bunning (15)

Recently uploaded

Recently uploaded (20)

Sustainable Agility at Scale