2. Case Against Scaling
Back to basics with your enterprise
transformation
Sami Lilja
Reaktor
Twitter: @samililja
Copyright Reaktor 2014
3. 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.
Copyright Reaktor 2014
5. Solving the wrong problem
Source: http://www.medscape.com/viewarticle/806573
Copyright Reaktor 2014
6. 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,
Copyright Reaktor 2014
vs.
We have too many meetings
vs.
decreases motivation
Coordinating between parallel projects
is not effective
vs.
We have too many parallel projects
7. 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 2014
8. Copyright Reaktor 2014
Economy of Scale
Scalability
Size
Cost of
overhead
Sublinear = Scales well
Highly repeatable
“How many?”
15. 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
Copyright Reaktor 2014
16. What makes us Big?
Large organization or
project
Fear of
transparency
Copyright Reaktor 2014
“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
17. The root of all Evil I
Work-in-Progress
Copyright Reaktor 2014
18. 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 2014
19. 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
Copyright Reaktor 2014
20. 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 2014
21. Work in Progress
• We underestimate the overhead that
Work-in-Progress causes
• In reality, large WIP causes huge and
costly problems
Copyright Reaktor 2014
– Delays
• time-through-system = Work-In-Progress / Velocity
– Queues and synchronization problems
– Internal Failure Demand
• Meetings, coordination effort, waiting, re-work, …
22. 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?
Copyright Reaktor 2014
23. 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?
Copyright Reaktor 2014
24. The root of all Evil II
Failure Demand
Copyright Reaktor 2014
25. Value demand
Adds value from customer
point of view.
Something customers are
willing to pay for.
This type of demand we want.
Copyright Reaktor 2014
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
26. All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/
Copyright Reaktor 2014
27. Failure demand: Not only bugs
NEW IT SYSTEM!
Copyright Reaktor 2014
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..”
28. Internal Failure demand
Do we need this
process?
What thinking
created this?
Copyright Reaktor 2014
29. Hidden Failure demand
Copyright Reaktor 2014
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
30. Copyright Reaktor 2014
Dysfunction
Something in the design and
management of work that is
causing problems.
31. Institutionalized Dysfunction
Problem that is resolved by adding
processes or management actions
and then focusing on actions
rather than the original problem.
Copyright Reaktor 2014
32. 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.
Copyright Reaktor 2014
Slippery slope to
institutionalized
dysfunction
33. 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?
Copyright Reaktor 2014
34. 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?
Copyright Reaktor 2014
36. 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
Copyright Reaktor 2014
“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.
37. 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…
Copyright Reaktor 2014
38. Copyright Reaktor 2014
Size
Cost of
overhead
Sublinear = Scales well
Reducing project size by
X% decreases costs by a
lot more than X%
X%
39. Copyright Reaktor 2014
But hey, …
• “You are overreacting. We all know
large scale may not be the best
solution. But it is usually
unavoidable. And it works”
40. It is not perfect but it works
If it works, don’t fix it
- American Car manufacturers, 1970s
Copyright Reaktor 2014
41. 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?
Copyright Reaktor 2014
43. What is missing from
this picture?
I can not see the
customer here..
Copyright Reaktor 2014
44. What is missing from
this statement?
What if the demand
comes from end user?
What if we are
creating a service?
Copyright Reaktor 2014
45. 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!
Copyright Reaktor 2014
46. 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”
Copyright Reaktor 2014
47. Copyright Reaktor 2014
Customers,
users
Customers,
users
Demand
Demand
Value for
customers
and users
Value for
customers
and users
49. • 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
Copyright Reaktor 2014
50. 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
Copyright Reaktor 2014
51. 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
Copyright Reaktor 2014
52. solving the right problem?
We are engineers.
We are trained to
solve problems.
Copyright Reaktor 2014
53. 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
Copyright Reaktor 2014
54. Dissolution: redesign the system or its environment
in such a way that it eliminates the problem or the
conditions that caused it
Copyright Reaktor 2014