Page 240 - Lean six sigma demystified

218 Lean Six Sigma DemystifieD

4. Measured. Departments start to measure the software process—cycle time
and defects. This is the M in DMAIC.
5. Optimized. Groups start doing root cause analysis and making improve-
ments in the software process. Then they begin to use the measurements
to stabilize and control the delivery process. This is the AIC—Analyze,
Improve, and Control—in DMAIC.
Unfortunately, this waterfall model of software process improvement forces
groups to define and measure their process before they start making improve-
ments. Without improvement, defining and measuring seems like non-value-
added work that takes away from the delivery of software. Software developers
resist this bureaucracy with a passion. I believe the trick is to throw them right
into problem solving and improvement, producing processes and metrics as a
by-product of improvement, instead of as a prerequisite.
All software projects follow some sort of process no matter how unstruc-
tured. They all have some sort of metrics even if it’s just trouble reports, change
requests, and daily fallout or error counts. These are more than sufficient to
start making improvements in your core application systems. So the question
is how do we hook software developers and maintainers on process, measure-
ment, and improvement? After working with various IT groups, I’ve found that
nothing works as well as the exhilaration they feel when they use the root cause
tools of Six Sigma to make an improvement, weave it into the existing process,
and experience the benefits of their improvement.
From working with teams in various IT departments, I’ve developed a sim-
ple method for achieving breakthrough improvement and getting IT hooked
on Six Sigma. I call it the Dirty 30 Process for Six Sigma Software. In 2000, I
used this simple technique with one wireless telephone company to reduce

service order errors and save $250,000 per month in error correction after
just 4 months.

The Dirty 30 Process for Six Sigma Software

Although most software quality efforts focus on the development of software—
requirements, design, code, and test—this method focuses on the fine tuning
of delivered software. Yes, it would be better to prevent the kind of problems
we see in software, but applications continue to be written by people using
requirements and designs that can be flawed. Software is rarely released; it
escapes.