Case Against Scaling (Tre Goes Agile presentation, Dec 14 2013)

1,168 views

Published on

Presentation slides from my talk "Case against Scaling" at Tampere Goes Agile on Dec 12 2013

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,168
On SlideShare
0
From Embeds
0
Number of Embeds
45
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Case Against Scaling (Tre Goes Agile presentation, Dec 14 2013)

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

×