The document discusses issues with attempting knowledge work at large scale in organizations. Key points made include: - Large scale is suboptimal for creating products/services and is mainly due to high work-in-progress, failure demand from both external and internal sources, and fear of fast feedback. - Large scale is a system condition that can be changed by reducing WIP, removing failure demand, decreasing complexity, and increasing transparency. - Problems should be addressed by redesigning systems and environments to eliminate root causes, rather than just solving surface problems. Attempting to scale processes like Agile is treating a symptom rather than the underlying issue of an organization's size.

1. LuottamuksellinenCopyright Reaktor 2013

2. Copyright Reaktor 2013 Luottamuksellinen
Case Against Scaling
Back to basics with your enterprise
transformation
Sami Lilja
Reaktor
Twitter: @samililja

3. Copyright Reaktor 2013 Luottamuksellinen
The Beef

4. Copyright Reaktor 2013 Luottamuksellinen
Solving the wrong problem
Source: http://www.medscape.com/viewarticle/806573

5. Copyright Reaktor 2013 Luottamuksellinen
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.
Scaling Agile?

6. Copyright Reaktor 2013 Luottamuksellinen
Is it just a coincidence that
Scale rhymes with Fail? *)
*)Inspired by @AgileBorat in Twitter

7. Copyright Reaktor 2013 Luottamuksellinen
Economy of Scale
Scalability
Size
Costof
overhead
Sublinear = Scales well
Highly repeatable
“How many?”

8. Copyright Reaktor 2013 Luottamuksellinen
Labor-intensive work

9. Copyright Reaktor 2013 Luottamuksellinen
Knowledge work?

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

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

12. Copyright Reaktor 2013 Luottamuksellinen
Organizations getting bigger

13. Copyright Reaktor 2013 Luottamuksellinen
Pear-shape organizations

14. Copyright Reaktor 2013 Luottamuksellinen
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
Big projects need lot
of people need big
projects need …
“Adding more people
will speed us up”
Lot of unfinished
work (WIP)
Silos in
organization
(Conways’s Law)
Belief in Economies
of Scale
Failure
Demand
Short-term
(Project) thinking

15. Copyright Reaktor 2013 Luottamuksellinen
What the other say..
(A very opinionated view)

16. Copyright Reaktor 2013 Luottamuksellinen
The root of all Evil I
Work-in-Progress

17. 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?

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

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

20. 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, …

21. 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?

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

23. Copyright Reaktor 2013 Luottamuksellinen
The root of all Evil II
Failure Demand

24. Copyright Reaktor 2013 Luottamuksellinen
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

25. Copyright Reaktor 2013 Luottamuksellinen
All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/

26. Copyright Reaktor 2013 Luottamuksellinen
NEWITSYSTEM!
Failure demand: Not only bugs
Value
for
user
Fail
C
U
S
T
O
M
E
R
S
U
P
P
O
R
T
“PRESS 1 IF YOU
CALL ABOUT..”
“PRESS 2 IF YOU
CALL ABOUT..”
“PRESS 3 IF YOU
CALL ABOUT..”

27. Copyright Reaktor 2013 Luottamuksellinen
Internal Failure demand
Do we need this
process?
What thinking
created this?

28. Copyright Reaktor 2013 Luottamuksellinen
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

29. Copyright Reaktor 2013 Luottamuksellinen
Dysfunction
Something in our design and
management of work that is
causing problems.

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

31. Copyright Reaktor 2013 Luottamuksellinen
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

32. 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?

33. Copyright Reaktor 2013 Luottamuksellinen
THE WAY OUT?

34. Copyright Reaktor 2013 Luottamuksellinen
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
Big projects need lot
of people need big
projects need …
“Adding more people
will speed us up”
Lot of unfinished
work (WIP)
Silos in
organization
(Conways’s Law)
Belief in Economies
of Scale
Failure
Demand
Short-term
(Project) thinking
None of these are Laws of Nature.
None of these are imposed on you.
These are the results of thinking.
And we can get rid of these if we
want.

35. Copyright Reaktor 2013 Luottamuksellinen
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.
Large Scale

36. 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%

37. 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-to-
end Agile project before attempting a large
scale Agile project?

38. 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”

39. Copyright Reaktor 2013 Luottamuksellinen
It is not perfect but it works
If it works, don’t fix it
- American Car manufacturers, 1970s

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

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

42. Copyright Reaktor 2013 Luottamuksellinen
One more thing..

43. Copyright Reaktor 2013 Luottamuksellinen
solving the right problem?
We are engineers.
We are trained to
solve problems.

44. Copyright Reaktor 2013 Luottamuksellinen
In order to improve radically,
we need to do more than just
solve problems.
We have start looking at
problems from a completely
new perspective.

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

46. Copyright Reaktor 2013 Luottamuksellinen
Dissolution: redesign the system or its environment
in such a way that it eliminates the problem or the
conditions that caused it
Dissolution: redesign the system or its environment
in such a way that it eliminates the problem or the
conditions that caused it