Columns

Guest Column: Six Sigma's not for everyone

• By Dan Romanchik
• June 1, 2004

In my opinion, Six Sigma is a very poor term to use for a software development process. Six Sigma is a term first used for manufacturing process improvement methodologies and, in that context, it refers to the variability of a process. Say, for example, that you have a manufacturing process that produces steel rods 1m long. Because your process is not perfect, the lengths of some steel rods will be 0.998m, some 0.999m long, others 1.001m long and so on. As far as your customer is concerned, this is OK as long as the length of each steel rod is between 0.997m and 1.003m. If your process is a Six Sigma process, it will produce only 3.4 bad rods -- rods shorter than 0.997m or longer than 1.003m -- for every million rods made.

Now I ask you, how do you translate this concept to software development? One thing you might do is to say that the goal of a Six Sigma software development process is to produce software with fewer than 3.4 defects per million lines of code. But the first problem with this definition is that lines of code are not steel rods. Steel rods have specific properties, and customers want those properties to be the same for every unit. Computer programs, on the other hand, are all different, and each line of code that makes up those programs is different. So what is the measurable quantity in a line of code?

You might dismiss this rant-ing as 'just semantics,' but I think it's important to use terms that are readily understandable by everyone involved. One of the most important parts of implementing a process is making sure that all those involved understand what it is you're asking them to do. If you use a name that can be misleading, you're making a mistake right from the start.

What Six Sigma brings to the table
Having said all that, do Six Sigma proponents bring anything to the table? Yes, they do. What they bring is a way to think about the software development process as well as a framework for improving it.

The most recognizable part of this framework is what Six Sigma proponents call the 'Six Sigma Toolkit.' Others refer to it as the five phases of Six Sigma. Quite often, all you will see is the acronym DMAIC, which stands for the following:

• Define -- In the first phase of a Six Sigma project you define the problems with your current process and identify why they are important. 
• Measure -- Next, you make measurements to quantify the problem. 
• Analyze -- In the analysis phase, you determine the root cause of the problem and begin to propose solutions. 
• Improve -- In this step, you prioritize solutions, concentrating on those that will have the biggest payback. 
• Control -- Finally, you measure the improvements and put in place a system that will ensure that you continue to benefit from your process improvements.

If you are manufacturing steel rods, defining the problem is almost a no-brainer. Your quality assurance department (or your customers) will define the problem for you -- the steel rods are either too long or too short.

The measurement phase is also a snap. You get out a ruler, measure the length of the rods and chart the data. Doing this will tell you exactly how good (or bad) your manufacturing process is.

Unfortunately, it's not that easy to define and measure the parameters of a software development process. Steel rods are defective when they're too short or too long, but a software defect is not as easy to define.

Things become murkier when you head into the analysis phase. Due to the mechanistic nature of the steel rod manufacturing process, it is relatively easy to determine the root cause of a manufacturing problem. The die used to cut the rods may be worn or a sensor used to position stock in the cutting machine may be acting erratically.

But how do you determine the root cause of a software defect? My guess is that you will have to do an awful lot of research to determine the root cause of even a single defect. Was it an ambiguous customer request, an incomplete functional specification or simply a poor programmer that was the reason for the defect? To successfully complete your analysis, you will have to do this for hundreds of different defects.

This is certainly not to say that examining your process in this way is totally without merit. No process is perfect, and Six Sigma tools can provide a framework to help you do this. Just keep in mind, however, that the toolkit was developed for improving manufacturing processes and that using it to improve your software development processes will be a lot of work.

If your company is using Six Sigma techniques in manufacturing, adapting it to software development may be a natural progression. Executives will have some familiarity with Six Sigma concepts, and if you do a lot of training in-house, your training department will also be ready to support you. If, however, Six Sigma is something totally new, you may want to take a very hard look at the costs involved before implementing a Six Sigma program.