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.