I’ve spent some time around John Willis, one of the thought leaders in the DevOps movement. If you spend any time at all around John, you’re bound to hear him talk about W. Edwards Deming and the idea that Deming laid many of the foundational principles and practices of DevOps. After reading Deming’s book, Out of the Crisis, I have to agree. And now I’m a fan of Deming, too. Not as much as John (just look at his Twitter avatar), but a big fan nonetheless.

John, thanks for inspiring me to read the book. It was well worth it.

The crux of the book is identifying and explaining Deming’s 14 Points for Management. Keep in mind this book was published in 1982 and was based on Deming’s experience in post-World War II Japan during the 50’s and 60’s, which makes his points that much more remarkable. He was way ahead of his time.

Here are four of my big takeaways from the book.

1. Leadership should be focused on the system.
We all know leadership is important. Deming had an interesting spin on leadership and its focus. Instead of treating people as underperformers or overperformers, arbitrarily setting goals, or managing simply “by the numbers”, leadership should focus on understanding the system, controlling the system, and improving the system.

This was one of my favorite threads throughout the book. Here are some choice quotes about the role of leadership.

“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.”

“The aim of leadership should be to improve the performance of man and machine, to improve quality, to increase output, and simultaneously to bring pride of workmanship to people. Put in a negative way, the aim of leadership is not merely to find and record failures of men, but to remove the causes of failure: to help people to do a better job with less effort.”

“Cease to blame employees for problems of the system. Management should be held responsible for faults of the system. People need to feel secure to make suggestions. Management must follow through on suggestions.”

“Beat horses, and they will run faster—for a while.”

2. You need statistical control to have any hope of achieving improvement.
Statistical control is the limitation of variation within the system. All of those statistics terms we learned in high school or college — mean, standard deviation (to establish upper and lower control limits), conditional probabilities — here’s where we get to apply them.

If the system is not in a state of statistical control, you can’t improve it because you won’t have any idea whether changes you’re making to improve the system are having the intended effect.

“Statistical control opened the way to engineering innovation. Without statistical control, the process was in unstable chaos, the noise of which would mask the effect of any attempt to bring improvement.”

The system will produce what the system is capable of producing in terms of throughput, defect rate (quality), and cost. You have to change the capability of the system to get a different result. Management’s tendency to set (arbitrary) numerical goals in the hopes of improving results is pointless without changes in the system. Merely saying, “We’re setting a goal of 10% more [whatever you want more of]” because, “It’s what we want and we think it’s reasonable,” is not a sound approach for improvement.

“If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached.”

There’s also a difference between “common causes” of variability and “special causes”. If you don’t recognize which is which, any effort to change the system could either destabilize the system (and increase variability) or waste time and money.

In today’s world, automation has a big part to play in reducing variability and bringing the system into statistical control. Computers are great at doing the something over and over again the same way every time. No variability.

3. Focus on quality first. Throughput will follow.
Build in quality throughout the process — not just at the end. Don’t rely on inspection. This philosophy has implications for organizations using a more traditional quality assurance approach which puts the bulk of testing at the end of the process.

“Folklore has it in America that quality and production are incompatible: that you can not have both. A plant manager will usually tell you that it is either or. In his experience, if he pushes quality, he falls behind in production. If he pushes production, his quality suffers. This will be his experience when he knows not what quality is nor how to achieve it.”

The State of DevOps Reports have shown that stability (quality) and throughput move together in high-performing organizations, confirming Deming’s point. It’s not a tradeoff.

Deming’s answer for why this is? Less rework. This is a fundamental principle of lean.

If you focus on increasing throughput without improving quality first, you run the risk of just producing crap faster and at a higher cost.

4. Deming was in the DevOps movement.
A lot of the philosophies Deming espouses are ones we hold in the DevOps movement today. Here are a couple of quotes.

“Drive out fear, so that everyone may work effectively for the company.”

This brings Sydney Dekker’s Just Culture and John Allspaw’s Blameless Postmortems to mind. Deming is talking about creating a culture that balances safety and accountability.

“Break down barriers between departments.”

Sound a little like Sharing in CALMS?

Of course, Deming obviously has a lot to share about lean, automation, and measurement, too. See earlier points — or read the book to see for yourself.