Case Against Scaling (Scrum Gathering Berlin)

Copyright Reaktor 2013 Luottamuksellinen

Case Against Scaling
Back to basics with your enterprise
transformation
Sami Lilja
Reaktor
Twitter: @samililja
Copyright Reaktor 2014

How big is big?
Pick a piece of paper and a pen.
Think about software / IT projects you
have been working on.
Based on your experience fill in the
blank:
A project is a big project when it has
more than ___ people working on it.

The Beef

Solving the wrong problem
Source: http://www.medscape.com/viewarticle/806573

Finding the right question
The way we formulate the problem,
limits our space of potential solutions
Meetings take too much time
People lack motivation
Work environment, the system,
vs.
We have too many meetings
vs.
decreases motivation
Coordinating between parallel projects
is not effective
vs.
We have too many parallel projects

Scaling Agile?
The problem is not that we lack ways
to scale Agile.
The problem is not that we fail with
Agile in large organizations.
The problem is that we are large.
Size does matter.

Economy of Scale
Scalability
Size
Cost of
overhead
Sublinear = Scales well
Highly repeatable
“How many?”

Labor-intensive work

Knowledge work?

When doing knowledge work in
Large Scale, the key question is
not “How?” – it is “Why?”

Organizations getting bigger

Pear-shape organizations

But, hey..
• Do you say companies should not grow?
– No, I am not saying that
• Do you say companies should only do
small things?
– No, I am not saying that
– But.. small batches are better than large batches
• Are you against the frameworks that
promise Agility in large-scale?
– No, I am against doing large-scale development
– However, the frameworks take “large scale” as given
and do very little to reduce that

What makes us Big?
Large organization or
project
Fear of
transparency
“We need lot of
different competences”
“Relative overhead is
smaller”
Complex
systems
Separating action,
feedback, knowledge and
decision making
“Adding more people
will speed us up”
Big projects need lot
of people need big
projects need …
Silos in
organization
(Conways’s Law)
Lot of unfinished
work (WIP)
Belief in Economies
of Scale
Failure
Demand
Short-term
(Project) thinking

The root of all Evil I
Work-in-Progress

Work-in-Progress
• How many things your organization is
currently working on?
• How easy it is to get dedicated people /
team to deliver customer value?

Hey, but..
• Work-in-Progress and Little’s Law are
about time through system
• What does this have to do with project
size?
• Large amount of WIP helps to create
unnecessarily large projects
– When time-through-system gets long, some
organizations add more people to gain speed
– People are split to work on many parallel
projects. Getting X people worth of work
takes 10x more people

Work in Progress
• Most organizations have too many
things going on at one time, because
– People are costly: Fear of <100% resource
utilization
– It is easier to start things than complete
things
– Large projects require lot of people
require large projects require lot of
people..

Work in Progress
• We underestimate the overhead that
Work-in-Progress causes
• In reality, large WIP causes huge and
costly problems
– Delays
• time-through-system = Work-In-Progress / Velocity
– Queues and synchronization problems
– Internal Failure Demand
• Meetings, coordination effort, waiting, re-work, …

Sami’s Test #1
• Think about predictable demand that
comes to your organization
– Support request, creating a new service,
ramp-up of a project, fixing a bug, …
• What would be the fastest completion
time for such work in your system, if
you could do anything to make it
happen?
• If your current performance is lower,
why is that? What causes delays?

Quick review
• Pick a person near you, form pairs or
triplets
• In your small group, have a 2 minutes
discussion about
– What topics have been covered so far?
– How do you feel about these topics?
– What concepts have been significant to you?
– How could you use these in your work?

The root of all Evil II
Failure Demand

Value demand
Adds value from customer
point of view.
Something customers are
willing to pay for.
This type of demand we want.
Failure
demand
Failure to do what customer
needs
Bad quality, wrong product or
service, delay.
No product or service.
Missing either what or how
customer wants
Can account up to 80% of work

All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/

Failure demand: Not only bugs
NEW IT SYSTEM!
Value
for
user
Fail
CU
ST
O
M
E
R
S
UP
P
O
R
T
“PRESS 1 IF YOU
CALL ABOUT..”
“PRESS 2 IF YOU
CALL ABOUT..”
“PRESS 3 IF YOU
CALL ABOUT..”

Internal Failure demand
Do we need this
process?
What thinking
created this?

Hidden Failure demand
Value Demand
(Project work)
Failure Demand
(Bug fixes etc)
Other
The Plan
Value Demand
(Project work)
Failure Demand
(Bug fixes,
meetings,
waiting,
coordination)
Other
The reality

Dysfunction
Something in the design and
management of work that is
causing problems.

Institutionalized Dysfunction
Problem that is resolved by adding
processes or management actions
and then focusing on actions
rather than the original problem.

Institutionalized Dysfunction
and Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Slippery slope to
institutionalized
dysfunction

Sami’s Test #2
• Assume you could freely choose the
smallest possible number of people to
implement the product or service.
• How large would that group be?
• If such group is significantly smaller
than your current development
project, why is that?

Quick review
• Pick a person near you, form pairs or
triplets
• In your small group, have a 2 minutes
discussion about
– What topics and issues have been covered so
far?
– How do you feel about these topics?
– What topics or concepts have been
significant to you?
– How could you use new learning in your
work?

THE WAY OUT?

What makes us Big?
Large organization or
project
None of these are Laws of Nature.
None of these are imposed on you.
Fear of
transparency
“We need lot of
different competences”
“Relative overhead is
smaller”
Complex
systems
Separating action,
feedback, knowledge and
decision making
“Adding more people
will speed us up”
Big projects need lot
of people need big
projects need …
Silos in
organization
(Conways’s Law)
Lot of unfinished
work (WIP)
Belief in Economies
of Scale
Failure
Demand
Short-term
(Project) thinking
These are the results of thinking.
And we can get rid of these if we
want.

Putting things in perspective
• Up to 80% of work in organization is Failure
Demand
– What if you could reduce it, just a little bit?
• Significant amount of work in project is
caused by large amount of WIP
– What if that improves as well?
• Keep in mind the pear-shape organization and
super-linear cost of scaling…

Size
Cost of
overhead
Sublinear = Scales well
Reducing project size by
X% decreases costs by a
lot more than X%
X%

But hey, …
• “You are overreacting. We all know
large scale may not be the best
solution. But it is usually
unavoidable. And it works”

It is not perfect but it works
If it works, don’t fix it
- American Car manufacturers, 1970s

Sami’s Test #3
• OK, let’s assume you’ve done everything to
limit WIP, remove failure demand and reduce
complexity
• Still your project is Large(-ish) .. At least 3x
bigger than “by-the-book” Agile project
• Doing things in large scale is the only option.
And you want to do it Agile.
• Have you done a very successful small end-to-end
Agile project before attempting a large
scale Agile project?

SCRUM AT LARGE SCALE

What is missing from
this picture?
I can not see the
customer here..

What is missing from
this statement?
What if the demand
comes from end user?
What if we are
creating a service?

Asking the right question
• “How can I make Scrum work in my
organization and my projects”
– Coaching, Teaching, Inspect and Adapt
• “How can I fulfill value demand from
customer using Scrum”
– Coaching, Teaching, Inspect & Adapt, …
– Study and understand demand
– Design and manage work against Value
Demand!

Forgetting customer
• Forgetting customer may lead to tunnel
vision
– Creating backlogs for teams rather than for
customer need
– Having unnecessary dependencies between
teams (and product owners)
– Internal failure demand: synchronization,
prioritization, waiting
– Lack of purpose: Backlog represent “work”
instead of “Customer need”

Customers,
users
Customers,
users
Demand
Demand
Value for
customers
and users
Value for
customers
and users

BEYOND SCRUM: "
SOLID FRAMEWORK"
"
HTTP://SOLID.REAKTOR.FI

• Three different levels and
frames for thinking
– Note: These boxes are not
separate organizations
• Purpose of Solid: Help
organizations design and
manage work so that
value demand from
customer is fulfilled
• Solid helps organizations
to find the right
questions

Operational Level looks at value delivery
flow in order to maximize the Return on
Investment.
Thinking frames
• True Agility
• Kanban, Scrum, XP
Tactical Level aims to find the right products
and services. It also provides tools to manage
investment (project) portfolio.
Thinking frames
• Customer development & Lean startup
• Data science
Strategic Level provides understanding
about markets and customer needs. It helps
to design workflow and value delivery
system.
Thinking frames
• Systems Thinking
• Outside-in perspective

Summary
• Attempts to do knowledge work in large
scale are likely to fail
– …or at least suboptimal way to create products
and services
• Main reasons for being large
– Lot of parallel work-in-progress
– Inability to see and remove failure demand
– Fear of fast feedback and transparency
• Large Scale is a System Condition
• In order to change System Conditions, we
need new thinking
– We need to find better questions, not just good
answers

solving the right problem?
We are engineers.
We are trained to
solve problems.

Ways to deal with a problem
Dissolution: redesign the system or its environment
in such a way that it eliminates the problem or the
conditions that caused it
solution: discover or create behavior that yields the
best, or approximately the best, possible outcome, one
that "optimizes" the situation.
Resolution: employ behavior previously used in
similar situations, adapted if necessary, so as to obtain
an outcome that is good enough.
Absolution: ignore a problem and hope it will solve
itself or go away of its own accord.
http://results2match.com/ackoff-again-4-different-ways-of-solving-a-problem

Dissolution: redesign the system or its environment
in such a way that it eliminates the problem or the
conditions that caused it

Case Against Scaling (Scrum Gathering Berlin)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Case Against Scaling (Scrum Gathering Berlin)

Similar to Case Against Scaling (Scrum Gathering Berlin) (20)

Recently uploaded

Recently uploaded (20)

Case Against Scaling (Scrum Gathering Berlin)