The Three Core Principles of DevOps
If you ask a group of people "what is DevOps?" you are likely going to get a variety of different answers. Some think it's just the automation of a pipeline. Some people may say it's just developers doing operations work. I subscribe to the idea that DevOps is a mental model for how to think about creating software. From that philosophy some concrete tactics have emerged, such as automating infrastructure and deployments. However those are the end results of thinking like DevOps and applying some principles to the processes of getting work done.
To realize the potential of DevOps you should become intimately familiar with some core principles, expressed as the "The Three Ways of DevOps" from the book, "The DevOps Handbook". If you've not read it I do recommend it, it goes into great detail about the principles. I will summarize them in this blog post though.
I first started learning DevOps by learning about the "Three Ways of Devops", which are the Principle of Flow, the Principle of Feedback, and the Principle of Continuous Improvement.
The Principle of Flow.
The first principle is all about creating smooth flow of work through the different functional areas of an organization, from gathering requirements to releasing features to production. It emphasizes the importance of continuously improving the flow of work through the entire software delivery process, from idea to deployment. The goal is to eliminate bottlenecks and streamline the process of delivering "value" or code. Part of this demands collaboration and communication between teams involved in the process, such as development, testing, and operations. You gotta break down communication silos and allow people to work together.
Functionally, this principle is asking that we do two things in order to improve the flow of work. The first is to reduce the batch size of that work. The second is to eliminate constraints that impede the flow of the work.
Reducing batch size is about breaking down large work into smaller, more manageable pieces. Reducing batch size means less time to complete an item and an increase in frequency of feedback (more on that later). Smaller batches allow for faster and more frequent deployments, which can help to identify and fix issues more quickly. In practice, you can achieve this by implementing agile development methodologies, such as Kanban, that prioritize iterative and incremental delivery of work. It may also involve automating some processes, such as testing, to reduce the amount of manual effort required to complete each batch of work. Reducing batch sizes also reduces the amount of work-in-progress (WIP). Too much WIP can lead to delays and bottlenecks, while too little can result in idle resources and slower progress. Managing WIP is important as it can impact the flow of work through the process.
Eliminating constraints refers to identifying and removing any barriers or limitations that impede the flow of work. This can include technical constraints such as outdated systems, or organizational constraints such as siloed teams. To eliminate constraints, teams often use techniques such as value stream mapping, which involves mapping out the entire delivery process to identify areas where constraints exist. Once constraints are identified, teams can work together to develop solutions to eliminate them, such as upgrading systems, improving communication and collaboration, or automating manual processes.
Dr. Goldratt states in his book, Beyond the Goal: Theory of Constraints
In any value stream, there is always a direction of flow, and there is always one and only one constraint; any improvement not made at that constraint is an illusion.
The Principle of Feedback.
The second principle is the principle of feedback. This is all about creating fast feedback loops across the entire process. Feedback is crucial when it comes to improving quality and efficiency of the process. Feedback comes from a wide variety of sources, including customers, end-users, internal stakeholders, and can be both qualitative and quantitative. Teams want to gather and analyze feedback in order to identify areas for improvement, to validate assumptions, and to make informed decisions about future work. A concrete example of this is creating a CI/CD pipeline to automate testing, which allows for quick feedback on changes made to software. Another example is collecting data on user behavior and system performance to inform how to improve the overall user experience.
The DevOps approach to feedback is to move it closer to the source, rather than making it someone else's problem. For example, if a QA team is exclusively in charge of the correctness of work produced by developers the quality of the product is shifted away from the source. Feedback is received when work moves between work centers in the value stream. This hand-off can create delays and could become a bottleneck. It can disrupt the flow of work. Moving quality closer to the source can improve quality and flow and reduce the WIP.
Overall the principle of feedback is essential in DevOps as it promotes a culture of continuous improvement and learning. By gathering and acting on feedback at every stage of the software delivery process, teams practicing DevOps can deliver better quality more efficiently.
The Principle of Continuous Improvement.
The third principle is about creating a culture of continual learning and experimentation. Fast feedback enables us to learn from mistakes, but we also want to continually improve the entire organization. Continuous improvement involves regular reflection and analysis of the delivery process to identify areas for improvement, such as bottlenecks, inefficiencies, or areas where quality can be improved. Teams use metrics and data to measure the effectiveness of the delivery process and identify areas for improvement.
When teams are consistently too busy or occupied to improve their daily work and resort to workarounds, they accumulate technical debt. This not only leads to persistent struggles but also causes problems that can snowball over time. As a result, processes deteriorate, productivity declines, and throughput diminishes, and flow of work is threatened. Embracing continuous improvement can ensure that teams are delivery high-quality.
Conclusion
Easy peasy, thinking like DevOps can mean a huge transformation to your org, or just a huge personal transformation in how you get your work done. DevOps is more than a set of tools and technologies and practices. DevOps is a cultural shift, it is a mindset, a different way of thinking about solving the problems of building software. DevOps enables a company to ship value to customers more frequently and more efficiently. Just remember the three F's; the principles of Flow, Feedback, and Fine Tuning.