Six Sigma Meets Software Development Is off Track

I'm sorry, but I just read the article "Six Sigma Meets Software Development" and I think it's really off track. Six Sigma works beautifully with software development just as it is. I've been using it for two years in our software development consulting projects (as well as other non-software projects) with incredible results; and we do it straight from the book as taught by Juran's Six Sigma class. Since I started on this all I've met is opposition from others saying you can't apply it to software; you can--but you need to understand Six Sigma as Harry and Shroeder defined it and meant it to be used and you need to have a clear understanding of the software development process.

I applied all the DMAIC (BTW, DFSS is no good, in my opinion, unless the team has already been doing SixSigma successfully; then it's wonderful) steps to our problems and have made substantial improvements in the productivity and quality of the companies we work with. And we used the Six Sigma tools right out of the box. E.g., COPQ, FDM, FMEA, Brainstorming, ANOVA, DOE, and, of course, measure, measure, measure the process. I think most people's mistake is that they confuse measuring the results with measuring the process and they think that once they've measured the results they are done with the Measure step. Measure the the software process and you will find a great match for Six Sigma and software development. If you only measure the results (e.g., bug counts, schedule delays, costs, etc.) you aren't doing Six Sigma. For example, has anyone measured the process of a Fagan review? How much time does it take, how effective is it in finding bugs, what methods are more effective, etc.? I think you'll be surprised at the results; I certainly was (sorry, I can't share my results due to confidentially requirements from my customers).