For the past 5 years GE has been following and enhancing the Six Sigma quality model. During this same period Extreme Programming has emerged as an alternative to the traditional software development process. In the past year the authors have been following a process which merges elements from each of these disciplines. This paper gives the background and describes their current approach.
Six Sigma Basics
Behavior is a function of values. We measure what we value. Therefore it follows that to change behavior we have to change what we measure. This simple truth is the core of the Six Sigma quality program at GE We must adapt our measurement systems to look at true life cycle costs and reward behavior that improves on these costs. Basic Six Sigma focuses on improving existing processes and understanding the key control factors for these processes. Within GE this has been stretched far beyond manufacturing to include processes throughout the company including sales, services, and engineering. In this basic approach GE has followed the Mikel Harry’s Six Sigma Breakthrough Cookbook [Harry 94]. This approach breaks down any quality problem into four steps: Measure, Analyze, Improve, and Control. In the measure phase the practitioner characterizes the process in terms of Critical To Quality, CTQ, characteristics. These are the elements that the customer considers as the key factors for process success. Specific, measurable targets are established for these CTQs both for mean performance and statistical variation. In the analyze phase the CTQs are broken down to understand the factors that influence their performance. These are divided into two group, key control parameters and noise parameters. In the improve phase measures of the key control parameters are further collected and studied to learn how their performance can be tuned to optimize the effected CTQ’s performance. In the final phase, control, a method is developed to ensure that the CTQ performance will remain at its improved value. This reliance on gathering data from actual measures is another of the fundamental aspects of the Six Sigma approach. Instead of relying on intuition to guide changes Six Sigma demands that data be used to make decisions.
Extreme Programming, XP, is a emerging approach to software development that focuses attention on the granularity of work elements from concept to implementation, the testing of the work products, the reduction of ‘overhead’ activities and the involvement of the customer in the development process. XP is successful because it emphasizes customer satisfaction and promotes teamwork. The most surprising aspect of XP is its simple rules and practices. They seem awkward and perhaps even naive at first, but soon become a welcome change to developers who adopt the XP model. Many customers enjoy being partners in the software process and developers actively contribute regardless of experience level. The rules and practices must support each other. Together they work to form a development methodology. Unproductive activities have been trimmed to reduce costs and frustration. This approach to refining the development process is in keeping with the Six Sigma tenet of behavior being driven be values and measurements. In general people value their time and as such are unwilling to spend time on ‘unproductive’ activities. Thus all activities that are elements of XP need to be transparently productive or they will soon fall into disuse. XP, as defined by Kent Beck[Beck 2000], has a number of elements.
Six Sigma Applied to Software Development
Green Belt Projects
At GE every person in the company was challenged to understand and apply Six Sigma methods to their job. To back up this challenge every GE employee has been trained in Six Sigma tools and practices. Every professional within the company is expected to demonstrate use of the tools to perform their job. The demonstration takes the form of green belt projects. For people just undergoing training these are generally small projects that look to make demonstrable improvements to quality in some aspect of their work and to demonstrate proficiency with elements of the Six Sigma approach. The projects are selected by the trainee and mentored by a more experienced Six Sigma leader. In software groups the training projects have generally focused on some measurable aspect of the coding or testing process. Topics such as regression test coverage, memory usage, and code style are all projects that have been done for training. The general experience with these projects has been that they do a reasonable job of defining CTQ’s, e.g. all files shall have a mean of 80% of their lines of code exercised by regression tests with a standard deviation of no more than 5%. The analysis and improve phases uniformly yield an improvement in CTQ performance, generally as the result of personal effort on the part of the trainee, e.g. they implemented a sufficient number of tests to drive the coverage up. The control phase is then where problems arise. In this phase, the trainee reports on a plan to monitor CTQ performance on a periodic basis. Having gotten their training completed the trainees then go back to working exactly as they have in the past. The problem is in the control step. The quality gain, once achieved, was a lone effort and remains that way in the control stage. Thus the rest of the team ends up with little concern for the gain and eventually it is forgotten.
Changing the Way We Work
As the same a group of workers that has gone through or is going through green belt training began to adopt elements of extreme programming an interesting phenomenon occurred. The group has a five year history of developing an open source package so they had been early adopters of elements of the approach. The idea of collective code ownership, refactoring, simple design, and coding standards were all part of the group ethic to a greater or lesser degree. One of the new elements of extreme programming that the group decided to experiment with as it was embarking on Six Sigma was a modified form of pair programming. This has made all the difference in the impact made by Six Sigma.
In the local version of pair programming the concept is extended to be paired, or trippled, work. Not only is time programming spent together but other work time is also spent together. This includes time spent on green belt projects. The time being jointly directed as in pair programming. This means that each member of the work group ends up having to buy into the value of the green belt project before it begins. Given this expanded ownership of note just the code output but also of the quality outputs the control phase got a renewed emphasis. With additional owners comes additional pressure to achieve a suitable performance on the CTQ. After the first round of projects the CTQ performance had risen noticeably and any backsliding was more rapidly noticed. The group then moved to the next element of extreme programming, continuous integration. Measuring the quality results entailed running a test of sorts for each aspect of quality that was being checked. Running these tests by hand became cumbersome so the group developed a nightly test harness that runs each of the quality tests and collects all of the data to present a single comprehensive view of measured quality. It was a small move from this point to start a continuous test process that runs a slimmed down set of the quality tests whenever code is checked into the source code repository.
The continuous measure of quality then is the final blending of extreme programming with Six Sigma. Behavior and measurement are well aligned. System performance against external, customer defined CTQs, expressed through regression tests, and internal, team defined CTQs, expressed through quality tests are available on a continuous basis. The teams are not able to move forward unless the results of their work is a clean dashboard as measured by both continuous and nightly dashboards. Extreme Six Sigma has become the way we work.
Timothy P. Kelliher is a Computer Scientist at GE's Corporate Research and Development Center in Schenectady, NY. He has over 15 years experience in systems and software engineering. At the center he has worked on Software Engineering CASE tools, Human Computer Interaction, and Software Quality systems. He is a Six Sigma Master Black Belt and spends much of his time instructing and mentoring the GE software development community. He is co-author of “Engineering Complex Systems with Models and Objects” published by McGraw-Hill, 1997.
Daniel Blezek is a Computer Scientist in the Visualization and Computer Vision Program at GE's Corporate Research and Development center. He holds a Ph.D. from the Mayo Graduate School in Biomedical Engineering. His research interests include medical image segmentation, advanced rendering algorithms, and practical software quality techniques.
William Lorensen is a Graphics Engineer at GE's Corporate Research and Development Center in Schenectady, NY. He has over 30 years of experience in computer graphics and software engineering. William is currently working on algorithms for 3D medical graphics and scientific visualization. William is the author or co-author of over 60 technical articles on topics ranging from finite element pre and postprocessing, 3D medical imaging, computer animation and object-oriented design. He is a co-author of "Object-Oriented Modeling and Design" published by Prentice Hall, 1991. He is also co-author with Will Schroeder and Ken Martin of the book "The Visualization Toolkit: An Object-Oriented Approach to 3D Graphics" published by Prentice Hall in November 1997. Mr. Lorensen holds twenty seven US Patents on medical and visualization algorithms.
James Miller is a Computer Scientist at GE's Corporate Research and Development Center in Schenectady, NY. He joined GE after receiving his PhD from Rensselaer Polytechnic Institute in 1997. His thesis topic was in Computer Vision. At GE James has become a primary contributor to vtk software algorithm development and testing. For the past year, he has been the project leader on a research project for Lockheed Martin involving the inspection of large airframes using laser ultrasonic techniques.