LuottamuksellinenCopyright Reaktor 2013
Copyright Reaktor 2013 Luottamuksellinen
Case Against Scaling

Back to basics with your enterprise
transformation

Sami Li...
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 f...
Copyright Reaktor 2013 Luottamuksellinen
Is it just a coincidence that
Scale rhymes with Fail? *)
*)Inspired by @AgileBora...
Copyright Reaktor 2013 Luottamuksellinen
Economy of Scale
Scalability
Size
Costof
overhead
Sublinear = Scales well
Highly ...
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 s...
Copyright Reaktor 2013 Luottamuksellinen
When doing development work in
Large Scale, the key question is not
“How?” – it i...
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 lo...
Copyright Reaktor 2013 Luottamuksellinen
What the other say..
(A very opinionated view)
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?
• ...
Copyright Reaktor 2013 Luottamuksellinen
Hey, but..
•  Work-in-Progress and Little’s Law are
about time through system
•  ...
Copyright Reaktor 2013 Luottamuksellinen
Work in Progress
•  Most organizations have too many
things going on at one time,...
Copyright Reaktor 2013 Luottamuksellinen
Work in Progress
•  We underestimate the overhead that
Work-in-Progress causes
• ...
Copyright Reaktor 2013 Luottamuksellinen
Sami’s Test #1
•  Think about predictable demand that
comes to your organization
...
Copyright Reaktor 2013 Luottamuksellinen
Intermission
•  Project == Problem
•  We encapsulate product or service
creation ...
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
will...
Copyright Reaktor 2013 Luottamuksellinen
All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_...
Copyright Reaktor 2013 Luottamuksellinen
NEWITSYSTEM!
Failure demand: Not only bugs
Value
for
user
Fail
C
U
S
T
O
M
E
R 

...
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)
...
Copyright Reaktor 2013 Luottamuksellinen
Dysfunction
Something in our design and
management of work that is
causing proble...
Copyright Reaktor 2013 Luottamuksellinen
Institutionalized Dysfunction
Problem that was resolved by adding
process or mana...
Copyright Reaktor 2013 Luottamuksellinen
Institutionalized Dysfunction
and Agile Manifesto
We are uncovering better ways o...
Copyright Reaktor 2013 Luottamuksellinen
Sami’s Test #2
•  Assume you could freely choose the
smallest possible number of ...
Copyright Reaktor 2013 Luottamuksellinen
THE WAY OUT?
Copyright Reaktor 2013 Luottamuksellinen
What makes us Big?
Large organization or
project
Fear of
transparency
“We need lo...
Copyright Reaktor 2013 Luottamuksellinen
Large Scale is a System Condition.
It is a result of thinking by those who
decide...
Copyright Reaktor 2013 Luottamuksellinen
Putting things in perspective
•  Up to 80% of work in organization is Failure
Dem...
Copyright Reaktor 2013 Luottamuksellinen
Sami’s Test #3
•  OK, let’s assume you’ve done everything to
limit WIP, remove fa...
Copyright Reaktor 2013 Luottamuksellinen
But hey, …
•  “You are overreacting. We all know
large scale may not be the best
...
Copyright Reaktor 2013 Luottamuksellinen
It is not perfect but it works
If it works, don’t fix it
- American Car manufactu...
Copyright Reaktor 2013 Luottamuksellinen
•  Squads, chapters,
tribes, guilds …
•  Most important is
thinking!
Alignment
Au...
Copyright Reaktor 2013 Luottamuksellinen
Summary
•  Attempts to do knowledge work in large
scale are likely to fail
–  …or...
Copyright Reaktor 2013 Luottamuksellinen
One more thing..
Copyright Reaktor 2013 Luottamuksellinen
solving the right problem?
We are engineers.

We are trained to
solve problems.
Copyright Reaktor 2013 Luottamuksellinen
In order to improve radically,
we need to do more than just
solve problems.
We ha...
Copyright Reaktor 2013 Luottamuksellinen
Ways to deal with a problem
Absolution: ignore a problem and hope it will solve
i...
Copyright Reaktor 2013 Luottamuksellinen
Dissolution: redesign the system or its environment
in such a way that it elimina...
Upcoming SlideShare
Loading in...5
×

The Case Against Scaling Agile

328

Published on

Presentation material from Agile Finland breakfast, Mar 28 2014. See also lightning talk: https://www.youtube.com/watch?v=KT24s6N7v_k&index=3&list=PLb9a4LiaclrwgEokxjMOTueWrAKBRfIEX

Published in: Business
4 Comments
2 Likes
Statistics
Notes
  • @josephbutson Exactly my point: I am not against large companies or even large groups of people delivering value. For example airline company there are probably hundreds of people 'touching' the value to the customer. But they do not need 100+ people onboard to make people reach their destination: they are not running onboard-ITIL to manage requests to the staff, they do not have 'boarding process planning meetings'. They focus on delivering value, with smallest possible group of self-organizing people.
    My case against scaling is not against large companies or global reach; it is about being unnecessary large due to failure demand and doing the wrong thing,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @jmazloum1 Hi Julien and thanks for the question. With large or small system I would start from customer demand: what customers need and how we deliver that. Then, I'd use Kanban or Scrum or any other method to balance demand with capability.
    It is very important to understand demand and do the right thing, rather than do the things right.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I found the presentation to be quite enlightening but I am skeptical. It is very true large organizations are problematic if excessively centralized. But if they decentralize, coordinate well and communicate precisely, they can do great things that no other entity can. Think about the self organized team that are responsible for flying you to your destination. They work in a large facility, for a large company, guided by a very strict set of rules and have some of the most sophisticated systems known to man. So Large 'ideas' and organizations are so problematic as centralized thinking within them is.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Very good and very clear. The most effective way I see is to reduce WIP is to shorten release cycles. The second most effective way is to either Scrum (get things done in a Sprint) or use Kanban with WIP limits as close as possible to capacity. And you are saying that for large systems, it is usually the first thing to do. Right?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
328
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
4
Likes
2
Embeds 0
No embeds

No notes for slide

The Case Against Scaling Agile

  1. 1. LuottamuksellinenCopyright Reaktor 2013
  2. 2. Copyright Reaktor 2013 Luottamuksellinen Case Against Scaling Back to basics with your enterprise transformation Sami Lilja Reaktor Twitter: @samililja
  3. 3. Copyright Reaktor 2013 Luottamuksellinen The Beef
  4. 4. Copyright Reaktor 2013 Luottamuksellinen Solving the wrong problem Source: http://www.medscape.com/viewarticle/806573
  5. 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. 6. Copyright Reaktor 2013 Luottamuksellinen Is it just a coincidence that Scale rhymes with Fail? *) *)Inspired by @AgileBorat in Twitter
  7. 7. Copyright Reaktor 2013 Luottamuksellinen Economy of Scale Scalability Size Costof overhead Sublinear = Scales well Highly repeatable “How many?”
  8. 8. Copyright Reaktor 2013 Luottamuksellinen Labor-intensive work
  9. 9. Copyright Reaktor 2013 Luottamuksellinen Knowledge work?
  10. 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. 11. Copyright Reaktor 2013 Luottamuksellinen When doing development work in Large Scale, the key question is not “How?” – it is “Why?”
  12. 12. Copyright Reaktor 2013 Luottamuksellinen Organizations getting bigger
  13. 13. Copyright Reaktor 2013 Luottamuksellinen Pear-shape organizations
  14. 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. 15. Copyright Reaktor 2013 Luottamuksellinen What the other say.. (A very opinionated view)
  16. 16. Copyright Reaktor 2013 Luottamuksellinen The root of all Evil I Work-in-Progress
  17. 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. 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. 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. 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. 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. 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. 23. Copyright Reaktor 2013 Luottamuksellinen The root of all Evil II Failure Demand
  24. 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. 25. Copyright Reaktor 2013 Luottamuksellinen All demand is considered work Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/
  26. 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. 27. Copyright Reaktor 2013 Luottamuksellinen Internal Failure demand Do we need this process? What thinking created this?
  28. 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. 29. Copyright Reaktor 2013 Luottamuksellinen Dysfunction Something in our design and management of work that is causing problems.
  30. 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. 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. 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. 33. Copyright Reaktor 2013 Luottamuksellinen THE WAY OUT?
  34. 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. 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. 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. 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. 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. 39. Copyright Reaktor 2013 Luottamuksellinen It is not perfect but it works If it works, don’t fix it - American Car manufacturers, 1970s
  40. 40. Copyright Reaktor 2013 Luottamuksellinen •  Squads, chapters, tribes, guilds … •  Most important is thinking! Alignment Autonomy “Structure happens!” Example of new thinking
  41. 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. 42. Copyright Reaktor 2013 Luottamuksellinen One more thing..
  43. 43. Copyright Reaktor 2013 Luottamuksellinen solving the right problem? We are engineers. We are trained to solve problems.
  44. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×