Notes from the Book - Four Days with Dr Deming
I have recently finish reading the book Four Days with Dr. Deming: A Strategy for Modern Methods of Management (Engineering Process Improvement Series)
This book is designed to replicate the feeling that a CEO would have had attending one of Dr. Deming’s four day seminars. The book is a relatively quick read and is presented to appeal to multiple learning styles.
Some of the items that strike me as most important in applying Dr Deming’s principles are:
A) Quality needs to be top down to be truly effective.
Bottom up is ineffective. Even if the bottom tier is doing it’s assigned duties in a high quality fashion, they may still not be doing the right thing. It is an employees job to make sure that he “cuts down trees” in as efficient manner as possible. It is a leader’s job to make sure that the employee is in the right “forest.” The employee does not have the visibility to know if he is in the correct forest. This is especially true in software development. The cost of finding a defect increases exponentially the further away from it’s point of origin. If quality is not made a priority for the whole team and is relegated to a Quality Assurance group, the system will not function optimally.
B) Variation always exists.
The identification of “special causes” and “common” causes are key. Special causes can be fixed by the people implementing the process via such things as training. Common causes need to be fixed by changing the process. Until Fred Brook’s Silver Bullet
C) Systems with only common cause variation are said to be stable.
Stable systems can only change if the process changes. Attempting to provide further training to individuals will be ineffective.
D) Classifying variation incorrectly can lead to worsening the system.
When common causes of variation are classified as special, improvement will be focus at the individual level. This will be ineffective. When special causes are classified as common, adjustments will be incorrectly made to the process that can lead to worsened quality. Many times the tool used to inspect a process will give more trouble that the process itself.
E) The optimization of the system rarely occurs from the optimization of the individual parts.
Competition between individual parts of the system will lead to sub-optimization. Only through cooperation can the system be optimized. As interdependence increases in a system, the amount of cooperation required to optimize will increase. If I as a tester turn the finding of defects into a competition with the developers, I am not operating in the best interests of the system. I should be helping the developer to eliminate as many of these defects as early as possible. I should be providing clear duplication steps and be willingly to help the developer understand the issues better. I need to realize that testing is not about the number of defects found. Testing is about helping a customer do what they would expect the program should do with little trouble.
F) Plan(Design) - Do(Make) - Study(Sell) - Act(Test in Service) - Repeat(Redesign)
Iterative development processes are reminiscence of the Shewhart cycle presented in the book. Iterative development only seems to differ in how many releases are actually tested in service.
G) “To Achieve Quality There is No Substitute for Knowledge”
Implementing anything without understanding it is doomed to failure. A process must be understood to be properly implement and to be improved. Attempting to implement “best practices” will fail if the theory behind the practices are not understood.
H) “Quality can’t be assured (after the fact), it must be built in.”
Attempting to assign an individual the job of Software Quality Assurance is a fallacy. If anyone on the team attempts to assign the quality of the product to another individual, poor quality will result. We need to eliminate this title.
I) Focus should be placed on people performing outside the bounds of the normal system.
People who are on the negative side need special help via training. People on the positive side need to be studied. People within the bounds of the system need the system to continually improve.
J) “The most rigorous adherence to procedures does not ensure the desired quality.”
If the process is poor, perfect execution of individual procedures will not make a quality product. The process and procedures must change.
K) Most of the testing done in service organization is done after it has been completed.
Testing a product after it has been completed is the least effective testing that can occur. It is hard to stabilize software development procedures. Each product and team will face unique challenges that potentially have never been attempted before. The speed with which software is being developed doesn’t help any. If software testing is to become independent of the process of development, the process must stabilize.
L) Consumer cannot tell the developer everything.
Often the developer is in a far better position than the consumer to invent new designs and new services. Consumer frequently do not even know that they might need a particular feature until after they have used the feature. This implies that while the consumers voice is valuable it is not omniscient. Developers can improve a product even more when they actually use their own product.
The only issue I had with the book was related specifically to the quality of the design of the book. It is presented in a landscape format but the margin by the bind was too small. I was constantly having to pry open the binding to see the inner most columns.
Overall, I thoroughly enjoyed the content of this book and would highly recommend it to anyone. Dr. Deming’s principles are usually taught from a manufacturing perspective but I believe they can also be effectively applied software development.
