Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives
From Backlog to Acceptance and In Between –
The Value of Cycle Time Analysis
Have you ever wondered if there is a science to determining how long a customer will wait on hold or stand in a line/queue waiting for something until they just hang up or give up? Yes there is, and it is called Little's Law. Let's explore why you should care and what this has to do with the PMLC/SDLC.
Actually there are quite a few analogs regarding cycle time that we could delve into:
- In its purer sense, process cycle time is a core component of process capability from a throughput and customer satisfaction standpoint.
- In Agile methodologies, Kanban uses cycle time as a primary measure for delivering customer value through delivered user stories, features, or requests fulfilled.
- In another popular Agile methodology, Scrum, the number of user stories or story points correlates to delivery of customer value though the measure of delivery velocity over a fixed cycle time (Sprint).
- Acceptability of SLAs in a product support model for acceptable down time when a fault occurs, including a measure of mean time to response or resolution.
- Network or application performance resulting in wait states for transaction processing
- The use of an enabling technology to increase process capability or capacity
- Tools to make your code more efficient within a program, making your algorithms run faster, resulting in fewer or shorter wait states between transactions
The common denominator in all these examples is time verses the delivery of customer value, with cost reduction through reduced cycle time and increased capacity, capability, and performance.
Before we go much further here are some definitions to turn what seems like common sense into a measurement method for your development and delivery processes.
Process Cycle Time (PCT)
PCT is simply the time it takes for the process to be executed. It is a composite of Value Add Time (VAT) (steps in which a tangible product is being created) verses Non-Value Add Time (such as approvals and wait states between VAT). PCT is measured in duration instead of effort since the work being done is not continuous.
Wait States or Queue Time
These equivalent terms both refer to the time between process steps, or to process steps that may not yield a measureable or tangible product but are necessary for the process to function. These wait states need to be factored into the overall PCT. An example in agile development is resource availability when determining the percentage of time a team resource can work on the project. The Queue Time would be the time the resource is spending on non-project or administrative work, which creates a difference between effort and duration estimation during the planning phase of a sprint. It is also sometimes referred to as tax on the team or process. Here's one method of calculating it:
Average Queue Time = Inventory / Throughput
Work In Progress (WIP)
WIP is work that has been started and is currently being worked on by the team. In Kanban it is also known as the WIP Bin, where work has been selected or "pulled" from the product backlog to be worked on. The number of WIP components has a direct correlation to cycle time and throughput or Exit Rate. Having too many work items in the WIP Bin can also slow down or even completely halt work in progress.
Exit Rate is the number of products that can be delivered in a given timeframe. An example is the number of user stories that are delivered per sprint, or in Kanban the number of user stories delivered in a given cycle period such as a week or month. Throughput is a direct measure of process capability.
From a process standpoint, inventory is the total amount of work within any of the steps in the system or process. Think of it as an inventory of tasks verses physical product inventory. It is often calculated using this formula:
Average inventory = Throughput * Average queue time
John Little developed the law that bears his name as a theory of probability in 1954. Little's Law was focused around customers waiting in line and the impact of new customers (inventory) on the wait times for existing queues (throughput). In this article we will take the core components of Little's Law and adapt them for more practical purposes.
Do More with Less
To reduce the wait time, reducing inventory actually increases throughput. While it may seem counter-intuitive, having a finite number of resources available to process too much inventory slows the whole process down or can also reduce quality (as mentioned previously in the WIP definition).
Let's explore an example of a single-thread process: a drive-through window where only one car can go through the process at a time.
- Order -- 20 seconds
- Pay -- 30 seconds
- Collect -- 40 seconds
- Total process cycle time (PCT = Order + Pay + Collect) 20+30+40 = 90 seconds, or a throughput rate of 0.0111 customers per second
When five cars go through the line at the same time, the time from order to collection is 200 seconds or 0.025 customers per second. With an inventory of five, more customers were served but the cycle time significantly increased.
Let's try that example with only three cars: When three cars go through the line at the same time from order to collection the elapsed time is 120 seconds or 0.025 customers per second. In this illustration, putting three cars at a time through the drive-through serves the same number of customers as five cars, but with an 80-second reduction in average PCT.
Reflecting back to Little's Law, other parts of the process, such as taking and transferring the order can cause friction across the whole process which can impact total process cycle time (PCT). Other sub-processes such as how the order is fulfilled (not being measured here) may be the culprit and warrant further investigation. If the capacity of the process needs to be scaled up to meet customer demand these sub-processes should be measured using the same methods.
These data demonstrate that there is an optimum level of inventory that can be processed in a constrained environment. In the table below, the optimum PCT and throughput rate is either two or three cars in the system at a given time.
This theory holds true for Kanban cycles, or for teams working on user stories during a sprint. Quite often, user stories have to be split at the end of a sprint because of too much work was in process. Another example is when one or more user stories become blocked or constrained during the sprint, causing extended wait states for one or more user stories. There is also a cost for restarting the user story at the beginning of the next sprint, which impacts the overall cycle time of the next sprint or cycle period. These wait states accumulate over the longer duration of a release, month, or quarter, impacting the overall development process performance. This can lead to the perception that the overall delivery is taking too long, potentially impacting customer satisfaction.
It is important to assess the expected cycle time of a blocked or constrained user story to determine if it should be relegated to the backlog until the constraint is removed (or until the cycle time of the user story can reach an optimum throughput rate). Quite often teams just leave these stories in the WIP bin in the hope that some magic will occur that allows them to restart the work.
Another common pitfall occurs when a user story in the WIP bin is blocked and a new user story is added, but not completed, before the original story becomes unblocked. The story owner may not have the capacity to complete both stories within the cycle time remaining.
If this issue occurs I would recommend an assessment of which story to move forward with and whether the subordinated story should be returned to the backlog.
These practices can lead to confusion on the progress of a blocked or constrained user story, which will impact the overall throughput rate of the non-constrained user stories. Having "dead wood" in your WIP bin therefore increases process cycle time and leaves throughput rate unchanged, as those constrained stories are left in the queue and have to be addressed in the future.
Theory of Constraints
Another analog to the adage "do more with less" is borne out of the Theory of Constraints, which is derived from Eliyahu M. Goldratt's management philosophy as described in his 1984 book, The Goal. The Theory of Constraints concept focuses on identifying where the constraint lies and addressing it using root cause analysis methods. There are several steps involved in the Theory of Constraints. Typically, constraints consist of either processes, policies, people, machinery or parts inventory to complete the product. These constraints can also be illustrated using a Fishbone or Ishikawa Diagram.
The Five Focusing Steps
Step 1 - Identify the bottlenecks: Identification of the "bottleneck" impacts throughput/cycle time until the next constraint is identified and resolved, driving improvements in process capability until the process is running at optimum performance. Local optimums are the conditions that exist within a process step, but unless the process step is considered a bottleneck improving local optimums on a non-constraining step will not improve overall throughput.
Step 2 - Exploit: Take the process step to its maximum capacity by removing local constraints within the process step. For example, would it help to add more people resources, or break the task up across multiple resources?
Step 3 - Subordinate: Take resources from other non-critical tasks or steps to address the bottleneck. An analog to this in project management is crashing the schedule, where the focus is just on critical path items.
Step 4 - Elevate: Make lasting improvements in the process step to permanently remove the bottleneck. Add a resource, increase computing capacity, or make a policy or process change.
Step 5 - Repeat: Repeat the process and re-measure to see if the bottleneck has improved or has been removed.
The Thinking Processes
The Thinking Processes with Theory of Constraints use a cause and effect problem-solving methodology to determine answers to these questions:
- What needs to change?
- What should it be changed to?
- What actions need to be taken to effect the change?
You know a process is running at optimum performance when measuring the impact of removing or improving a constraint by determining if the resulting change continues to have material improvement on PCT or throughput. At this stage, upper and lower control limits can be placed via a Control Chart to validate that the process is running at its optimum performance. Any negative constraint within the system or process is known as an Undesirable Effect or UDE.
Some Additional Tree Tools
The tools below are a sampling of the many tools that are available within The Thinking Processes, more of which can be explored in the Further Reading section below.
Current Reality Tree
This tree provides a view of the current state of the undesirable effects (UDEs) in the process or system, inclusive of a root cause and mitigant.
Strategy and Tactics Tree
Focuses on the why, what, and how, or the logistics of the actions needed to effect the improvement.
Evaporating Cloud Tree
This tree is fundamentally a conflict resolution diagram where there is more than one method of attaining the objective. There are injection points where an approach or methodology is used to achieve the objective. The point of conflict is where there is a decision to be made between the points of conflict.
Future Reality Tree
This to-be tree contains the Desired Effect (DE) or objective of the improved state of the process or system. The Injection Points are the improvements that are made to achieve the Desired Effect.
Next time you are waiting in line at an amusement park, planning your next software release, or optimizing a steady state process, think about Mr. Little and his theorem. It can be adapted within Lean and Agile methodologies to drive quantification metrics and cause and effect into optimizing your product quality and delivery throughput.
As is now obvious, it is not just about arriving at your deliverable, but more about the journey you take to get there, the decisions and paths you take to reach your mission and goals through efficiencies and waste reduction.