Lean Management: Value Stream Mapping

Value stream mapping, sometimes called information flow mapping is part of the Lean Management method for evaluating the as is state and an aid to modeling and designing the to be state of a system from beginning to end. It is a visual tool that should display all the critical steps in the process, stressing time taken, especially during handoffs, at each stage. The map illustrates the flow of information and product, in this case, software, as they progress through the process and identifies choke points that to remove. It will also identify areas where rework can more effectively be performed or eliminated, smooth, or reduce gating actions and improve delivery quality to the end consumer.

The purpose of value stream mapping exercise is to identify and remove or reduce waste in value streams, thereby increasing the efficiency of a given value stream. Waste removal should result in increased productivity by creating leaner operations, which in turn makes waste and quality problems easier to identify. A value stream mapping exercise includes the stakeholders relevant to the value stream under review. This includes business specialists, technical specialists, and other program participants. It may also include individuals with knowledge of feeder processes or ancillary value streams.

This series discusses Value Stream Mapping by looking at the theory of constraints and its impact on value streams, the impact of Conway’s Law on development and value streams, and the process of conducting value stream mapping exercise, understanding the outcomes and their effect on workstream, obstacles, and execution.

Theory of Constraints

The theory of constraints comes out of concepts introduced in the 1980s in a book called The Goal, as well as ideas around power-oriented management theory from the late 1960s. Eliyahu Goldratt is credited with coining the paradigm, however. At its heart, the premise-based around the notion that organizations can be measured and controlled by variations of three metrics: throughput, operational expense, and inventory. In manufacturing, inventory is related to the monies invested in purchasing all the things that the company intends to sell. Operational expense is all the money the system spends to turn inventory into throughput. In the software world, this is development time and labor. Throughput is the rate at which the system generates money through sales. In software, this is harder to quantify, but delays in throughput have an eventual monetary impact. Whether making money is a goal or a necessary condition, it is critical to understand the financial decisions based on throughput, inventory, and operating expenses.

The theory of constraints, then, is based on the premise that the rate of goal achievement is limited by at least one if not more of the three constraints. Ironically, if nothing is preventing a system from achieving higher throughput, that throughput would be infinite, which, of course, is impossible. The system’s goal must be clearly articulated, and measurements defined before the constraint can be addressed. Then you can begin to:

• Identify the constraint(s)
• Decide how to exploit the system’s constraint(s).
• Subordinate everything else to the above decision(s).
• Alleviate the system’s constraint(s).
• However, if in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint.

The five focusing steps aim to ensure ongoing improvement efforts are centered on the organization’s constraint(s). This is the process of ongoing improvement (POOGI).

A constraint is anything that prevents the system from achieving its goal. Within the theory of constraints model, the idea is not that there are tens or hundreds of constraints, but only one, or at most a few in any system. Constraints are either internal or external to the system.

The material in this series looks at the theory of constraints through the lens of DevSecOps.

Conway’s Law

Named after Melvin Conway in 1967, Conway’s law states:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

The reasoning behind it is that for a software module to function, multiple authors must frequently communicate with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more complicated. Conway’s law was intended as a valid sociological observation, although sometimes it’s used in a humorous context. It was dubbed Conway’s law by participants at the 1968 National Symposium on Modular Programming.

Eric S. Raymond tightened it up by saying: If you have four groups working on a compiler, you’ll get a 4-pass compiler.

The selections below highlight Conway’s Law and some of the ways to avoid falling into the trap it presents.

Value Stream Mapping

Value-stream mapping has supporting methods that are often used in Lean environments to analyze, and design flows at the system level (across multiple processes). Although value-stream mapping is often associated with manufacturing, it is also used in logistics, supply chain, service-related industries, healthcare, software development, product development, and administrative and office processes.

As part of the original model, seven accepted types of waste have been defined (and these are primarily around manufacturing, but can be applied to software development as well):

• Faster-than-necessary pace: creating too much of a good or service that damages production flow, quality, and productivity. Previously referred to as overproduction, and leads to storage and lead time waste.
• Waiting: any time goods are not being transported or actively worked.
• Conveyance: the process by which products are moved around. Previously referred to as transport, and includes double-handling and excessive movement.
• Processing: an overly complicated solution for a simple procedure. Previously referred to as inappropriate processing, and contains unsafe production. This typically leads to poor layout and communication and unnecessary motion.
• Excess Stock: an overabundance of inventory, which results in more significant lead times, increased difficulty identifying problems, and high storage costs. Previously referred to as unnecessary inventory.
• Unnecessary motion: ergonomic waste that requires employees to use excess energy such as picking up objects, bending, or stretching. Previously referred to as unnecessary movements, and usually avoidable.
• Correction of mistakes: any cost associated with defects or the resources required to correct them.

These can be reduced to three:

• Non-value adding operations (NVA): actions that should be eliminated, such as waiting.
• Necessary but non-value adding (NNVA): activities that are wasteful but necessary under current operating procedures.
• Value-adding (VA): conversion or processing of raw materials via manual labor.

The value stream mapping process usually results in two outputs. The current state map, which is used to determine what the process looks like, and identify the bottleneck. The future state map focuses on what the process will look like after process improvements are introduced into the value stream.

The material in this section looks at the value stream purpose, as well as how to create and use the value stream mapping process to improve the existing process.

Value Stream Mapping Hands On Example

Whether you are doing it manually, or using a software tool, the process of developing a value stream map is a skill that has to be learned. This series of videos walks you through a VSM exercise if you have not had the opportunity to participate in one before.

Additional Reading and Presentations

Value Stream Mapping Book