News
Six Sigma to the rescue?
- By Dan Romanchik
- March 23, 2004
"Six Sigma" is a term often bandied about in software development circles lately, but few developers know what it really means. Originally coined by quality professionals in the manufacturing world, it refers to a methodology developed to reduce the number of defects produced by a manufacturing process. In the manufacturing world, if you've reached the Six Sigma level, your manufacturing process is producing fewer than four defects for every million units that you produce.
That's the literal definition of the term. In practice, the term Six Sigma is used when referring to the methods used by companies such as Motorola and General Electric to reach the Six Sigma level. Because these companies have been successful in improving their manufacturing processes with these techniques, some people in the software world are now trying to apply them to the software development process.
This is a controversial topic, but one person who thinks it is a good idea
is Christine Tayntor, author of the book, Six Sigma Software
Development (Auerbach Publishing, 2002). I recently asked her some questions
about Six Sigma and how to use Six Sigma techniques in software development.
Q: Isn't the term Six Sigma just a buzzword? You don't honestly expect
software development teams to reach the Six Sigma level (3.4 defects per million
lines of code), do you?
A: I wouldn't call Six Sigma a buzzword. I do agree that it's unlikely that a software development team will achieve a true Six Sigma level, but that doesn't diminish the value of Six Sigma and having minimal defects as a goal.
Having a specific, measurable goal increases the probability of meeting that
goal, or at least getting closer to the goal. That's one of the benefits of
Six Sigma. It introduces specificity and measurement as well as a formal process
toward meeting those goals. We in IT need that. After all, it's a lot easier
to say "We're going to improve our quality" than to say "We're going to improve
our quality by reducing defects from x to x-y, and here's how we're going to
do it." The latter approach -- the Six Sigma way -- requires that we know what
our defect level is, that we have a plan for reducing the number of defects,
and that we measure and report our progress toward the goal.
Q: How do Six Sigma techniques differ from traditional software quality
assurance (QA) techniques?
A: In addition to the differences I outline in Chapter 2 [of my book], I think
it's important to realize that Six Sigma has a greater emphasis on process --
how to do things -- than QA or SEI CMM. Both traditional QA and the higher levels
of SEI CMM, notably Levels 4 and 5, stress the need to measure and reduce defects.
Six Sigma, with its strong statistical component, teaches people how to measure
and then how to analyze what they've measured. It's no coincidence that the
DMAIC model has steps called "Measure" and "Analyze."
Q: What's the most difficult part of implementing a Six Sigma software
development process?
A: Change management. Six Sigma is like any new initiative. It involves new
ways of thinking and new ways of doing things. Change doesn't happen -- at least
not successfully -- without careful management. By that I mean planning for
change as if it were a separate project. Establishing responsibility, developing
a formal project plan, training everyone who's involved, communicating . . .
the whole nine yards.
Q: Can Six Sigma techniques be implemented on particular projects even
though the entire application development department may not use them?
A: Yes. You can even use Six Sigma tools and techniques on portions of a project.
For example, if you've already started implementing a piece of packaged software
and are at the stage of developing interfaces from existing systems, you could
use an FMEA [Failure Mode and Effects Analysis] to determine the risks and establish
a plan to mitigate those risks. You could also track errors and analyze their
root causes, using basic Six Sigma statistical tools. The FMEA focuses attention
on potential problems and, in doing so, helps prevent them. Tracking and analyzing
errors is useful for preventing their recurrence in subsequent phases of this
project as well as future projects.
Q: Six Sigma techniques sound good on paper, but can you give me an
example of a company that successfully adopted these techniques? What benefits
did they gain from doing it?
A: Motorola, GE and Honeywell are all famous for having adopted Six Sigma and
having achieved significant results from it. Companies that have implemented
Six Sigma techniques for system development report less rework and higher customer
satisfaction. The reason for these improvements is that the companies have a
greater focus on customers. They listen to their customers, are vigilant in
ensuring that they truly understand customer requirements, and then ensure that
the functionality they develop meets those requirements. In other words, they
make certain that they're working on the right project because they know that
it's not enough to develop defect-free code. That code needs to be solving the
customer's problems.
About the Author
Dan Romanchik is an engineering manager turned writer and Web developer. His current passion is amateur radio. You can read his amateur radio blog at www.blurty.com/~kb6nu.