Sidebar: Watts Humphrey on Software Quality

Computerworld - Watts S. Humphrey is a fellow and a research scientist in the Software Process Program of the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. He wrote the first version of the SEI's Capability Maturity Model (CMM) for software in 1987.
In 1991, he served on the Board of Examiners for the Malcolm Baldrige National Quality Award. From 1959 to 1986, he was director of programming quality and process at IBM, where he oversaw the development of OS/360. He recently told Computerworld why he developed the Personal Software Process (PSP) and the Team Software Process (TSP).

Is CMM the only quality tool software developers need? The CMM framework is essentially aimed at how do you establish a good management environment for doing engineering work. It's about the planning you need, the configuration management, the practices, the policies -- all that stuff. It doesn't talk about how you do things.
When I looked at organizations that were at high [CMM] levels, I discovered that the engineering practices hadn't changed that much. I had naively assumed that when we put good practices in place, like planning and measurement and quality management, that it would seep down to the engineers [programmers], and they'd start to use it in their personal work. It didn't happen.
What was missing? The PSP and TSP were developed to show individual developers and their teams how to apply these [CMM] principles in your personal work. So we've moved from the what to the how. PSP and TSP aren't tightly bound to CMM, but they are built on identical principles, and they work very well together.
Many people are using PSP and TSP and not using CMM. They use PSP and TSP and then go back and look at CMM and say, "Oh my goodness, the move to CMM is really pretty straightforward now because we sort of understand this."
How should one get started with PSP and TSP? Instead of going broadside with PSP and TSP, you can focus on a particular area -- a couple of projects, one department, a fairly small group -- and you essentially bring a laser focus on that effort and show them exactly how to do it. In effect, you are taking a little slice of the organization all the way to Level 5. You end up with a small group that really understands how it works. You get enthusiasm, and that helps galvanize the organization. Then the movement up the CMM is tremendously accelerated. One company went from Level 1 to Level 4 in 1.5 years. Normally that would take about six years.
What sort of improvements can you expect with PSP and TSP? You get productivity improvements of 70% to 80%. And in shipped code, we are getting things like 100-to-1 quality improvements.
The SEI's new Capability Maturity Model Integration (CMMI) product suite has subsumed the old CMM for Software (SW-CMM). Why did SEI come out with CMMI? CMMI focuses more completely on the business needs, and it integrates better with the overall organization.
At least one major company plans to first move up the old SW-CMM ladder then move to CMMI at Level 5. Is that a good idea? I wouldn't recommend that. Moving up the maturity levels takes a long time, and there's a substantial investment. Doing SW-CMM and then moving to CMMI adds cost unnecessarily.
What advice would you offer the IT manager just embarking on one of the CMM programs? The first thing I'd strongly recommend is, don't get hypnotized by a number. The maturity levels are purely for guidance, and they are useful; but if you are focusing on getting to Level 3 or Level 4, you are making a mistake. The focus should be on improving the process in an orderly way.
Second lesson, very important -- get senior management backing. Without that, this won't work.
Third, make line management responsible. Make bonuses, etc., applicable to line managers as well, not just the CIO.
But most of the heavy lifting falls to the IT people, doesn't it? The immediate actions required are mostly management. We'll go through an early [CMM] assessment, and we have all these software people in the room. Management comes into the final briefing expecting the software people to be told what they have to go and fix, and what management is surprised to discover is about 80% of the recommendations are things that management has got to do, and not the software people at all.