If you are looking to implement a DevOps strategy in your organization there are three core tenants that are widely accepted by the DevOps community. These are known as the Three Ways of DevOps. They can act as a guiding light as you are making decisions and working to change the culture in your organization.
The First Way – Flow
The First Way of DevOps is flow. This involves optimizing the system, not just the technology but the entire human system / process, to keep work moving through the organization as quickly and efficiently as possible. The goal of flow is to reduce the time to value for customers as much as possible. This is typically accomplished through reducing the amount of work in progress, focusing on work flowing in one direction, left to right, and optimizing the entire system to work as whole, rather than optimize for individual team outcomes.
Systems Thinking
The First Way encourages the use of systems thinking. Looking at the entire system, both the technology and the human components. This means looking at the team and organizational processes that create the technological systems and optimizing for the whole system, rather than individual parts. It is often tempting for a team to optimize for what will make the team successful, while forgetting about the overall organization goals and success. With systems thinking, one should always strive to achieve a profound understanding of the entire system.
This also means never passing a known defect to a downstream team. Teams should never allow local optimization to create global degradation.
Removing Constraints
Focusing on the greater system with key bottlenecks in mind. This is the idea that “a chain is no stronger than its weakest link”. A system can move no faster than its slowest part. Much of this comes from the Theory of Constraints (see Theory of Constraints by Eliyahu M. Goldratt).
To be successful in The First Way, teams must, as Gene Kim states, always seek to achieve profound understanding of the system.
The Second Way – Feedback Loops
The Second Way of DevOps is feedback loops. The goal of the Second Way is to shorten and amplify feedback loops within the organization. These feedback loops can take many forms. Everything from feedback loops with customers, via user testing, focus groups and to feedback loops for individuals in the system, like CI/CD systems that fail fast to provide the quickest feedback to the developers or analysts.
Perhaps the most obvious feedback loops are feedback loops between teams. These can take many forms, from stakeholder meetings to informal culture changes to encourage direct collaboration across team boundaries. The most important point is facilitating open communication with the shared goal of removing barriers, reducing time to value and increasing quality.
If these feedback loops are intentional they can and will lead to a higher level of engagement of team members as they feel they have a voice, they can increase inter team unity and help align everyone behind common goals.
The Second Way is aided by effectively utilizing the The First Way. By reducing work in progress (WIP), value cycles happen more quickly as WIP flows faster. This leads to shorter cycles between retrospectives, giving teams more opportunities to focus on what is working well and what isn’t.
The Third Way – Experimentation & Continual Learning
The Third Way of DevOps is creating a culture of continuous experimentation and learning. By encouraging teams to take small calculated risks and allow and even rewarding small failures, teams can learn more rapidly.
The Third Way is supported by the first and second ways. By utilizing the First Way, work in progress is reduced, thus failures are scoped small. Small failures allow teams to quickly determine which ideas don’t work well. Incorporating fast feedback, The Second Way, allows teams to quickly learn about new methods or tools from upstream teams and stakeholders. These scoped failures allow for rapid innovation and learning.
Businesses are generally risk averse by nature. This can be at odds with The Third Way. By making sure risks are calculated and controlled, a risk taking strategy can be implemented without undue risk to the business at large.
Learning is key. When failure is acceptable, when scoped appropriately, as long as learning takes place, failure should be considered acceptable and even embraced. This takes discipline and may take time to prove to business stakeholders that the strategy is warranted. Trust must be built by showing the value of the First and Second Ways.
Organizations should strive for continual improvement, always reinforcing good habits and consistently raising the bar. These can be achieved by allocating time for improvement of daily work and creating rituals that reward the team for taking risk.
Conclusion
The Three Ways of DevOps should be used together to create the best possible outcome for all stakeholders involved. By combining the ideas of flow, shortened and amplified feedback loops and continual learning and experimentation, teams can maximizes the value delivered and shorten the overall time to value, from idea to value delivery to end users.
