Obstacles 9-12
Pleasant Dreams
9. “Our troubles lie entirely in the work force.” The supposition is prevalent the world over that there would be no problems in production or in service if only our production workers would do their jobs in the way that they were taught. Pleasant dreams. The workers are handicapped by the system, and the system belongs to management. It was Dr. Joseph M. Juran who pointed out long ago that most of the possibilities for improvement lie in action on the system, and that contributions of production workers are severely limited…
It is thus not sufficient to improve processes. There must also be constant improvement of design of product and service, along with introduction of new product and service and new technology. All this is management’s responsibility.
10. False starts. False starts are deceptive. They give satisfaction, something to show for effort, but they lead to frustration, despair, disappointment, and delay.
One kind of false start arises from the supposition that wholesale teaching of statistical methods to enough people in production will turn things around. The fallacy of this supposition has been amply demonstrated. Understanding of variation, special causes and common causes, and the necessity to reduce constantly the variation from common causes, is vital…
Another false start is QC-Circles. The idea has appeal… A QC-Circle can thrive only if the management will take action on the recommendation of the Circle. Many QC-Circles are, I fear, management’s hope for a lazy way out.
11. “We installed quality control.” No. You can install a new desk, or a new carpet, or a new dean, but not quality control. Anyone that proposes to “install quality control” unfortunately has little knowledge about quality control. Improvement of quality and productivity, to be successful in any company, must be a learning process, year by year, top management leading the whole company.
12. The unmanned computer. A computer can be a blessing. It can also be a curse. Some people make good use of computers. Few people are aware, however, of the negative input of computers. Time and time again, in my experience, when I ask for data on inspection, to learn whether they indicate that the process is in control, or out of control, and at what time of day it went out, and why, or ask about differences between inspectors and between production workers, or between production workers and inspectors, in an attempt to find sources of trouble and to improve efficiency, the answer is, “The data are in the computer.” And there they sit. People are intimidated by the computer. They can not tell it what data or charts they need: instead, they take whatever the computer turns out, which is reams of figures.
- Deming, W. Edwards. Out of the Crisis (MIT Press) (pp. 134-139). The MIT Press. Kindle Edition.
THE AIM of today’s post is to continue our review of Dr. Deming’s obstacles to transformation, with our focus on the next four (9-12) as they appeared in his 1986 book, Out of the Crisis. All will feel familiar, even to modern managers and employees.
We begin with the well-worn complaint that “Our troubles lie entirely in the workforce” which has never really gone out of vogue though it may travel under different guises today. Anywhere we find quotas, targets, and appraisals to provide “correction” to people, we will find this obstacle to transformation right at hand. Recall in our earlier post, Who’s to Blame?, Dr. Deming’s observation that built on Dr. Juran’s:
"I should estimate that in my experience most troubles and most possibilities for improvement add up to proportions something like this : 94% belong to the system (responsibility of management) 6% special"
Time and again, even among seasoned practitioners in my field, I see this understanding escape their attention, especially in circumstances where a “solution” is offered to management that absolves them of participation. This obstacle may also travel as a hidden stowaway in well-intended initiatives like the Manifesto for Agile Software Development which can reinforce to management that poor outcomes for software projects were the teams’ fault all along. My longstanding theory is that many “Agile” transformations fail for the reason that all the changes only occur at the team layer while everything else is held constant.
False starts occur when we try to gain the benefits of a new way of working without understanding why or how it works, or what is necessary to have in place before beginning. Results? Delay of learning, confusion of coincidences with causes-and-effects, and typically resignation and abandonment of the effort, concluding that “we tried that here, and it doesn’t work”. What is not typically appreciated, especially in organizations that succumb to the Deadly Disease of mobility of management, is that this is a signal more learning is required.
In The Leader’s Handbook, Peter Scholtes uses two simple graphs to illustrate the delta between what we think a “learning curve” looks like (reality: a false curve) and what may be actually happening. He observed that moving from A to C in Figure 1-5 can take a year or longer as everyone in the organization moves through stages of “false” learning, believing they are mastering the concepts before becoming confronted with a situation that proves how unprepared they are. That’s when the “real” learning curve commences. Of course, this is one executive promotion or departure away from a total reset.
We installed quality control is very familiar to those of us who’ve tried (and failed) to transform software delivery practices from the team room-upward. For a time the misplaced idea that you could “roll out” or “implement” agile was in vogue, and still remains today with frameworks like SAFe. Unfortunately, quality isn’t so easily improved without the full participation of top-management. As we saw with Obstacle #1, affirmations of faith are insufficient.
A few years ago, a colleague satirized a prevailing meme where everyone was copying the “Spotify model” of how to “install and scale” agile practices in their organization without understanding the why or how (the methods). Much truth in jest, here:
Finally, The Unmanned Computer or “the data are in the computer” is, surprisingly, still with us today. Enormous sums continue to be spent to find answers to seemingly eternal questions like “How long will it take?” and “How much will it cost?”. Software delivery teams are often required to work with applications that make this difficult to answer, and more importantly, do nothing to help improve the quality of the product.
One team I indirectly worked with at a large organization was once tasked to produce a system status figure (yes, just one!) on a dashboard for an important executive. It took almost a day for the respective parts of the organization to collate the required data into this single figure (on top of the demands of their work) that the executive would see completely out of context, and caused them anxiety whenever it went down or stayed constant for too long. Showing the data on a run-chart would have prevented much grief and might even have changed the executive’s mind about the value of the figure.
Reflection Questions
How many of the above obstacles have you encountered in your organization or over your career? How many “false starts” have you witnessed? What examples of holding employees to account for management decisions can you recall? What was the prevailing attitude toward “installing quality”? What limitations of data in a computer were found? What positive efforts did these conditions obstruct? What were the consequences? How could they have been overcome? What similar obstacles do they suggest to you?