APM & SEE VOL. 15 NO. 6
Over the last decade there has been growing interest in applying Lean thinking to software. More recently, Lean methods have been extended to broader business processes that include both development and operations. DevOps practitioners set out to better integrate IT operations and software development to improve their joint responsiveness to change requests. These requests may include traditional IT problem tickets, new requirements for software for a specific market, fulfilling a contract, or for software embedded in a larger system. DevOps has the following goals:
- Reduce time needed for fulfilling a change request.
- Reduce wasted time and effort when servicing the change.
- Streamline the pipeline for the change request from operations through development to deployment.
- Balance the capacities of the change request organizations to address the change.
These are the same goals that drive the adoption of Lean management principles for manufacturing or logistics. We can describe Lean as both a mindset and a set of techniques that manage and improve flow measures, such as end-to-end cycle time (or lead time), and take full advantage of an organization's capacity to optimize the flow of material (i.e, the inventory) through the product pipeline.
The accompanying Executive Report lays out a line of reasoning on how to do just that in the software realm. It starts with a discussion of how software and DevOps, unlike the traditional targets of Lean, are best thought of as an artifact-centric business process.
We can visualize any process in two ways:
- Activity-centric. Here, the process is described by the set of operations and the order needed to carry out that process to create the work product(s). Flow charts or IDEF diagrams illustrate the operations.
- Artifact-centric. Here, the work products and their lifecycles describe the process. The process occurs by taking a work product through a transition state.
Manufacturing and logistics may be well described by the former, while any kind of knowledge creation work is better described by the latter.
The report continues with a general discussion on the role of artifacts to help teams set and achieve goals. Business processes with uncertainty are, at a high level, a sort of control loop. Teams use these steps to steer processes to achieve planned goals. Generally, to carry out the loop, a team sets a plan, starts to carry it out, checks to see if the goals are being achieved, and then takes action. There may or may not be a replan step as processes circulate the loop. Analytics can instrument the check step to inform the action taken.
Measures are essential to carrying out control loops, but they are not free. They require an investment in terms of time and effort. Collecting the wrong measures can interfere with achieving Lean goals; they may even add wasted effort and perhaps slow down the efforts. So choosing measures wisely is critical.
Next, the report shows how to apply value stream mapping -- a Lean technique to artifact-centric business processes such as software. Value stream mapping includes such core Lean measures as inventory and cycle times. Generally, each process step is associated with a detailed description of the activities needed to carry out that step. Such an activity description for manufacturing might include the following steps:
- Take a part from inventory.
- Inspect the part for rough edges.
To apply value stream maps to an artifact-centric process, start by identifying the process artifacts. Each artifact has its own lifecycle, which is a set of states it will pass through from initiation to completion. For example, a simple business request state model includes the following stages:
- Submitted
- Approved
- Developed
- Deployed
- Customer-evaluated
The key idea here is that for artifact-centric work, the process steps consist of state transitions. The following are two kinds of measures in a value stream map:
- Flow measures address how the artifacts flow through the state transitions. These include end-to-end (lead) times, the times for each state in the process (the lines at the bottom), and the artifact counts in each state.
- Process measures address team efficiency in carrying out the transitions. These measures detect whether bottlenecks are caused by a lack of capacity or simply inefficient processes.
Applying these measures to software and DevOps entails measuring and instrumenting the project artifacts' state transitions, which the report describes in detail.
The report focuses on two key areas:
- Delving into the particulars of applying the measures for the sorts of data encountered in software and DevOps
- Describing some common usage models of the measures
Today, Lean methods are essential to running competitive software and IT organizations. Competitive pressures do not permit long cycle times, bottlenecks, wasted effort, and other inefficiencies. Following the well-known Kelvin's principle -- "You can't improve what you don't measure" -- finding those inefficiencies and taking action to improve them involves flow measures. However, applying flow measures for software requires special techniques.
The report takes you beyond the platitudes and provides a solid understanding of the principles and practices of specifying and instrumenting those flow measures that are essential for adapting Lean for DevOps.
