Software Delivery Glossary

Adam previews a new project by presenting a few entires from the software delivery glossary.

[00:00:00] Hello, everybody. Welcome to a special episode of small batches. This is going to be a little bit different than the typical episodes as you've already noticed. I wasn't ready with an episode this week, so I didn't have time to send anything off to the audio guy. So I'm just producing this one straight up on my own.

[00:00:25] I also have a new recording setup, so trying to break it in a little bit. So please forgive me for something a little bit different this week.

[00:00:35] Also, I didn't have anything explicitly prepared for this week. So. Luckily, I had something else for a different project that I had been working on. So, what I'm going to do for this episode is read you off a few of the entries I've written for what I would call a software delivery glossary. Now I haven't really edited these very much. This is the first time that I'm really gonna just read these out loud or go through it.

[00:01:08] For many of you, you will have likely heard these terms before and discussed in depth. But, you know, it will give you an overview of what's coming up in this new project. If you'd like to be notified when I do, in fact launched this project, you can subscribe to my newsletter at smallbatches.fm.

[00:01:32] All right. So, let me read off a few of these entries.

[00:01:37] The first one is titled software delivery KPIs.

[00:01:44] Accelerate describes four KPIs. That's a key performance indicator for software delivery performance. Lead time is how long it takes to go from commit to running software and production. Deployment frequency is the number of deploys to production in a given time interval. Mean-time-to-resolve (MTTR) is the mean time between detecting production incidents and resolving them. And change failure rate is the percentage of changes (i.e. software releases or infrastructure changes) that result in production incidents or failures that requires subsequent mitigation.

[00:02:22] All right. Well, I've also written specific entries for each of the individual KPIs. I'm just going to read them off now for more context.

[00:02:31] Deployment frequency is one of the four KPIs from accelerate. Deployment frequency and measures the number of deploys in a given time window. It approximates software delivery tempo. Teams should strive to increase their deployment frequency. The best way to do that is to build automated deployment pipelines and by reducing batch sizes. This KPI is inversely correlated with lead time. High performance teams deploy multiple times per day on demand.

[00:03:01] Okay. Next up is "lead time".

[00:03:04] Lead time is one of the four KPIs from accelerate. Lead time measures the implementation time and deployment time. In other words, it measures the time for when the work is started until that work is running in production. It also measures software delivery tempo. Teams should strive to decrease their lead times. The best way to do that is by building automated deployment pipelines and reducing batch sizes and lowering the barriers to enter production. Lead time is inversely correlated with deployment frequency. As lead time decreases. Deployment frequency increases. High performance teams are able to start and deliver work to production in less than one hour.

[00:03:49] All right. Next one is titled "change failure rate".

[00:03:53] Change failure rate is one of the four KPIs from accelerate. It measures how often changes such as production releases or infrastructure changes result in degregaded service or require immediate resolution. In other words, it's the percentage of defects, that escaped the deployment pipeline. Change failure rate measures, quality. Teams should reduce their change failure rate by applying jidoka and applying countermeasures for known issues. High performance teams have failure rates between zero and 15%.

[00:04:28] Lastly, there's mean-time-to-resolve or MTTR.

[00:04:32] This is also one of the four KPIs from accelerate. It's also well known to anyone who's ever held a pager. It measures the mean or average time from detecting a problem to resolving the problem in production. In other words, it measures how quickly service can be restored. High performing teams, restore service in under an hour.

[00:04:53] So those five entries, I think give you a nice idea of what to expect from the glossary. That point of the glossary is not to cover every little last detail about a particular topic. But to give you enough that if you encounter a particular term, you'll have some context and background for, you know, what it is and how it's applied.

[00:05:16] Also bear in mind that, you know, these are not going to be presented in any order. It's more of a anthology or kind of think of it as one of those daily desk calendars where, you know, every day you pull off a new thing and you get some, you know, something new.

[00:05:33] So the next entry is jidoka. And I just love this one so much. Short and sweet.

[00:05:40] Jidoka is a way of building quality into systems. The concept originates from Saikichi Toyota's work inventing a loom that detected problems stopped and allowed the operator to fix the issue before continuing. It has since grown into a pillar of the Toyota production system.

[00:05:59] All right, let's just pick another one.

[00:06:02] Okay. The Toyota production system, aka TPS, is Toyota's unique approach to lean manufacturing developed over decades. Taiichi initially developed TPS in post-World war II, Japan. In that time demand was low and need for variety was high. These constraints led to the approach with quick changeovers, low inventories and flexibility. Taiichi Ohno's method blends jidoka and just in time to quickly produce a high quality products on demand that fully meet customer needs.

[00:06:36] All right. Let's pick another one. That's kinda Toyota related. This one is titled Kaizen.

[00:06:43] Kaizen is a Japanese word, meaning change for the better or continuous improvement. It's a philosophy of first striving for excellence and the scientific process of iterative experimentation. Focused on raising baseline performance. It was popularized by Toyota's work on lean manufacturing today. It's a pillar of the Toyota production system. Kaizen has broader applications than repetitive manufacturing processes. It's a way to improve the performance of any process.

[00:07:14] All right, I'll give you one more before we wrap up the episode. I'm going to pick one from a recent book. I just read, it's called four types of problems.

[00:07:25] This one is titled Type Three Problem: Target-Condition. It's basically a followup to the previous one on Kaizen.

[00:07:34] Target condition problems move beyond the status quo, regardless of how effective it is. Target condition problem solving creates new problems that did not previously exist. This is continuous improvement or Kaizen. Target condition and gap from standard problems have similar routines, but create different outcomes. Target condition problems are proactive means of improvement. The gap from standard problems are reactive means to meet an established baseline. Both require scientific thinking, but target condition problems are typically larger in scope and gap from standard problems. Thus, they require transforming more parts of the value stream.

[00:08:15] All right. I think that's a wrap for this, short preview of the, software delivery glossary. I think I read off maybe six or seven entries. At the moment I have, 50 entries actually written. So, if you would like to keep up to date on this project, when I finish and release it, then go to smallbatches.fm and subscribe and you'll be the first to find out.

[00:08:45] So what that, I leave you. Thank you for listening to this episode. I'll catch you back two weeks from now for the regular scheduled programming. And hope you had a nice holiday. If you're off today. See ya.

Subscribe to Small Batches

Show notes and other presents sent to your inbox

Got it. You're on the list!
2020 Adam Hawkins