Learn the "Thee Ways" of DevOps: flow, feedback, and learning as measured by lead time, deployment frequency, MTTR, and change failure rate.
The DevOps Handbook is the best introduction to DevOps available. It puts the value stream at the center of an IT company, thus it’s in the company’s best interest to optimize the value stream. The DevOps Handbook presents the “Three Ways”: flow, feedback, and learning.
Accelerate picks up where the DevOps Handbook left off. The three ways cover theory and relevant technical practices, but does not precisely define success criteria. Accelerate defines four metrics for measuring IT performance: lead time, deployment frequency, MTTR, and change failure rate. Research done by the authors also presents low, medium, and high performance targets for each metric.
Combining theory and practices from The DevOps Handbook and metrics from Accelerate provide a solid philosophy for software development and measuring performance. That’s “DevOps” in a nutshell.
- Free DevOps Course much more detailed than what we can cover in the podcast
- Products over Projects expand flow, feedback, and learning to the entire organization
- Mastering the Third Way of DevOps use the Toyota Kata for continuous improvement
- The DevOps Handbook by Gene Kim, Jez Humble, John Willis, Patrick Debois
- Accelerate by Nicole Forsgren, Jez Humble, Gene Kim
Creators & Guests
What is Software Delivery in Small Batches?
Adam Hawkins presents the theory and practices behind building a high velocity software organization. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.
[00:16:00] So this is it. The first episode of my podcast, it looks like the new year gave me the push 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 two]. consider small batches a 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 these goals through DevOps.
[00:00:55] DevOps connects our work as engineers to business value. Exploring internalizing and implementing DevOps has changed my career. I've spent the last few years reading and writing a lot about DevOps, So there's no better way to launch this podcast than introducing DevOps.
[00:01:10] For this I turn two of the best books, the DevOps handbook and accelerate both are written by gene Kim and some other people. You may also know gene Kim by his work on the Phoenix project. And now the unicorn project.
[00:01:24] The DevOps Handbooks introduces DevOps principles and their associated technical practices. Accelerate provides metrics to measure progress and evidence of DevOp’s effectiveness. You need both to understand DevOps.
[00:01:38] The DevOps handbook introduces the three ways of DevOps. They are flow feedback and learning each build on the other to create a feedback loop between technology and business. Accelerate defines four metrics, lead time, deployment frequency, mean-time-to-resolve, and change failure rate.
[00:01:56] Here's how the two fit together
[00:01:58] Flow. The first way of DevOps, establishes fast flow from development to production organizations achieve this goal by breaking the work down into smaller batches, preventing defects with continuous integration and automated deployments. These practices largely fall under the umbrella of continuous delivery.
[00:02:16] 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.
[00:02:27] Feedback. The second way of DevOps, establishes right to left flow of telemetry across the value stream to ensure early detection and recovery or prevent subsequent regressions. The idea here is to use production learnings to drive subsequent developments.
[00:02:43] Here are some examples:
[00:02:44] Let's say you just shipped a new feature. How do you measure your engagement?
[00:02:48] Another, are their metrics or logs that engineers can use to monitor the system's health?
[00:02:53] And finally...
[00:02:54] How do you know how long are builds are taking teams can measure the second way with the well known mean-time-to-resolve or MTTR metric.
[00:03:02] Learning, the third way of DevOps, enables a high-trust culture focused around scientific experimentation and learning.
[00:03:09] The idea is that once work is shipping out to production quickly, and the telemetry is in place across the. value stream, Then teams should improve their processes through scientific experimentation.
[00:03:20] The principle of flow enables teams to quickly ship new business ideas or process improvements.
[00:03:25] The principle, of feedback ensures teams have the information to empirically validate their ideas.
[00:03:30] Organizations apply this principle through activities such as blameless, postmortems, and AB testing.
[00:03:36] Teams can measure the third way by tracking their change failure. rate. That is the percentage of changes that result in degraded service or require a follow-up action, like a patch or rollback. Although I offer you a different interpretation, I think of it as the percentage of changes that did not deliver the expected results, but that's a topic for a future episode.
[00:03:57] I have much more to say on these topics, but I'll leave them for future episodes.
[00:04:01] Let's recap.
[00:04:02] Apply continuous delivery for fast flow from development to production. Add telemetry across your process and use it to drive future decisions, then strive to improve both those processes to scientific experimentation and learning.
[00:04:16] Measure your progress with lead time deployment, frequency, MTTR, and change failure rate.
[00:04:22] Your trajectory should be to decrease lead times, increase deployment frequency, decrease MTTR and decrease change failure rate. Or in other words, as you improve your velocity, then stability comes along. for the ride.
[00:04:36] Alright, That's a wrap on this episode, go to smallbatches.com for show notes, a transcript and links for my review and analysis on both DevOps handbook and accelerate. Also be sure to subscribe to this podcast, to receive future episodes.
[00:04:51] if you liked it, please share with your friends and colleagues. Until the next one good luck out there and happy shipping.