Software Delivery in Small Batches

This is the first episode of a few episodes on Dr. Deming's works. Adam recaps Dr. Deming's "System of Profound Knowledge" principle: understanding variation. There are two types of variation: common and special causes. Misunderstanding the type of variation leads to wasted effort and lost resources. Understanding variation helps optimize system performance.

The Deming Rabbit Hole:
★ Support this podcast on Patreon ★

Creators & Guests

Host
Adam Hawkins
Software Delivery Coach

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. In each episode I present a small batch, with theory and practices behind building a high velocity software organization. Topics include DevOps, lean software architecture, continuous delivery, and conversations with industry leaders. Now let's begin today's episode.

[00:00:26] I recently read Dr. Deming's the new economics. The book introduces what Dr. Deming calls the system of profound knowledge. It's a four-part theory for understanding and improving systems. Understanding variation is one part of the system of profound knowledge. You see, variation is a natural trait of life and in systems, I think we implicitly understand this Deming explains how this implicit understanding becomes an explicit aspect of improving systems.

[00:00:59] Let me explain what the simple example, there are two types of variation, common cause and special cause common causes are expected and natural. In other words, they are part of the system. Consider your drive to the grocery store. You know that you'll hit some red lights and green lights. Some days you may get lucky with the lights and never have to make a stop, but don't mistake that for anything special.

[00:01:26] That's common. You see the system is operating. Normally that's just variation at work. What if one day on your way, you got a flat tire that delayed you for four hours. That's a special cause that's something outside the ordinary. Now consider the lucky with delights scenario. Now imagine the opposite where you hit a frustrating amount of red lights. You may mistake this for a special cause and then try to avoid hitting any red lights by changing your driving. That's all for not because of nothing you can do about the lights Deming calls this the first mistake, attributing special cause variation to common cause variation. The second mistake is the opposite attributing, a common cause variation to special cause variation.

[00:02:16] Now return back to the drive for the grocery store. You could assume that flat tires are expected events uncommon, but just a cost of doing business and leave it. There. That's a mistake because special causes can and should be eliminated. You could eliminate, or at best drastically reduce the possibility of a flat tire by conducting routine vehicle maintenance.

[00:02:40] These were stakes and examples demonstrate how to approach special in common cause variation. Special causes should be investigated, mitigated, and at best eliminated, common causes are inherent to the system. They cannot be eliminated. They may only be optimized thus minimizing variation. So why is this important to software delivery?

[00:03:05] Well, the work of software delivery, whichever way you want to measure it, be it lead time. Deployment frequency change, failure rate or meantime to resolve are all affected by variation. So, if we want to improve lead time, then we start by identifying the common and special causes that produce different lead times.

[00:03:24] If we detect special causes. we'll then the system right is chaotic. Optimization is not possible yet. It must first stabilize the system by eliminating special causes afterward. The average limits of variation are predictable with high confidence for the near future quality and quantity are predictable.

[00:03:44] Costs are predictable just in time begins to actually take on the meaning. Then we can set ourselves the task of actually improving the process. Dr. Deming's work describes improving systems by first identifying the stable or unstable nature of the system. Here's my challenge to you. Identify the common and special cause variation in your own.

[00:04:08] work. If you'd like to learn more then I recommend Dr. Deming's work on statistical process control Dr. Schwartz control charts. And of course, Dr. Deming's book the new economics. Also, I want to leave you with two things. If we complete this episode, the first is recommendation for my Toyota kata pocket guide.

[00:04:29] You can get that@toyotapocketguide.com or just go smallbatches.fm. Once you detect and eliminate special causes and turn your attention to common causes. as Well, you'll need a practice for actually optimizing them. That's where the Toyota kata comes in. So get that pocket guide at toyotakatapocketguide.com. Second, if you like this podcast and things I talk about on this podcast and the guests then come and join me in the flow collective. This is a slack group for people like you and me to discuss the ideas of full software delivery and the theory and practices behind the philosophy. So search for the flow collective or go to smallbatches.fm to find a link to the slack group.

[00:05:12] And I hope to see you. there. Thank you for listening. You've just finished another episode of small batches podcast on building a high performance software delivery organization. For more information, and to subscribe to this podcast, go to smallbatches.fm. I hope to have you back again for the next episode.

[00:05:31] So until then happy shipping,

[00:05:37] like the sound of small batches. This episode was produced by pods. Worth Media. That's podsworth.com.