Software Delivery in Small Batches

Adam presents an updated introduction to DevOps principles and practices.

Show Notes

Recommend Reading
Recommended Listening
★ 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.

DevOps 101
Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode, I share a small batch of software delivery education aiming to help find flow, feedback, and learning in your own daily work. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
Today I’m going to revisit DevOps. The idea of DevOps is central to lean software delivery. My own understanding of the topic has changed over the years as I gain more experience and try explaining principles and practices in new ways. So in this episode I’m sharing a revised introduction to the principles and practices behind DevOps. OK, let’s rock.
DevOps is a way of working that optimizes the end-to-end value stream. It uses cross-functional teams that continuously deliver and continuously improve. There are no assumptions about specific technologies, only how they are used.
DevOps begins by establishing fast flow of changes from development to production. Second, use feedback from production to guide future development—be it features, risk, debts, or defects. Third, continuously improve the first two activities through experimentation and learning.
These are "The Three Ways of": flow, feedback, and learning.
Flow applies continuous delivery. Continuous delivery is a way of working that uses automated deployment pipelines to keep software in an always releasable state.
Engineers use trunk-based-development to commit to trunk (or master, main, etc) many times a day. Each commit runs through the automated deployment pipeline to ensure the change is fit for production. If a change breaks the pipeline, then all work is stopped to fix the pipeline.
Deployment pipelines typically follow a process like: build, test, promote to a test environment, run acceptance tests against the live system. Pipelines may be as long or short as needed. Checks begin fine-grained and become more coarse as the pipeline progresses. In other words, the pipeline moves from the bottom to the top of the test pyramid.
Continuous delivery pipelines end with releasable artifacts that may be deployed to production at any time. Production deploys may use feature flags, canary deploys, and/or blue-green deploys to further mitigate risk.
Software only provides value in production. Teams must use telemetry from production to ensure the system is delivering the expected value. Telemetry is information such logs, metrics, and alerts—ideally available in real time.
Telemetry provides the necessary feedback for automated monitoring and manual corrective actions. DevOps teams are responsible for the developing and operating their services in production. This means being on-call, conducting postmortems, and committing to business-as-usual operations work.
Being on-call provides invaluable feedback to service owners. Production issues reveal the consequences of decisions made in development. This leads to better decisions in development that improve production operations. This is the virtuous cycle is the beating heart of the principle of feedback. We call this a feedback loop.
The principle of learning and experimentation uses the feedback loop to continuously improve the end-to-end value stream. The principle of feedback reveals problems. The principle of learning and experimentation is about solving them.
Solving problems may mean enacting countermeasures to mitigate issues. It may also mean designing new systems devoid of the problems. Over time, DevOps teams will improve at detecting and solving problems. This means that failure signals will become increasingly harder to detect. This is an ongoing process of improvement.
Organizations cannot "just" become a DevOps organizations. Transformation begins with the individual—irrespective to their place in organization structure or value stream.
Individuals must change their thinking, thus change their goals. This impacts how goals are set, thus how management works. This means pushing for flow, feedback, and learning, across all parts of the value stream; individuals at all levels working together.
Large scale change does not happen overnight, or a month, quarter, or even a year. It happens in small batches. Incrementally one percent at a time. Eventually, time, effort, and commitment deliver results. Small goals ladder up to larger goals. Success compounds.
Alright, that’s all for this batch. Go to SmallBatches.fm/75 for further resources. I have a link to recommend reading and listening and a much more detailed email course.
Plus there’s a link to Small Batches slack app that posts daily software delivery education to your team’s slack.
I hope to have you back again for the next episode. Until then, happy shipping.