32:T64d,md `### Observation 1: Without moderate variability, utilization doesn't matter (as much) The first thing we can explore is that utilization isn't a factor if variability is zero or very low. Think of it as every car moing at exactly the same speed on a freeway. Even at 100% utilization, every car enters (zero arrival time variability) and leaves (cycle time variability) without any delay. There is zero queuing time. This is of course not the general case in anything other than the theoretical for software development. | With zero variability | With moderate variability | With higher variability | | ---------------------------- | ----------------------------- | ----------------------------- | | cycle time: 5 | cycle time: 5 | cycle time: 5 | | utilization: 99% | utilization: 99% | utilization: 99% | | cycle time variability: 0 | cycle time variability: 0.2 | cycle time variability: 0.5 | | arrival rate variability: 0 | arrival rate variability: 0.2 | arrival rate variability: 0.5 | | | | | | Results | Results | Results | | ------- | ------- | ------- | | Queue time: 0 | Queue time: 20 | Queue time: 124 | | Process efficiency: 100% | Process efficiency: 20% | Process efficiency: 4% | | | | |
Software developmnt typically has a process of efficiency of 5-15% meaning we are in these areas, and highly impacted by excessive utilization.`33:T829,md `### Observation 3: There are TWO types of variability we must consider The two types of variability Kingman's Formula uses to compute queue time are - Cycle time (or service time) variability - Arrival rate variability Cycle time variability is the most often discussed and managed system variability. A whole lot of management goes around making cycle time predictable. But, that is just one part of the equation. The often missed and mis-understood variable is how to manage arrival rate. Think about a grocery store checkout. Queue time is different depending of 100 people turn up all at once versus 100 people over 24 hours. The same with our processes, if incoming work arrival time is all at one time a lot of that work will be queued waiting; if incoming work was predictable and spread out evenly over a time period, queuing time will be less on average. This means that if you CANNOT control arrival rates (helpdesk tickets for example), but you need fast turnaround of those tickets, you need to run at lower utilization. Just like emergency services, we are willing to have more idle time of the necessary resources (equipment and people to operate them) to ensure rapid response when needed. If response time is costly and important, run at lower average utilization. Here are some ideas for managing arrival rates where possible - - Work in Progress limits protect the system from being deluged with work at one time, but it really just pushes that queue time to another upstream spot - Incentivise using "slow" times. Electricity suppliers learned long ago that they could incentivise people with lower costs to use "off-peak" periods for their workload. A lot of industry uses night-shifts to take advantage of lower costs, and the electricity supplier gets more even demand for its system. - Selecting what work gets impacted by queued time and what doesn't, using prioritization or class of service. Don't allow lower priority work to impact higher priority work by adding to the arrival rate variability, schedule that low priority work at low-peak times. `34:T726,md `

### About the Kingman's Formula The [Kingman's Formula](https://en.wikipedia.org/wiki/Kingman%27s_formula) was first published by John Kingman in 1961 in a paper titled, The Single Server Queue in Heavy Traffic. ${tex`\mathbb E(W_q) \approx \left( \frac{\rho}{1-\rho} \right) \left( \frac{c_a^2+c_s^2}{2}\right) \tau`} where ''τ'' is the mean service time (i.e. ''μ'' = 1/''τ'' is the service rate), ''λ'' is the mean arrival rate, ''ρ'' = ''λ''/''μ'' is the utilization, ''c_a'' is the [[coefficient of variation]] for arrivals (that is the standard deviation of arrival times divided by the mean arrival time) and ''c_s'' is the coefficient of variation for service times. It has proven to be very accurate at predicting the mean queuing time of system that can service one thing at a time. Software development systems are a form of queuing system, evident in having a backlog and people working on those items somewhat individually (although sometimes in parallel and concurrently). There is evidence that software delivery systems encounter higher delays at higher utiliztion and higher variability. One of the strogest pieces of evidence is that items estimated to be of similar effort to produce can take very different lead-times when atually developed. The causes of this difference in total-lead time is the amount of time different work items spend idle in a witing state (non-hands-on time) measured as process efficiency. 100% process efficiency means all hands-on time, and as that number gets lower so does the ratio of hands-on to queued time. This formula allows us to exlore the interplay between system utilization and variability to understand when and why some systems have a large amount of non-hands-on time versus hands-on time and vice-verca.` 35:T85f,data = [ { p: 0, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.0,serviceTimeMean2, variability, 0)}, { p: 5, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.05,serviceTimeMean2, variability, 0)}, { p: 10, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.1,serviceTimeMean2, variability, 0)}, { p: 15, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.15,serviceTimeMean2, variability, 0)}, { p: 20, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.2,serviceTimeMean2, variability, 0)}, { p: 25, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.25,serviceTimeMean2, variability, 0)}, { p: 30, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.3,serviceTimeMean2, variability, 0)}, { p: 35, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.35,serviceTimeMean2, variability, 0)}, { p: 40, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.4,serviceTimeMean2, variability, 0)}, { p: 45, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.45,serviceTimeMean2, variability, 0)}, { p: 50, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.5,serviceTimeMean2, variability, 0)}, { p: 55, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.55,serviceTimeMean2, variability, 0)}, { p: 60, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.6,serviceTimeMean2, variability, 0)}, { p: 65, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.65,serviceTimeMean2, variability, 0)}, { p: 70, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.70,serviceTimeMean2, variability, 0)}, { p: 75, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.75,serviceTimeMean2, variability, 0)}, { p: 80, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.80,serviceTimeMean2, variability, 0)}, { p: 85, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.85,serviceTimeMean2, variability, 0)}, { p: 90, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.9,serviceTimeMean2, variability, 0)}, { p: 95, cycleTime: serviceTimeMean2, time: kingmanQueueTime(0.95,serviceTimeMean2, variability, 0)} ];36:[] 30:{"title":"How Does Utilization Impact Lead-time of Work?","cells":[{"id":0,"value":"md`# How Does Utilization Impact Lead-time of Work?`","pinned":false,"hidden":false,"mode":"ojs"},{"id":4,"value":"md `Does system utilization impact the amount of time it takes to complete work? This notebook examines the impact of utilization and suggests ways to minimize that impact. Kingman's Approximation is a mathematical formula use to estimate the queue time (which is in addition to the work time) in a system based on utilization, arrival variability and service time variability. We can use it to understand why \"similar effort\" things can take massively different amounts of time to develop in software systems.`","pinned":false,"hidden":false,"mode":"ojs"},{"id":245,"value":"md `### Set these four inputs to calculate the queuing time for this system (time waiting to get started) on average`","pinned":false,"hidden":false,"mode":"ojs"},{"id":9,"value":"viewof serviceTimeMean = slider3({\n message:'Set the average cycle time (1 to 50 minutes/hours/days): ',\n min: 1, \n max: 50,\n start: 5,\n step: 1, \n int:true})","pinned":false,"hidden":false,"mode":"ojs"},{"id":39,"value":"viewof p100 = slider3({\n message:'Set the system utilization (0 to 100%): ',\n min: 0.0, \n max: 99,\n start: 80,\n step: 1,\n precision: 2})","pinned":false,"hidden":false,"mode":"ojs"},{"id":24,"value":"viewof serviceTimeVariability = slider3({\n message:'Set the system cycle time variability (0 to 1): ',\n min: 0.0, \n max: 1.0,\n start: 0.5,\n step: 0.1, \n precision: 2})","pinned":false,"hidden":false,"mode":"ojs"},{"id":23,"value":"viewof arrivalTimeVariability = slider3({\n message:'Set the arrival rate variability (0 to 1): ',\n min: 0.0, \n max: 1.0,\n start: 0.5,\n step: 0.1,\n precision: 2})","pinned":false,"hidden":false,"mode":"ojs"},{"id":152,"value":"html`

Queue Time avg: ${kingmanQueueTime(p,serviceTimeMean, serviceTimeVariability, arrivalTimeVariability)} +

Cycle time avg: ${serviceTimeMean} = Total time: ${serviceTimeMean + kingmanQueueTime(p,serviceTimeMean, serviceTimeVariability, arrivalTimeVariability)}. (Process Efficiency: ${Math.round((serviceTimeMean / (serviceTimeMean + kingmanQueueTime(p,serviceTimeMean, serviceTimeVariability, arrivalTimeVariability)) * 100))}%) `","pinned":false,"hidden":false,"mode":"ojs"},{"id":167,"value":"html`

Experiment with the values above by moving the sliders and see the impact on queue time and process efficiency (hands-on / total time). We cover the formula used in this calculator and the units of measure more below.

`\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":251,"value":"$32","pinned":false,"hidden":false,"mode":"ojs"},{"id":312,"value":"md `Although the actual units of measure used here as variability isn't clear to you yet, you can see the difference even a small amount of variability causes on process efficiency at higher utilizations. In a factory machine environment where variability can often be eliminated by design, if we are working in a process that has inherent variability (invention or ANYTHING involving people) utilization will be a big impact on queuing time.`","pinned":false,"hidden":false,"mode":"ojs"},{"id":281,"value":"md `### Observation 2: Queue time explodes after 80% utilization\n\nThe impact of utiliztion on queue time isn't linear. Initially it is very slight, but after 80% it absolutely explodes. Experiment with the impact of variability on the queuing time (shown in orange). Notice that altering the average cycle time DOESN'T change what utilization crosses the queue-time (the ratio of impact stays the same, just the Y-axis value changes). \n\nVariability AND Utilization alter the shape (and impact) of queuing time and process efficiency. We have to control both utilization AND vriability to avoid the 10x - 20x queue times that can quickly form if utilization goes unchecked.\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":437,"value":"viewof serviceTimeMean2 = slider3({\n message:'Set the average cycle time (1 to 50 minutes/hours/days): ',\n min: 1, \n max: 50,\n start: 25,\n step: 1, \n int:true})","pinned":false,"hidden":false,"mode":"ojs"},{"id":440,"value":"viewof variability = slider3({\n message:'Set the variability (0 = none, 0.4 = moderate, 0.8 = high) (0 to 1): ',\n min: 0.0, \n max: 1.0,\n start: 0.4,\n step: 0.1, \n precision: 2})","pinned":false,"hidden":false,"mode":"ojs"},{"id":364,"value":"chart = {\n const svg = d3.create(\"svg\")\n .attr(\"viewBox\", [0, 0, width, height]);\n\n svg.append(\"g\")\n .call(xAxis);\n\n svg.append(\"g\")\n .call(yAxis);\n \n svg.append(\"path\")\n .datum(data)\n .attr(\"fill\", \"none\")\n .attr(\"stroke\", \"orange\")\n .attr(\"stroke-width\", 3)\n .attr(\"d\", line);\n \n svg.append(\"path\")\n .datum(data)\n .attr(\"fill\", \"none\")\n .attr(\"stroke\", \"steelblue\")\n .attr(\"stroke-width\", 3)\n .attr(\"d\", lineCycleTime);\n \n svg.selectAll('circle')\n .data(data)\n .enter().append('circle')\n .attr('r', 5)\n .attr('fill', 'orange')\n .attr('cx', d => x(d.p))\n .attr('cy', d => y(d.time))\n \n svg.append(\"text\") \n .attr(\"transform\",\n \"translate(\" + (width/2) + \" ,\" + \n (height + 0) + \")\")\n .style(\"text-anchor\", \"middle\")\n .text(\"Utilization %\");\n \n return svg.node();\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":460,"value":"html`

Queue Time avg

Cycle time avg. \n\n

Note: This graph stops at 95% utiliztion, because after that queue time grows SO MUCH that it makes the chart unusable. But, I bet your processes encourage 100% utilization! You need to stop that if you have any variability.

`","pinned":false,"hidden":false,"mode":"ojs"},{"id":476,"value":"$33","pinned":false,"hidden":false,"mode":"ojs"},{"id":491,"value":"md `## Conclusions\nUtilization above 80% in even moderately variabile systems will have a MASSIVE impact on the queued time and process efficiency of a system. If we can't manage the variability of that work (often the case in innovative and difficult work) then we must maintain control and reserve capacity of utiliztion in order to avoid a 10x to 100x waiting (queued) time which is excessively more expensive than holding rserve capacity.\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":533,"value":"md `### What is the economic impact of utilization? \nWhen is it more cost effective to add new capacity? See this notebook: [The Economic Impact of High System Utilization](https://observablehq.com/@troymagennis/the-economic-impact-of-high-system-utilization?collection=@troymagennis/agile-software-development). `","pinned":false,"hidden":false,"mode":"ojs"},{"id":294,"value":"$34","pinned":false,"hidden":false,"mode":"ojs"},{"id":541,"value":"md `

\n#### Training and consulting - contact us...\nFocused Objective offers training and consulting on metrics and forecasting applied to software development. If you are interested in on-site or public workshops to teach how to plan and manage software development using practical and proven techniques please email me: [troy.magennis@focusedobjective.com](mailto:troy.magennis@focusedobjective.com). If you are interested in following more of my work on Twitter connect at [@t_magennis](http://twitter.com/t_magennis). Always happy to spend an hour on the phone to see if I can help in any way.\n

`","pinned":false,"hidden":false,"mode":"ojs"},{"id":483,"value":"md `

\n### Inner workings of this notebook, you can ignore unless curious`","pinned":false,"hidden":false,"mode":"ojs"},{"id":36,"value":"\n function kingmanQueueTime (p,stm, stv,atv) {\n let result = ((p/(1-p)*((Math.pow(atv,2)+Math.pow(stv,2))/2)*stm));\n return Math.round(result,3);\n }\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":232,"value":"p = p100/100","pinned":false,"hidden":false,"mode":"ojs"},{"id":86,"value":" function slider3({\n message = 'Set your value', \n min = 0, max = 1, start = 0.5, step = 0.1,\n precision = 3, int = false,\n}){\n \n min = min/step;\n max = max/step;\n start = start/step;\n \n const div = html`\n\t${message}\n \n ${start*step}\n `;\n const range = div.querySelector(\"[type=range]\");\n const value_disp = div.querySelector('span');\n div.value = value_disp.innerHTML = start*step;\n\n \n range.addEventListener(\"input\", () => {\n const newValue = range.valueAsNumber*step; \n div.value = newValue;\n value_disp.innerHTML = int ? Math.round(newValue) : newValue.toPrecision(precision); \n });\n return div;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":384,"value":"$35","pinned":false,"hidden":false,"mode":"ojs"},{"id":366,"value":"height = 500","pinned":false,"hidden":false,"mode":"ojs"},{"id":368,"value":"margin = ({top: 20, right: 30, bottom: 40, left: 40})","pinned":false,"hidden":false,"mode":"ojs"},{"id":370,"value":"y = d3.scaleLinear()\n .domain(d3.extent(data, d => d.time))\n .range([height - margin.bottom, margin.top])","pinned":false,"hidden":false,"mode":"ojs"},{"id":372,"value":"x = d3.scaleLinear()\n .domain(d3.extent(data, d => d.p))\n .range([margin.left, width - margin.right])","pinned":false,"hidden":false,"mode":"ojs"},{"id":401,"value":"yAxis = g => g\n .attr('transform', `translate(${margin.left}, 0)`)\n .call(d3.axisLeft(y))","pinned":false,"hidden":false,"mode":"ojs"},{"id":377,"value":"xAxis = g => g\n .attr('transform', `translate(0, ${height - margin.bottom})`)\n .call(d3.axisBottom(x))","pinned":false,"hidden":false,"mode":"ojs"},{"id":360,"value":"d3 = require(\"d3@5\")","pinned":false,"hidden":false,"mode":"ojs"},{"id":362,"value":"line = d3\n .line()\n .defined(d => !isNaN(d.time))\n .x(d => x(d.p))\n .y(d => y(d.time))","pinned":false,"hidden":false,"mode":"ojs"},{"id":455,"value":"lineCycleTime = d3.line()\n .defined(d => !isNaN(d.cycleTime))\n .x(d => x(d.p))\n .y(d => y(d.cycleTime))","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W36","stdlib":"1","titling":"auto"}