It was a restaurant my wife and I had passed many times, and we had always told each other, "We must try them some day." When we finally tried them, we were pleasantly surprised. The food, the service, the atmosphere, even the price were great! "This will be a regular stop for us," we agreed. But on our third visit, we had to send our food back twice. Another time, we waited nearly an hour for our order. Then, some time later, we were seated at a table that was not clean. Most of the time, things were great. But as we experienced sporadic problems, we visited that place less and less often.
Why is it that a business can do so well some of the time and mess up so badly at other times? What causes this inconsistency? If we could have taken a peek behind the scenes at that unnamed restaurant, what would we have found?
Inconsistency in quality of food, service, products, software (of anything) is almost always caused by inconsistency in the way those things are done. Poorly prepared food in a restaurant is often the result of a cook who in unfamiliar with the procedures for making certain dishes. A dirty table will result from the bus-person taking shortcuts.
In the same way, quality problems in software have their genesis in some sort of inconsistency. For example:
· When good project planning processes are skipped, developers are often required to do too much work too quickly, and end up making mistakes along the way.
· When project-staffing processes are not adhered to, inexperienced programmers can be pressed to do jobs that require skills or knowledge they lack, resulting in errors of judgment.
· When software design methods are used inconsistently, systems are sometimes poorly engineered.
· When developers are inconsistent in their coding practices, many defects can be injected.
· When configuration management procedures are not followed, good technical work may be lost, and must be replaced in a hurry.
Because the quality of our software is so closely tied to the consistency with which our processes are followed, it stands to reason that this should be among the first places that we look when trying to solve our quality problems. Unfortunately, that is easier said than done.
Suppose that your organization has a problem with interfaces among components not working correctly. During integration and system testing, you end up spending inordinate amounts of time diagnosing and fixing these interface defects. So, where do you look to find the offending process? Which of your processes should you suspect? It may be the way you do the architectural design for the system. Possibly, the component designers struggle with translating the system architecture into workable designs. It could also be a coding issue. On the other hand, it may also be that the architecture reviews (or design reviews or code reviews) are not effective. Then again, maybe it is a matter of training the staff to be competent with the technologies and techniques they are using. Perhaps the problem lies in the ways that project-staffing decisions are made. The list goes on and on.
This sort of a reactive approach to our processes is terribly inefficient, so we want to avoid taking this sort of reactive approach to quality problems. It is an inefficient approach for two reasons. First, you wait to take any action until there is problem, which means you have incurred the waste and rework inherent in defective systems. Second, as we observed above, diagnosing the actual root cause of the problem is not an easy task. It will require significant investigation to get to the root of the matter. All of this effort is being expended before you have taken the first step toward actually fixing the problem!
The alternative to a reactive approach is a proactive approach. That is, understand and monitor the effectiveness of your processes so you can avoid process-related problems. Make sure that your processes are working well and used consistently, and you can avoid much waste and rework. This proactive approach is not a new concept. It has been the foundation of quality programs for decades, ever since the 1930's and 40's, when Dr. W. Edwards Deming began teaching us how to control quality. In the past two decades, we have begun learning to apply it to software. Consider the following:
· When the Capability Maturity Model® (CMM) and CMMI use the term "quality assurance" (QA), they do not mean testing. Testing is encompassed in other process areas. QA refers to the activities of assuring that the organization's processes are serving their purpose and are being followed consistently.
· Extreme programming (XP) is one of the Agile software development methods that defines the role of the coach. This person is responsible for assuring that each team member knows how to follow the XP methods and does so consistently.
· Scrum (another of the Agile methods) includes a Scrum master, whose primary role is to keep watch over the way the team uses the Scrum process, and assure that it is being used to its greatest advantage.
Both the traditional plan-based CMMI and the new Agile methods agree on the following: consistency in the way processes are used is so important that a proactive approach is necessary to ensure consistency.
So, what does that mean for us? It points out a set of activities that we should be engaging in to assure the quality of the software we produce. It shows us that if we make an investment in ensuring that we are using appropriate processes, and if we monitor how those processes are used to make them consistent, then our investment is likely to be returned to us in the form of 1) better quality in the software that those processes produce; 2) significantly reduced waste and rework (which will help our budget and schedule performance); and 3) less time wasted trying to diagnose the root causes of problems. Proper attention to keeping our processes effective and consistent will not cost us time and money. To the contrary, in the long run, it will save us much more than we invest!
If that restaurant my wife and I used to frequent had paid attention to its processes, they would have discovered and corrected the inconsistencies in their performance long before they lost us as customers. Indeed, we (and likely others) would have left a lot more of our money in their till, and maybe, just maybe, they might still be in business today.
® "Capability Maturity Model," "CMM," "Capability Maturity Model Integration," and "CMMI," are registered with the US Patent and Trademark office by Carnegie Mellon University.
