Continual Improvement

Continual improvement is a "commitment to quality" -- in the United States we often have a throw away product development ethic which leads to products which are none too good at the beginning and go downhill from there. The Japanese call the commitment to continual improvement "kaizen" and it involves an ongoing effort to do everything better.

I like to say -- "I may not be good, but I'm getting better." G.K. Chesterton said that "Anything worth doing, is worth doing badly." and that is very true ... we have to do things badly before we can get really good. Fred Brooks said -- build two because you're going to have to throw one away -- don't ship the throw-away to the customer -- they won't appreciate it and may never do business with you again. A commitment to quality means a ever vigilant commitment to doing things better -- Kaizen! --RaySchneider

Gesundheit! Continual improvement of the self, of the process, and IMO of the product itself. The iterative process lets us get the product done by making it better and better, making it do more and more. --RonJeffries

Kaizen also has two other connotations, which are subtler. The first is SmallSteps. For improvement to be continuous it must proceed in SmallSteps rather than in GiantLeaps. The second is repetition. By repeatedly taking small improving steps the process can improve much further than it would with one big leap. These ideas can be applied to many things including software, and life --AsimJalis

I recently came across a description in one of RobertGrady? s books of a group who was charged with maintaining a large, old, legacy system. The measured the complexity of the modules they were maintaining, and made a conscious effort to reduce the complexity with each change. Thus unlike most systems which become brittle with maintenance, theirs gradually became easier to fix. This story is attributed to NathanLowel? in "Software Quality World", vol. 2, no. 2, (1990), pp. 1,5-7. I spent over 6 years maintaining a legacy system myself. Had I been a little wiser, I could have used this technique myself. -- KentSchnaith

Building two because you expect to throw one away anyway is sometimes called "prototyping." It's usually the opposite of ContinualImprovement. It has its dangers, best described by BertrandMeyer in (I think) ObjectSuccess?. If you know the thing you're working on isn't going to be used, why bother doing a good job of it? The difference between a prototype and the real thing is often what makes the real thing difficult, so the prototype may teach you nothing. -- DaveHarris

Actually there is no correlation between continual improvement and small steps. Additionally, there is no relationship between the size of the step taken and the magnitude of the result realized. Small steps can result in large improvements, but they can also result in small improvements.

To effectively do continual improvement, one needs to look at the system as a whole, determine where improvements would be beneficial, and what improvements are feasible. It is a subjective effort to decide what improvement to tackle first, but the key is to continue after addressing the first improvement. No improvements should be rejected out of had because they are too large.

The problem with relegating continual improvement to small steps is that it removes the responsibility from those who can authorize big steps. Big steps often require changes in work processes or cash and this requires those who can authorize these things to be involved as well. If that is not the case, then after a few high return, low effort steps are taken, one is left with low return steps. At this point, continual improvement ceases to be improvement and becomes rearranging deck chairs on the Titanic; a waste of everyone's time and effort.

See WikiPagesAboutContinualImprovement