25 Oct DevOps – The 3 Ways
The Three Ways
DevOps is more than just automating the deployment pipeline. In the words of John Allspaw, DevOps is about, “Ops who think like devs. Devs who think like ops.” Elaborating on that thought, Gene Kim explains The Three Ways as principles of DevOps:
The first way
System Thinking – emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large a division or as small as an individual contributor.
The second way
Amplify Feedback Loops – creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
The third way
Culture of Continual Experimentation and Learning – creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
Continuous Delivery (CD) focuses on The First Way: automating the flow from dev to ops. Automation plays an obvious role in helping to accelerate a deployment system. But there is more to systems thinking than just automation.
The Second Way is characterized by the practice, “Devs wear pagers too.” Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It’s not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.
The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it’s relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It’s harder to understand how the hand-offs between roles or organizations introduces delays. This means teams “inspect and adapt” across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn’t reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.
In Scrum, each retrospective is an opportunity to improve the practices and tooling. But if the team isn’t taking advantage of those opportunities to solve both short-term and long-term technical problems, then they will just wait for the Product Owner to put CD tasks into the backlog, which will never happen.
