Some common messages are beginning to emerge from several software-relevant areas – Six Sigma for software, Agile development and Lean thinking. The links between Design for Six Sigma (DFSS) and Agile have been explored recently, but now a broader view yet can illustrate the way that Lean thinking, evolved from just-in-time manufacturing, aligns well with both Agile and software Six Sigma.

A bit of Six Sigma and Lean history can help to frame their convergence with Agile thinking.

Six Sigma Origins: Follow the Defects

In the 1980s Motorola and many U.S. companies were under heavy competition from Japanese industry. In terms of the classic bathtub curve (Figure 1), product reliability was good – but infant mortality, caused by defects escaping production, was costing enough to dangerously erode profit margins. The whole curve can translate well to software. Software professionals are, of course, well aware of released defect costs. While the old-age defects in hardware are due to wear and tear, legacy software systems suffer end-of-life upswings in defects because the world around them changes so much over time.

In the period before Six Sigma, many manufacturing companies focused on yield (good units / units started) as a key quality measure. Motorola realized that this motivated hidden rework and that it did not provide good diagnostics on where the real problems and sources of defects were. Yield dropping from 98 to 80 percent indicates a problem, but does not do much to show where or how to look for the fix. As simple as it may sound, the Six Sigma shift of focus from good units to defects within units was a major change, with a number of rippling effects. Table 1 outlines some impacts of a move from “strength” measures, like yield, to “weakness” measures, like defects.

In problem-solving, this shift to defects and detail provided project teams with strong diagnostics about the real dynamics of a problem and its root causes. A DMAIC (Define, Measure, Analyze, Improve, Control) team could follow the defects, peeling the onion to find the detail they needed to isolate and remove the drivers of the problem.

While defects were key, early Six Sigma also paid attention to cycle-time improvement. A common deployment banner called for a 10-time reduction in defects each year for several years and 10-time improvement in cycle time. That early link with Lean has matured, as will be illustrated.

Interestingly, software did not need to unlearn yield or any other bias toward strength measures. Software defects or bugs have long been understood to be the signal to follow for detail on causes and fixes. In that regard, DMAIC has been a natural ally in software process improvement work from the beginning.

Lean Origins: Follow the Waste

The body of work now summarized as Lean traces its roots to a number of sources – key among them, Taiichi Ohno, an architect of Toyota’s Lean production system, and Eliyahu Goldratt, founder of the theory of constraints.

In the 1900s, U.S. manufacturing attained economic might by relying on large batches and large volumes of identical components and assemblies. Smaller competitors, like Toyota in the 1950s, realized they could not compete in the same way. Their markets called for smaller batches of products with more tailoring for different customer needs. Recognizing that the U.S. form of mass production hid a lot of waste in its large volumes (starting work on many units in order to yield enough good units to sustain sales), Ohno and others sought to go after that waste as a competitive weapon. Table 2 outlines the way that Lean thinking contrasts with mass production – and aligns with Agile software thinking.

There is a message that resonates well with software DFSS. Software design is not about mass-producing big batches of identical components. Rather, it is about creating and acting appropriately on knowledge of what is uniquely important to customer and company value in each project. That game is not won by becoming a widget factory – it is won by learning to play the game well, and going after the waste as a competitive weapon. At that juncture, software DFSS, Lean and Agile seem to intersect – each bringing insight to the other.

Mass producers saw the stockpiling of good units for later sales as a reasonable strategy to keep their high volume capacity in use. Lean practitioners saw this as waste – in space and handling, with the added risk of obsolescence. Software has painfully learned the risks in this big bang delivery, where a large inventory too often must be thrown away or reworked because it misses the mark. Lean parallels the Agile principle of building small iterations, each of which have small risk of being wrong. Done well in a software environment, early iterations provide knowledge discovery and risk reduction, thus increasing the net value of future iterations. It is a forward-looking learning cycle.

Power of Six Sigma and Lean in Concert

With unique orgins, Six Sigma and Lean intersect on some common ground (Figure 2). Six Sigma uses defects as a focal point for driving out the costs of rework during production and of replacement or repair after delivery. Its focus on customers, business results and statistical thinking provides a base for all kinds of fact-based learning. Lean brings special attention and tools to uncover and reduce waste – including, but not limited to, defects. This is especially helpful in software, where the defects are not always visible as pointers to the real problems. Often, time and wasted effort show the way to the waste and root causes of problems. Having a handle on each way to improvement – defects and/or time and wasted effort – rounds out the weaponry that software professionals would like to have at hand.