What is Total Quality Management (TQM)? TQM is a quality management philosophy that was created after the end of World War II by Dr. W. Edwards Deming. It resulted in major improvements in product quality particularly in the Japanese Automobile industry.
Is TQM Still Valid Today?
Although TQM was created a long time ago and many people may have forgotten about it, the fundamental ideas behind it are still very sound and it has a major influence on quality management today. In particular, TQM and Lean Manufacturing have had a major influence on Agile:
- Lean and, in particular, the philosophy of “just-in-time” manufacturing has had a major influence on the Agile development process
- TQM has had a major influence on how quality management is done in an Agile development process
Why Does TQM Make So Much Sense?
To understand TQM, you really need to understand the primary quality management approach that came before it. Prior to TQM, the primary approach to quality management was based on a “quality control (QC)” philosophy. QC is a reactive approach to try to find and fix defects in products before they ship to customers. The problems with that approach are numerous:
- It’s expensive to hire a lot of QC inspectors to try and find defects.
- Any inspection approach is normally based on sampling to reduce costs. Rather than doing 100% inspection of all products; only a sample of products are chosen for inspection. That obviously allows some number of defects to slip through without inspection which will likely result in some amount of customer dissatisfaction
- There is also a potentially high cost of reworking or scrapping some number of products that fail to pass inspection
Wouldn’t it make a lot more sense to take a more proactive approach to go upstream in the process and eliminate defects at the source? That is exactly what TQM advocates. Of course, there is always some need for final inspection, but it can be significantly reduced if the process that produces the products is inherently much more dependable and reliable.
How Does TQM Work?
TQM focuses on developing processes that are inherently reliable and consistently produce products that are as free of defects as possible. To do that, you have to consider everything that might impact the quality of the product including intangible factors such as the motivation and training of the people who produce the product. I won’t go into detail on Dr Deming’s original 14 principles that form the foundation of TQM. If you would like to read more about Dr.Deming’s original fourteen principles, you can go to the following link:
When you read these (14) points, you have to understand the context behind them. They were originally written in the late 1940’s and early 1950’s in the context of a manufacturing environment. It may require a bit of interpretation to re-interpret some of these principles in a broader, more modern context that is not limited to manufacturing, but the concept behind them is still valid today.
How Does TQM Relate to Agile Software Development?
If you think about it, the way software testing has typically been done is essentially a reactive, quality control approach.
- After the software development is finished, it is typically turned over to a separate and independent group for testing.
- It is their responsibility to try to find any defects in the software similar to the way an inspector would try to find defects in a manufacturing product at the end of an assembly line.
The problems with that approach are very similar to the problems in a manufacturing QC approach that were discussed earlier.
- It’s expensive to hire a lot of QA testers just as it is expensive for QC inspectors
- It’s also impossible for any QA testing approach to be 100% complete and some defects are bound to slip through
- There is also a potentially high cost of reworking or scrapping software that is found to have defects
The general approach to correct these problems is the same. Instead of a reactive approach to find-and-fix defects after development is complete; a more proactive approach to eliminate defects at the source will be much more efficient and effective. However, may not be as simple. It’s not just a simple matter of simply going upstream in the process to eliminate defects at the source. In order to eliminate defects at the source, you really need to significantly redefine the process so that:
- The process is much more concurrent rather than sequential. Testing needs to be integrated with development rather than being done sequentially
- The whole team (development as well as testing) is responsible for producing products that are free of defects. It is not someone elses’s responsibility to find defects after development is complete.
Applying TQM to a software development process is typically also a lot more difficult than a manufacturing process.
- In a manufacturing process, some portion of the process can be directly controlled and standardized to reduce variation that might lead to defects
- A software development process needs to be much more flexible and adaptive so it’s not totally possible to control and standardize all aspects of how the process works
- Intangible factors such as human motivation and training can play a much bigger role in a software development process
Nonetheless, the basic principle of designing processes that are inherently reliable and eliminating defects at the source rather than trying to find and fix them later is still very sound.
The ideas behind TQM were created a long time ago and were initially intended primarily for the manufacturing industry; however, they have had a much broader impact on quality management that has lasted a long time. Although many people may not be aware of it, the ideas behind TQM have had a profound impact on the way that quality is managed in an Agile software development process.
You will find much more detail on this in my Online Agile Project Management Training.