By David L. Hallowell
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.
| Figure 1: Cost of Escaped Defects Motivated Six Sigma |
|  |
|
|
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.| Table 1: Six Sigma Created a Shift to Weakness-Based Improvement |
| | Strength | Six Sigma shift toward Weakness (DMAIC roots) |
Example | Increasing yields (percent good units)
Increasing percent satisfied customers | Reducing defects within units
Reducing complaints |
Focus on | Ideas, the future, finding new solutions | Facts, data, past and present, finding root causes |
Sources of Data | Expert opinion | Current process and history |
Use of Metrics | Performance metrics
Less detail: good units or transactions
Rollups that summarize performance | Diagnostic metrics
More detail: defects within units
Details support root cause analysis |
Impact on Reporting | "Good news" is king
(tends to filter details, facors the best spin) | Surfaces the real issues
(focuses improvement work) |
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 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 Design for Six Sigma. 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.
| Table 2: Lean and Agile Thinking Learn from the Follies of Mass Production |
| Mass Production | Waste | Lean Thinking | Agile Software Thinking |
Build inventory
| Rework of disposal of outdated inventory | Build to order | Invest design and code work only on clear customer requirements (pull) |
| " | Transportation | Minimize wasted movement and handling | Minimize wasted "knowledge recovery time" switching in and out of different tasks |
| " | Storage | Minimize inventory and storage | Minimize work in process (and configuration and revision control overhead) |
| Start large batches of identical goods (push) | Overproduction | Right-size batches, matching the readiness of the next activity (pull) | Avoid "big bang" delivery...break work into smaller units that build incremental value |
| " | Queing/waiting | | Smaller iterations – avoid coders waiting for design, or worse, moving ahead of design |
| " | Defects and rework costs hidden by sales of the good units | Measure and reduce rework time | Measure and reduce rework and defect repair time |
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.
| Figure 2: Six Sigma and Lean – Natural Partners |
|  |
|
|
About the Author: David L. Hallowell, a founding partner of Six Sigma Advantage, Inc., has more than 20 years experience as an engineer, manager and Master Black Belt. As Digital's representative to Motorola's Six Sigma Research Institute, he worked on the original courseware for Black Belts and the application of Six Sigma to software. He has supported Six Sigma deployments worldwide. With a special focus on Design for Six Sigma, he has led development teams in the concept development and design of a number of commercial products. Mr. Hallowell has patents and publications in the area of microelectronics packaging and high speed interconnect. He has authored courses in software DFSS, design of experiments, C++ and computational intelligence tools. Mr. Hallowell can be reached at dhallowell@6siga.com.
