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, please subscribe and share it with your friends and colleagues. So this is it. The first episode of my podcast, it looks like the new year gave me the push.

[00:00:23] I needed to start shipping. I launched this podcast to share ideas and practices that have helped me throughout my career. I write each episode to be short and informative so you can fit them in over a cup of coffee or sometimes to consider a small batches of freeform anthology on the wide world of software engineering and business.

[00:00:41] Allow me to set the stage before we dive into today's topic. My goal as a software engineer is to create systems that are easier to build, test, deploy, and operate in production. I achieve this goal through dev ops dev ops connects our work as engineers to businesses. Exploring internalizing and implementing dev ops has changed my career.

[00:01:03] And I've spent the last few years reading and writing a lot about dev ops. So there's no better way to launch this podcast and introduce you to the topic for this. I turned to two of the best books, the dev ops handbook and accelerate both are written by gene Kim and some other people. You may also know gene cam by his work on the Phoenix project.

[00:01:22] And now the unicorn. The dev ops handbook introduces dev ops principles and their associated technical practices. Accelerate provides metrics to measure progress and evidence of dev ops effectiveness. You need both to understand DevOps, the DevOps handbook introduces the three ways of dev ops. They are flow feedback and learning each build on the other degree of feedback loop between technology and.

[00:01:49] Xcelerate defines four metrics, lead time, deployment frequency, meantime to resolve and change failure rate. Here's how the two fit together flow. The first way of dev ops establishes fast flow from development to production organizations achieve this goal by breaking their work down into smaller batches, preventing defects with continuous integration and automating deployments.

[00:02:12] These practices largely fall under the umbrella of continuous delivery. Teams can measure their flow with two metrics. Lead time and deployment frequency lead time is the time it takes to go from commit to production. Deployment. Frequency is simply how often deploys happen feedback. The second way of dev ops establishes right to left flow of telemetry across the value stream to ensure early detection and recovery or prevent subsequent regressions.

[00:02:38] The idea here is to use production learnings to drive subsequent developments. Here are some examples. Let's say you just shipped a new feature. How do you measure your engagement and another, are there metrics or logs that engineers can use to monitor the system's health? And finally, how do you know how long your CI built or taking teams can measure the second way with the well-known meantime to resolve or MTTR metric learning?

[00:03:03] The third way of dev ops enables a high trust culture of folks around scientific experimentation and learning. The idea is at once work is shipping out to production quickly, and the telemetry is in place across the. Then teams should improve their processes through scientific experimentation. The principle of flow enables teams to quickly shift new business ideas or process improvements.

[00:03:25] Their principle, a feedback interest teams have the information to empirically validate their ideas. Organizations apply this principle through activities such as blameless, postmortems, and AB testing teams can measure the third way by tracking their change failure. That is a percentage of changes that result integrated service or require a follow-up action, like a patch or rollback.

[00:03:47] Although I offer you a different interpretation, I think of it as a percentage of changes that did not deliver the expected results, but that's a topic for a future episode. I have much more to say on these topics, but I'll leave them for future episodes. Let's recap for now apply continuous delivery for fast flow from development.

[00:04:07] At telemetry across your process and use it to drive future decisions, then strive to improve both those processes through scientific experimentation and learning measure your progress with lead time deployment, frequency, MTTR, and change failure rate. Your trajectory should be to decrease lead times, increase your deployment frequency, decrease MTTR and decrease change failure rate.

[00:04:31] Or in other words, as you improve your velocity, instability comes along. All right. That's a wrap on this episode, go to small batches dot Def or show knows a transcript and links to my review and analysis on both the DevOps handbook and accelerate. Also be sure to subscribe to this podcast, receive future episodes.

[00:04:51] And if you liked it, please do share it with your friends and colleagues until the next one. Good luck out there and happy shipping.

[00:05:03] Want to learn more about dev ops, but don't have time for. And sign up for my free email course@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.