by Gerald Weinberg

Quality Software Management: Anticipating Change
Quality Software Management: Anticipating Change
by Gerald Weinberg

Quality Software Management: Anticipating Change
an excerpt from http://www.se-radio.net/2006/07/episode-24-development-processes-pt-1/
---------------------------------------------------------------------------------------
CMM-I certainly does not expect software to be built as a production line. It does provide practices that help guarantee that the results of hundreds of creative acts can be verified, understood, evaluated and coordinated, so that you and I can feel safe when we drive our car, fly a Boeing 777 or put our credit card in an ATM. So that the person who fires a cruise missile can be sure it won’t explode in their face. And that over time we can built bigger and better products, because the processes we use to do this are now less wasteful than 20 years ago.
CMM-I up to level 3 is mostly concerned with basics like having a process that can be taught. Making sure bad product is separated from good product. And making sure that all and only requirements are implemented. Level 4 and 5 support the feedback loops Mary Poppendieck advocates. Much of this is common sense. But as they say: Common sense is not so common.
----------------------------------------------------------------------------------------
Quality Software Management
----------------------------------------------------------------------------------------
A more prosaic description of organisational maturity is given by Gerald Weinberg in
Quality Software Management: Anticipating Change (Quality Software Management) by Gerald M. Weinberg (Hardcover – May 1997). Here is a summary of his software engineering cultural patterns (pp 437-443).

0. Oblivious culture: The results depend totally on the individual. No records are kept, so there are no measurements. Because the customer is the developer, delivery is always acceptable.
1. Variable culture. The work is generally one on one between the customer and the developer. Quality is measured internally by its function (“It works!”), externally by the working relationship. Emotion, personal relations and mysticism drive everything. There is no consistent design, randomly structured code, and errors removed by haphazard testing. Some of the work is excellent, some is bizarre, and it all depends on the individual.
2. Routine culture. The routine organisation has procedures to coordinate efforts, though its members only go through the motions of following them. Statistics on past performance are used not to change, but to prove that they are doing everything in the only reasonable way. Quality is measured internally by the number of errors (“bugs”). Generally the organisation uses bottom up design and semi structured code, with errors removed by testing and fixing. Routine organisations have many successes, but a few very large failures.
3. Steering culture. They have procedures that are always well understood, but not always well defined in writing, and that are followed even in a crisis. Quality is measured by user (customer) response, but not systematically. Some measuring is done, but everybody debates which measurements are meaningful. Typically, they are top down design, structured code, design and code inspections, and incremental releases. The organisation has consistent success when it commits to undertake something.
4. Anticipating culture. They use sophisticated tools and techniques, including function theoretical design, mathematical verification, and reliable measurement. They have consistent success, even on ambitious projects
5. Congruent culture. Here are all the good things achievable by the other cultures, plus the willingness to spend to reach the next level of quality. Quality is measured by customer satisfaction and by the mean time to customer failure (ten to one hundred years). Customers love the quality and bet their life on it. In some sense [this culture] is like [the Oblivious culture] in being totally responsive to the customer, but it is much better at what it does.

In summary, Maturity is not about predicting what will happen. It is about knowing what and how to manage to get a desired result. And the CMM-I model presents known, working practices in this area.