Software Delivery in Small Batches

[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. Each episode, I share a small batch of software engineering theory and best practices. If you enjoy this podcast and please subscribe and share it with your friends and colleagues.

[00:00:17] This episode completes our introduction to, for three ways of dev ops.

[00:00:22] Their previous two episodes introduced flow and feedback.

[00:00:26] Flow the first way establishes left to right flow from development to production feedback. The second way of dev ops establishes right to left feedback from development to production. The third way of dev ops establishes a culture of experimentation and learning around improving flow and feedback.

[00:00:45] Let's frame this discussion using the four metrics from accelerate:

[00:00:48] -lead time

[00:00:49] -deployment

[00:00:50] -frequency

[00:00:51] -MTTR

[00:00:52] -change failure

[00:00:54] Lead time and deployment frequency, both measure flow, MTTR measures, feedback, change, failure, rate measures, experimentation and learning trends. In these four metrics also reflect experimentation and learning.

[00:01:08] Consider this scenario. There's this severe six hour production outage. As a result, the business has lost money and received angry emails from customers. This long outage window impacts the teams MTTR. This bug, which went undetected by the deployment pipeline costs and outage, which increase the change failure rate. The team meets as soon as possible after restoring production operations, what do they do? If they apply the third way of dev ops, then they would conduct a blameless post-mortem the post-mortem would identify the root cause of how this bug entered production and what regression tests can prevent it in. Hopefully, they also discuss why it took six hours to restore operations and how they can improve a turnaround time next time.

[00:01:57] Here's another scenario, a team ships new features on a regular basis, but they don't see the expected business results. They thought these features would deliver results, but they can't figure out why they are not.

[00:02:10] So what can be done? Well, first, the team needs to step back and check their assumption. And instead of going all in on big features, they can test their assumptions with tiny experiments released to a small segment of their user base. If the results are positive, then the team should continue iterating. If not, well, then the team tries a new idea using this practice over time, the team sees that they spend more time delivering on proven business ideas instead of ideas, they assume what just. This approach is known as AB testing or hypothesis driven development from the lean it school.

[00:02:46] Both scenarios demonstrate a focus on improvement through experimentation and learning. However, this is only possible in a high trust culture. It's not possible to conduct a blameless postmortem. If people are afraid they're going to be fired over what they say. It's also not possible to conduct A/B tests. If the organization does not see the value in validating business ideas through experiments, this is why leadership must promote these principles. Now I'm going to read one of my favorite passages from the dev ops handbook. Now there are many wonderful passages in this book, but this is one of my favorites. This passage is a great example of leadership's role in a high trust culture:

[00:03:30] Internally. We describe our goal as creating quote buoys, not boundaries on quote, instead of drawing hard boundaries that everyone has to stay within, we put buoys that indicate deep areas of the channel, where you're safe and supported. You can go pass the buoys use as long as you follow the organizational principles after all, how are we ever going to see the next innovation that helped us win if we're not exploring and testing the edges?

[00:03:58] I just love that quote - there's so much good stuff there. It describes a high trust culture. Get it by safety and aligned through principles. The four metrics lead time, deployment, frequency, MTTR, and change failure rate our SLIs for your it. Dev ops is a set of principles that guide organizations to move these SLIs in the right direction, and when one done right the results are outstanding. You just need to ask yourself, how can we improve? If you can stick to asking that question, then you'll uncover that improvement of the daily work is the daily work.

[00:04:38] Alright, that's it for the principle of experimentation and learning these three ideas will come back time and time again on the podcast, but Hey, you can always come back to these episodes if you need a refresher.

[00:04:51] Head over to the podcast website, small batches.dev for links and our free ebook on putting continuous improvement into practice until the next one. And good luck out there and happy shipping.

[00:05:08] Want to learn more about dev ops, but don't have time for books and sign up for my free email course at freedevopscourse.com. The course details of three ways in depth, along with continuous delivery, trunk based development, and much more over the course of nine days. Sign up now at freedevopscourse.com.