Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace: • how_do_we_use_story_point_estimates_to_forecast • how_should_we_initially_track_release_progress • why_do_we_assign_business_values_to_pi_objectives • how_do_i_help_raise_awareness_of_transformation_problems • what_are_the_potential_problems_implementing_okrs_in_an_organization • what_is_session_based_testing • safe_values_and_principles • what_are_the_problems_with_estimation • why_don_t_we_use_gantt_charts_in_agile • what_is_wrong_with_100_utilization_thinking
what_is_wrong_with_100_utilization_thinking

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
what_is_wrong_with_100_utilization_thinking [2016/03/30 09:22] – [Understanding Real Cause and Effect of Utilization] hpsamioswhat_is_wrong_with_100_utilization_thinking [2020/06/04 11:19] (current) – Removed LINKBACK hans
Line 1: Line 1:
 ====== What Is Wrong With 100% Utilization Thinking? ====== ====== What Is Wrong With 100% Utilization Thinking? ======
- 
-====== Premise ====== 
- 
 As a person who has spent way too many years managing many projects, working with a lot of financial people, and who has worked to improve the results of a lot of organizations, one thing I was expected to focus on was "utilization rates" for people. The thinking seems straight-forward - if we are paying a certain amount of money for a person we can increase the return (value produced) associated with that person by making sure, at a minimum, that the person is working all the time and is always busy. As result I'd work to ensure that people were 90%, 100% utilized and be happy when people reported 110% utilization. As a person who has spent way too many years managing many projects, working with a lot of financial people, and who has worked to improve the results of a lot of organizations, one thing I was expected to focus on was "utilization rates" for people. The thinking seems straight-forward - if we are paying a certain amount of money for a person we can increase the return (value produced) associated with that person by making sure, at a minimum, that the person is working all the time and is always busy. As result I'd work to ensure that people were 90%, 100% utilized and be happy when people reported 110% utilization.
  
Line 8: Line 5:
  
 ====== Understanding Real Cause and Effect of Utilization ====== ====== Understanding Real Cause and Effect of Utilization ======
- 
-I want you to have a look at the following chart((Basis of chart results come from [[the_principles_of_product_development_flow_second_generation_lean_product_development_-_don_reinertsen|The Principles of Product Development Flow: Second Generation Lean Product Development - Don Reinertsen]] although it has been liberally interpreted to aid in understanding.)): 
  
 {{ :cycle_time_vs_utilization_rates.jpg?500 |}} {{ :cycle_time_vs_utilization_rates.jpg?500 |}}
 +
 +I want you to have a look at the chart((this version of chart results come from [[the_principles_of_product_development_flow_second_generation_lean_product_development_-_don_reinertsen|The Principles of Product Development Flow: Second Generation Lean Product Development - Don Reinertsen]] which was originally from the Kingsman Formula, although it has been liberally interpreted to aid in understanding.)):
  
 This is what actually happens when you increase the utilization rate beyond a certain threshold. Basically it says that "as we approach 100% utilization the time it takes to process something becomes exponentially large." This is an application of "queuing theory". It turns out that every time you halve the amount of excess capacity, you double the time it takes to process something. So as you move from 60% to 80% utilization you double the time it takes to process something, and moving from 80% to 90% will double it again. This is what actually happens when you increase the utilization rate beyond a certain threshold. Basically it says that "as we approach 100% utilization the time it takes to process something becomes exponentially large." This is an application of "queuing theory". It turns out that every time you halve the amount of excess capacity, you double the time it takes to process something. So as you move from 60% to 80% utilization you double the time it takes to process something, and moving from 80% to 90% will double it again.
  
 What does this say about loading up a person's work to 100% utilization? Basically if you are focussing on utilization rates there will come a point when you are valuing someone being "busy" over someone producing something in a timely manner. What does this say about loading up a person's work to 100% utilization? Basically if you are focussing on utilization rates there will come a point when you are valuing someone being "busy" over someone producing something in a timely manner.
 +
 +Interestingly you instinctively understand this effect even if you have not applied this to software. If you have a road system filled to capacity with cars and you are a car trying to get from point "A" to point "B" what are your chances? A "road system filled to capacity" is a traffic jam and so you will take a long time to get to your location.
 +
 ====== Now What Are You Going To Do? ====== ====== Now What Are You Going To Do? ======
  
Line 31: Line 31:
  
   - Limit work to capacity (don't try to take on too much at a time)   - Limit work to capacity (don't try to take on too much at a time)
-  - Even out the arrival of work+  - Even out the arrival of work (budgeting, approval and contracting processes tend to mean arrival of work is in big lumps and not even)
   - Minimize the number of things-in-process (work-in-progress, or WIP)   - Minimize the number of things-in-process (work-in-progress, or WIP)
   - Minimize the size of the things-in-process (small batch sizes - see [[What is the Effect of Batch Size on How Long Something Takes to Get Done]])   - Minimize the size of the things-in-process (small batch sizes - see [[What is the Effect of Batch Size on How Long Something Takes to Get Done]])
-  - Establish a regular cadence+  - Establish a regular cadence (establishes a predictable workflow and a reliable pace, allows for faster feedback and for staged delivery)
   - Use pull scheduling   - Use pull scheduling
- 
  
 ====== Want to Know More? ====== ====== Want to Know More? ======
Line 43: Line 42:
   * [[http://www.leanessays.com/2010/11/managing-pipeline.html|"Managing the Pipeline"]] by Mary Poppendieck. Mary is one of the original thinkers in the are of lean principles applied to software development. Her essays are always useful and get more useful as you need to grow your implementation of agile and lean to the overall organization.   * [[http://www.leanessays.com/2010/11/managing-pipeline.html|"Managing the Pipeline"]] by Mary Poppendieck. Mary is one of the original thinkers in the are of lean principles applied to software development. Her essays are always useful and get more useful as you need to grow your implementation of agile and lean to the overall organization.
   * [[http://brodzinski.com/2015/01/slack-time-value.html|Economic Value of Slack Time]]   * [[http://brodzinski.com/2015/01/slack-time-value.html|Economic Value of Slack Time]]
 +  * [[https://observablehq.com/@troymagennis/how-does-utilization-impact-lead-time-of-work?collection=@troymagennis/agile-software-development|How Does Utilization Impact Lead Time of Work]]: Excellent interactive model by @TroyMagennis allowing you to explore different how the Kingman formula works.
   * [[http://brodzinski.com/2012/03/myth-of-100-utilization.html|A Myth of 100% Utilization]]   * [[http://brodzinski.com/2012/03/myth-of-100-utilization.html|A Myth of 100% Utilization]]
- 
  
  
 {{tag>Enterprise Utilization Slack Risk RiskManagement FAQ PresentationIdea}} {{tag>Enterprise Utilization Slack Risk RiskManagement FAQ PresentationIdea}}
 +
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_is_wrong_with_100_utilization_thinking.1459354964.txt.gz · Last modified: 2020/06/02 14:23 (external edit)