Software project managers, who are responsible for shepherding software projects to completion, often feel like they are on a cross-country trip with several youngsters in the back seat. It seems like every few minutes someone asks, “Are we there yet?”
Cycle time for a software project is usually understood to mean the elapsed calendar time between official project start (problem statement and scope is agreed upon, and staff is assigned) and the time the resulting software system is operationally available to the customer (tested, documented, installed, trained and supported). In other words, cycle time is the elapsed calendar duration required to fully deliver an agreed-on amount of functionality.
What Drives Cycle Time?
Primary factors that drive cycle time include:
Amount of functionality to be delivered – The “size” can be measured in function points, story points, use cases, lines of code or whatever. Note that any discussion of cycle time improvement is meaningless absent the “how much” (size) dimension – it is trivially obvious that we can deliver faster if we deliver less.
The delivered quality requirements – Clearly a software company can deliver anything more quickly if it does not need to work when delivered. Hence, a meaningful measurement of cycle time improvement needs to consider some measure of delivered quality, such as defects per size or defect containment effectiveness.
Time on task – This is the extent to which the project team is actually devoting time to the project of interest. Rarely is it 100 percent. Most teams will spend a certain amount of time fixing defects related to a prior release, working on other parallel projects, attending training, taking vacations, etc. Interruptions are a fact of life and have a profound, but usually unmeasured, impact on both cycle time and productivity. Every interruption requires a “context switch,” i.e., absorbing the particulars related to the cause of the interruption, such as understanding the specifics of a prior release defect report, investigating potential causes, determining potential solutions, implementing and testing fixes.
(The nature of most software work involves a significant amount of complexity. Software developers must marshal many facts about logic flows, data structures, business rules and other considerations in their conscious memory in order to determine the proper course of action. Immersion in the necessary details often takes hours or days, and sometimes weeks. Worse, upon return to the original project problem, they must repeat the same sort of immersion in the relevant facts and data. Some studies suggest that this context switching can absorb up to 50 percent of total effort when interruptions are frequent, as often they are. Hence, one key to improving cycle time is reducing interruptions that require context switching.)
Defect insertion rate – This is largely a function of the experience level of the assigned personnel, the complexity of the problem being addressed and the reasonableness of the established schedule. As all industry cost-estimating models clearly demonstrate, excessive schedule pressure leads to significantly higher defect insertion rates, and hence higher rework.
Appraisal methods and timing – The type and amount of appraisal (reviews, inspections, testing) done at each phase of the development process (requirements, design, construction) has a profound influence on the effort required to find and fix defects. Failure to do sufficient early appraisal leads to significantly increased effort in appraisal (defect-finding) and rework (defect-fixing). More effort spent on finding and fixing defects invariably leads to longer cycle times.
Hand-offs and queues – Lean thinking has clearly shown that that both hand-offs and batch queues contribute to increases in cycle time. Smaller batches (functional scope) and end-to-end team responsibility contribute positively to reduced cycle time.
How Can Cycle Time Be Reduced?
In the near term, most organizations can realize meaningful cycle time reductions by adopting Agile methods. Agile reduces cycle time in many situations because:
- Smaller teams undertake smaller units of work and are hence more efficient.
- Smaller iterations facilitate parallelism. Iteration A can be tested while Iteration B is being built and Iteration C is being defined (requirements are being determined).
- Smaller units of functionality are less complex, and defect insertion rates are consequently lower.
- Shorter iterations reduce the consequences of requirements changes driven by changing business circumstances.
- Most Agile teams are structured so that they have end-to-end responsibility – hence fewer hand-offs and shorter queues or backlogs of incomplete work.
- It may, in some instances, be less difficult to manage and reduce interruptions.
In the longer term, it remains important to address and measure all of the factors that contribute to longer cycle times. Agile methods can reduce, but do not eliminate, root causes of cycle time problems. Lean Six Sigma drives to root-cause solutions.
Certainly cycle time is an important Y (outcome metric), but so is efficiency, which might be defined as cost (effort) per unit of functionality delivered (size). Ultimately, cycle time and efficiency are intimately connected. Optimizing one without regard to the other is certainly false economy. If shorter cycle time leads to lower throughput (cumulative functionality delivered), the gain can easily be an illusion. In some circumstances that can occur as a consequence of testing overhead associated with subsequent iterations, especially when there are many inter-dependencies with other systems. Even when cycle time is the primary metric of effectiveness (the primary CTQ, or critical-to-quality element), productivity will always be an important secondary metric. No matter how it is sliced, efficiency will always constrain cycle time.
