Four dimensions to instantiate DevOps principles (Part I)

Image Source: Athena

In 2016, while working as a consultant for a large multinational financial enterprise, the author was informed that user story splitting was not considered a part of DevOps. The company had a clear distinction between Agile and DevOps practices, with the former being solely related to Scrum practices like daily meetings, planning sessions, retrospectives, and user stories, while the latter focused on automation, tool chains, and infrastructure. When the author shared some DevOps principles with a related WeChat group, they received feedback indicating confusion about how they fit into Agile and Lean practices. Some members even felt that those who couldn't handle operations were responsible for managing DevOps.

Image Source: Woshipm

These experiences led me to ponder the following questions: what exactly is DevOps, and what principles does it entail? Furthermore, how does it relate to Agile and Lean? In order to answer these questions, let us examine the origins of DevOps, which can be traced back to two distinct lines.

Line 1: Patrick Debois, an independent consultant from Belgium

Patrick Debois, an independent consultant from Belgium, was working on testing in a government data center migration project in 2007. He had to frequently interact with both the Dev teams, who were already practicing Agile, and the Ops team, who were still working in a traditional Ops manner, while conducting the testing. Observing the exhausted state of the Ops team, he wondered if it would be possible to introduce Agile practices to the Ops team.

Line 2: Flickr, a photo-sharing site owned by Yahoo at the time

On June 23, 2009, John Allspaw, the manager of operations, and Paul Hammond, an engineer, presented a talk at the Velocity 2009 conference in San Jose, CA, discussing DevOps. The title of the presentation, "Deploying More Than 10 Times a Day: Dev and Ops Collaboration at Flickr," gained considerable attention at the time.

The main theme of the talk focused on whether the goals of Dev and Ops were at odds. It was widely believed that the goals of Dev and Ops conflicted since Dev's job was to add new features while Ops' job was to ensure the system remained stable and fast. The changes Dev made while adding new features could cause the system to run slow and unstable, leading to a clash between Dev and Ops. However, from a global perspective, the goal of Dev and Ops is the same, which is to make the changes required by the business available online at any time.

The title and strong perspective of the talk caught the attention of Debois, who tweeted, "It's too bad I couldn't be there," while he was in Belgium. In response, his friend Paul Nasrat suggested organizing a Velocity conference in Belgium, leading Debois to launch the community-sponsored DevOpsDays conference in Ghent, Belgium, from October 30 to 31, 2009. The conference brought together developers, system administrators, and software tool programmers, who had a great time chatting for two days and returned to Twitter after the conference. Due to the 140-character limit on Twitter, Debois dropped the "Days" from DevOpsDays and created the #DevOps hashtag for Twitter chat, thus giving birth to DevOps.

The vision of DevOps is to make the changes required by the business available online at all times, which aligns with the shared goal of Dev and Ops, as emphasized by the two speakers from Flickr. To achieve this vision, Lean provides a readily available tool. The Lean philosophy, derived from the Toyota Production System, is based on the concept of "Shortest lead time," which refers to the shortest time required to complete the entire process from the moment a customer places an order until the goods are received. This philosophy is central to DevOps, which seeks to realize this vision. Jez Humble, one of the authors of Continuous Delivery, recognized the significance of Lean in DevOps, prompting him to modify the CAMS framework for DevOps to CALMS by adding "L" to signify Lean, as discussed below.

The origin of DevOps reveals three important points:

1. DevOps had its roots in a grassroots community and initially lacked a top-down theoretical framework.
2. DevOps is grounded in the same principles of Agile and Lean, as discussed earlier.
3. The overarching goal of DevOps is to make business-required changes available online promptly.

Understanding point 2 is crucial to avoiding misconceptions like "Agile and DevOps are distinct" and "DevOps is just for developers, not operations teams" as mentioned earlier.

Since DevOps began as a grassroots movement, there is no single agreed-upon framework for defining it. DevOps practitioners have devised their own frameworks, including CALMS by Damon Edwards and revised by Jez Humble, and The Three Ways by Gene Kim, among others.

CALMS:

The CALMS framework defines five key areas to focus on for successful DevOps implementation. The first is Culture, which encourages effective collaboration and communication among all stakeholders to support business changes. The second is Automation, which aims to reduce manual processes and increase efficiency in the value chain. The third is Lean, which involves applying lean principles to ensure the delivery of value. The fourth is Metrics, which emphasizes the use of data and metrics to optimize delivery cycles. Finally, the fifth is Sharing, which emphasizes sharing successes and failures for mutual learning and improvement.

The Three Ways:

The Three Ways framework is another approach to implementing DevOps. It emphasizes three key principles for successful DevOps implementation. The first is System Thinking, which encourages global optimization and avoiding local optimization. The second is Amplify Feedback Loops, which involves creating a feedback loop of the development process. The third is Culture of Continual Experimentation and Learning, which emphasizes continuously experimenting, taking risks, learning from failures, and achieving perfection through repeated practice.

Image Source: Woshipm

Need more help? Check out the Zentao blog. They have more articles on project management, software management, building cross-functional teams, and so much more.

--

Author bio :

Wu Bin, a software development consultant at ThoughtWorks, is renowned for his expertise in software development technology practice. He's often referred to as the "Taoist Master" because of his frequent technical practice sessions. With over 20 years of experience in the industry, he's worked in various roles such as programmer, test engineer, project manager, and software development consultant. In April 2013, he founded bjdp.org, a Beijing-based programming practice community for full-stack developers.

Read more:

• Four dimensions to instantiate DevOps principles (Part II)