Upload
samililja
View
840
Download
5
Tags:
Embed Size (px)
DESCRIPTION
Presentation slides from my talk "Case against Scaling" at Tampere Goes Agile on Dec 12 2013
Citation preview
Copyright Reaktor 2013 Luottamuksellinen
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
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?
Copyright Reaktor 2013 Luottamuksellinen
Is it just a coincidence that Scale rhymes with Fail? *)
*)Inspired by @AgileBorat in Twitter
Copyright Reaktor 2013 Luottamuksellinen
Economy of Scale
Scalability
Size
Co
st
of
over
head
Sublinear = Scales well
Highly repeatable “How many?”
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
Fear of transparency
“We need lot of different competences”
Short-term (Project) thinking 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
Copyright Reaktor 2013 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
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
Copyright Reaktor 2013 Luottamuksellinen
All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/
Copyright Reaktor 2013 Luottamuksellinen
NE
W IT
SY
ST
EM
!
Failure demand: Not only bugs
Value for user
Fail
CUSTOMER SUPPORT
“PRESS 1 IF YOU CALL ABOUT..”
“PRESS 2 IF YOU CALL ABOUT..”
“PRESS 3 IF YOU CALL ABOUT..”
Copyright Reaktor 2013 Luottamuksellinen
Internal Failure demand
Do we need this process?
What thinking created this?
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
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
“More people will speed us up”
“We need lot of different competences”
Belief in Economies of Scale
Big projects need lot of people need big
projects need …
Failure Demand
Short-term (Project) thinking Complex
systems
Silos in organization
(Conways’s Law)
Separating action, feedback, knowledge and
decision making
Lot of unfinished work (WIP)
Fear of transparency
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.
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
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-to-end 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
• Squads, chapters, tribes, guilds …
• Most important is thinking!
Alignment
Autonomy
“Structure happens!”
Example of new thinking
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