Case Against Scaling (Tre Goes Agile presentation, Dec 14 2013)

S
Case Against Scaling


Back to basics with your enterprise
transformation



Sami Lilja

Reaktor

Twitter: @samililja

Copyright Reaktor 2013

Luottamuksellinen
The Beef

Copyright Reaktor 2013

Luottamuksellinen
Solving the wrong problem

Source: http://www.medscape.com/viewarticle/806573
Copyright Reaktor 2013

Luottamuksellinen
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.

Copyright Reaktor 2013

Luottamuksellinen
Is it just a coincidence that
Scale rhymes with Fail? *)

*)Inspired
Copyright Reaktor 2013

by @AgileBorat in Twitter
Luottamuksellinen
Cost of
overhead

Scalability

Sublinear = Scales well

Economy of Scale
Highly repeatable
“How many?”
Size

Copyright Reaktor 2013

Luottamuksellinen
Labor-intensive work 

Copyright Reaktor 2013

Luottamuksellinen
Knowledge work?

Copyright Reaktor 2013

Luottamuksellinen
Intermission: FAQ
•  Do you say that 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 being large.
–  However, the frameworks take “large scale” as given and
do very little to reduce that

•  Do you say that all projects and organizations
could be scaled down to be more Agile?
–  Yes, but this is not mandatory 
–  Survival is not mandatory, either
Copyright Reaktor 2013

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

Copyright Reaktor 2013

Luottamuksellinen
Organizations getting bigger

Copyright Reaktor 2013

Luottamuksellinen
Pear-shape organizations

Copyright Reaktor 2013

Luottamuksellinen
What makes us Big?
Large organization or
project


“We need lot of
different competences”


Complex
systems


Silos in
organization
(Conways’s Law)


Lot of unfinished
work (WIP)


“Adding more people
will speed us up”

Short-term
(Project) thinking


Separating action,
feedback, knowledge and
decision making


Fear of
transparency

Copyright Reaktor 2013

Belief in Economies
of Scale

Big projects need lot
of people need big
projects need …


Failure
Demand


Luottamuksellinen
The root of all Evil I

Work-in-Progress


Copyright Reaktor 2013

Luottamuksellinen
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?

Copyright Reaktor 2013

Luottamuksellinen
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 many on-going projects,
so one project needs more people
Copyright Reaktor 2013

Luottamuksellinen
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..

Copyright Reaktor 2013

Luottamuksellinen
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, …

Copyright Reaktor 2013

Luottamuksellinen
Sami’s Test #1
•  Think about predictable demand that
comes to your organization
–  Support request, deployment, creating a
new service, fixing a bug, …

•  What would be the fastest completion
time, if you could do anything to make
it happen?
•  If your current performance is lower,
why is that? What causes delays?

Copyright Reaktor 2013

Luottamuksellinen
Intermission
•  Project == Problem
•  We encapsulate product or service
creation into a project. But that is an
incorrect concept
•  project creates dysfunctions
–  Hides dependencies with existing systems 
–  Creates a boundary that is arbitrary from
customer perspective
–  Turns our attention away from customer to
project management
–  Adds a new dimension of management and
control
Copyright Reaktor 2013

Luottamuksellinen
The root of all Evil II


Failure Demand

Copyright Reaktor 2013

Luottamuksellinen
Failure to do what customer
needs
Bad quality, wrong product or
service, delay. 

Failure
demand


No product or service.
Missing either what or how
customer wants
Can account up to 80% of work
Adds value from customer
point of view.

Value demand


Something customers are
willing to pay for.
This type of demand we want.

Copyright Reaktor 2013

Luottamuksellinen
All demand is considered work

Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/
Copyright Reaktor 2013

Luottamuksellinen
Failure demand: Not only bugs

Fail

NEW IT SYSTEM!

Value
for
user


C
U
S
T
O
M
E
R

S
U
P
P
O
R
T

Copyright Reaktor 2013

“PRESS 1 IF YOU
CALL ABOUT..”

“PRESS 2 IF YOU
CALL ABOUT..”

“PRESS 3 IF YOU
CALL ABOUT..”

Luottamuksellinen
Internal Failure demand
Do we need this
process?

What thinking
created this?


Copyright Reaktor 2013

Luottamuksellinen
Hidden Failure demand
Value Demand
(Project work)

Value Demand
(Project work)

Failure Demand
(Bug fixes,
meetings,
waiting,
coordination)

Failure Demand
(Bug fixes etc)
Other

The Plan

Other

The reality

Copyright Reaktor 2013

Luottamuksellinen
Dysfunction

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

Copyright Reaktor 2013

Luottamuksellinen
Institutionalized Dysfunction

Problem that was resolved by adding
process or management actions and
then focusing on actions rather than
original problem.

Copyright Reaktor 2013

Luottamuksellinen
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 it is significantly smaller than your
current development project, why is
that?
Copyright Reaktor 2013

Luottamuksellinen
THE WAY OUT?

Copyright Reaktor 2013

Luottamuksellinen
What makes us Big?
Large organization or
project


“We need lot of
different competences”


“More people will
speed us up”


None of these are Laws of Nature.

None of these Short-term
are imposed on you.

Complex
Belief in Economies
(Project) thinking

systems

of Scale


These areSeparating action,
the results ofBig projects need lot
thinking.

Silos in
feedback, knowledge and
of people need big
organization
decision making
projects need …



(Conways’s Law)

And we can get rid of these if we
Failure
Lot of unfinished
want.

Fear of
Demand

work (WIP)


transparency


Copyright Reaktor 2013

Luottamuksellinen
Large Scale
Large Scale is a System Condition.
It is a result of thinking by those who
decide how work is designed and
managed.
As a system condition, it has major
impact on the performance.
And since it is man made, it can be
changed.
Copyright Reaktor 2013

Luottamuksellinen
Putting things in perspective
•  Up to 80% of work in organization is Failure
Demand
–  What if you could get rid of it? Or reduce it?

•  Significant amount of work in project is
caused by large amount of WIP
–  What if that disappears as well?

•  Keep in mind the pear-shape organization and
super-linear cost of scaling…
•  Reducing project size by X% decreases costs
by a lot more than X%

Copyright Reaktor 2013

Luottamuksellinen
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-toend Agile project before attempting a large
scale Agile project?
Copyright Reaktor 2013

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

Copyright Reaktor 2013

Luottamuksellinen
It is not perfect but it works

Copyright Reaktor 2013

Luottamuksellinen
It is not perfect but it works

If it works, don’t fix it

- American Car manufacturers, 1970s

Copyright Reaktor 2013

Luottamuksellinen
Example of new thinking
•  Squads, chapters,
tribes, guilds …
•  Most important is
thinking!
Alignment
Autonomy
“Structure happens!”

Copyright Reaktor 2013

Luottamuksellinen
Summary
•  Attempts to do knowledge work in large
scale are likely to fail
–  …or at least they are 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:
both external and internal
–  Fear of fast feedback and immediate visibility

•  Large Scale is a System Condition
–  System conditions can be changed
Copyright Reaktor 2013

Luottamuksellinen
1 of 39

More Related Content

Similar to Case Against Scaling (Tre Goes Agile presentation, Dec 14 2013)(20)

Case Against Scaling (Tre Goes Agile presentation, Dec 14 2013)

  • 1. Case Against Scaling Back to basics with your enterprise transformation Sami Lilja Reaktor Twitter: @samililja Copyright Reaktor 2013 Luottamuksellinen
  • 2. The Beef Copyright Reaktor 2013 Luottamuksellinen
  • 3. Solving the wrong problem Source: http://www.medscape.com/viewarticle/806573 Copyright Reaktor 2013 Luottamuksellinen
  • 4. 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. Copyright Reaktor 2013 Luottamuksellinen
  • 5. Is it just a coincidence that Scale rhymes with Fail? *) *)Inspired Copyright Reaktor 2013 by @AgileBorat in Twitter Luottamuksellinen
  • 6. Cost of overhead Scalability Sublinear = Scales well Economy of Scale Highly repeatable “How many?” Size Copyright Reaktor 2013 Luottamuksellinen
  • 7. Labor-intensive work Copyright Reaktor 2013 Luottamuksellinen
  • 8. Knowledge work? Copyright Reaktor 2013 Luottamuksellinen
  • 9. Intermission: FAQ •  Do you say that 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 being large. –  However, the frameworks take “large scale” as given and do very little to reduce that •  Do you say that all projects and organizations could be scaled down to be more Agile? –  Yes, but this is not mandatory –  Survival is not mandatory, either Copyright Reaktor 2013 Luottamuksellinen
  • 10. When doing development work in Large Scale, the key question is not “How?” – it is “Why?” Copyright Reaktor 2013 Luottamuksellinen
  • 11. Organizations getting bigger Copyright Reaktor 2013 Luottamuksellinen
  • 13. What makes us Big? Large organization or project “We need lot of different competences” Complex systems Silos in organization (Conways’s Law) Lot of unfinished work (WIP) “Adding more people will speed us up” Short-term (Project) thinking Separating action, feedback, knowledge and decision making Fear of transparency Copyright Reaktor 2013 Belief in Economies of Scale Big projects need lot of people need big projects need … Failure Demand Luottamuksellinen
  • 14. The root of all Evil I Work-in-Progress Copyright Reaktor 2013 Luottamuksellinen
  • 15. 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? Copyright Reaktor 2013 Luottamuksellinen
  • 16. 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 many on-going projects, so one project needs more people Copyright Reaktor 2013 Luottamuksellinen
  • 17. 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.. Copyright Reaktor 2013 Luottamuksellinen
  • 18. 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, … Copyright Reaktor 2013 Luottamuksellinen
  • 19. Sami’s Test #1 •  Think about predictable demand that comes to your organization –  Support request, deployment, creating a new service, fixing a bug, … •  What would be the fastest completion time, if you could do anything to make it happen? •  If your current performance is lower, why is that? What causes delays? Copyright Reaktor 2013 Luottamuksellinen
  • 20. Intermission •  Project == Problem •  We encapsulate product or service creation into a project. But that is an incorrect concept •  project creates dysfunctions –  Hides dependencies with existing systems –  Creates a boundary that is arbitrary from customer perspective –  Turns our attention away from customer to project management –  Adds a new dimension of management and control Copyright Reaktor 2013 Luottamuksellinen
  • 21. The root of all Evil II Failure Demand Copyright Reaktor 2013 Luottamuksellinen
  • 22. Failure to do what customer needs Bad quality, wrong product or service, delay. Failure demand No product or service. Missing either what or how customer wants Can account up to 80% of work Adds value from customer point of view. Value demand Something customers are willing to pay for. This type of demand we want. Copyright Reaktor 2013 Luottamuksellinen
  • 23. All demand is considered work Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/ Copyright Reaktor 2013 Luottamuksellinen
  • 24. Failure demand: Not only bugs Fail NEW IT SYSTEM! Value for user C U S T O M E R S U P P O R T Copyright Reaktor 2013 “PRESS 1 IF YOU CALL ABOUT..” “PRESS 2 IF YOU CALL ABOUT..” “PRESS 3 IF YOU CALL ABOUT..” Luottamuksellinen
  • 25. Internal Failure demand Do we need this process? What thinking created this? Copyright Reaktor 2013 Luottamuksellinen
  • 26. Hidden Failure demand Value Demand (Project work) Value Demand (Project work) Failure Demand (Bug fixes, meetings, waiting, coordination) Failure Demand (Bug fixes etc) Other The Plan Other The reality Copyright Reaktor 2013 Luottamuksellinen
  • 27. Dysfunction Something in our design and management of work that is causing problems. Copyright Reaktor 2013 Luottamuksellinen
  • 28. Institutionalized Dysfunction Problem that was resolved by adding process or management actions and then focusing on actions rather than original problem. Copyright Reaktor 2013 Luottamuksellinen
  • 29. 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 it is significantly smaller than your current development project, why is that? Copyright Reaktor 2013 Luottamuksellinen
  • 30. THE WAY OUT? Copyright Reaktor 2013 Luottamuksellinen
  • 31. What makes us Big? Large organization or project “We need lot of different competences” “More people will speed us up” None of these are Laws of Nature. None of these Short-term are imposed on you. Complex Belief in Economies (Project) thinking systems of Scale These areSeparating action, the results ofBig projects need lot thinking. Silos in feedback, knowledge and of people need big organization decision making projects need … (Conways’s Law) And we can get rid of these if we Failure Lot of unfinished want. Fear of Demand work (WIP) transparency Copyright Reaktor 2013 Luottamuksellinen
  • 32. Large Scale Large Scale is a System Condition. It is a result of thinking by those who decide how work is designed and managed. As a system condition, it has major impact on the performance. And since it is man made, it can be changed. Copyright Reaktor 2013 Luottamuksellinen
  • 33. Putting things in perspective •  Up to 80% of work in organization is Failure Demand –  What if you could get rid of it? Or reduce it? •  Significant amount of work in project is caused by large amount of WIP –  What if that disappears as well? •  Keep in mind the pear-shape organization and super-linear cost of scaling… •  Reducing project size by X% decreases costs by a lot more than X% Copyright Reaktor 2013 Luottamuksellinen
  • 34. 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-toend Agile project before attempting a large scale Agile project? Copyright Reaktor 2013 Luottamuksellinen
  • 35. But hey, … •  “You are overreacting. We all know large scale may not be the best solution. But it is usually unavoidable. And it works” Copyright Reaktor 2013 Luottamuksellinen
  • 36. It is not perfect but it works Copyright Reaktor 2013 Luottamuksellinen
  • 37. It is not perfect but it works If it works, don’t fix it - American Car manufacturers, 1970s Copyright Reaktor 2013 Luottamuksellinen
  • 38. Example of new thinking •  Squads, chapters, tribes, guilds … •  Most important is thinking! Alignment Autonomy “Structure happens!” Copyright Reaktor 2013 Luottamuksellinen
  • 39. Summary •  Attempts to do knowledge work in large scale are likely to fail –  …or at least they are 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: both external and internal –  Fear of fast feedback and immediate visibility •  Large Scale is a System Condition –  System conditions can be changed Copyright Reaktor 2013 Luottamuksellinen