9599632723 Top Call Girls in Delhi at your Door Step Available 24x7 Delhi
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
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
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
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
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