Simple: DevOps got its name from a Twitter hashtag (true story).
In seriousness, there’s a lot of confusion surrounding the differences between DevOps and Agile. This stems in part from the fact many marketers use the terms as loosely defined buzzwords, watering down their meaning. However, it isn’t only ambiguity in marketing that contributes to the confusion and fuzzy understanding of the concepts. That both DevOps and Agile focus on principles, as opposed to specific practices, contributes to the confusion as well.
Case in point: We’ve previously defined DevOps as an intersection of culture, processes, and tools focused on breaking down silos between development and operations and increasing the velocity and quality of software delivery. While the Agile Manifesto directly refers to “early and continuous delivery of valuable software” as well as the objective to “deliver working software frequently.” From the perspective of the outsider looking in, it’s easy to see how one could come to ask: “DevOps & Agile both focus on speed, quality, and collaboration in software development, so, what’s the difference?”.
The answer lies in the areas Agile and DevOps emphasize. While Agile, with its emphasis on customer collaboration and developer/customer feedback loops, and DevOps, which prioritizes collaboration between development (Dev) and operations teams (Ops), both benefit from the integration of the best customer feedback tools. Agile aims to incorporate flexibility in software planning and development (to quote the Agile Manifesto: “welcome changing requirements, even late in development”), DevOps stresses automation and streamlining of the development pipeline.
Understanding the differences, and getting the most out of either Agile or DevOps entails understanding the principles behind the respective movements, the practices commonly associated with those principles, and the problems Agile and DevOps are designed to address. Here, we’ll take a deep dive into Agile, DevOps, and the differences & similarities between the two. Oh, and we’ll explain the hashtag thing too.
Agile Origins and Principles
The origin of the writing of the Agile Manifesto is well-known in the world of software development. Seventeen software professionals, known as the Agile Alliance, met at The Lodge at Snowbird ski resort in Utah from February 11th to February 13th, 2001. However, it is important to understand that Agile wasn’t magically created then and there. A movement was brewing for years prior.
In the late 1990s and early 2000s, frustrated with the shortcomings of slow heavy development methodologies like waterfall, thought leaders of the time including ThoughtWorks Chief Scientist Martin Fowler, Extreme Programming (XP) co-founder Ron Jefferies, and ex- theoretical physicist Mike Beedle sought to create a more lightweight and iterative approach to software development. The pain point was simple: traditional software development was too rigid to enable software teams to maximize the value they deliver to customers.
To solve the problem, these thought leaders sought an alternative approach that enabled rapid feedback loops and flexibility. This desire for a lightweight alternative to the waterfall leads to milestone moments such as the Jeff Sutherland and Ken Schwaber codifying Scrum in the 1995 OOPSLA Business Object Design and Implementation Workshop paper and the emergence of Extreme Programming. As the movement continued to gain steam, the founding fathers of Agile met in 2000 at the Rogue River Lodge in Oregon. That meeting led to the scheduling of the Snowbird meeting, and the rest is history.
By the end of the meeting, they agreed to a short and sweet manifesto that serves (or should serve) as the guiding light of Agile software development. The principles behind the Agile Manifesto prioritize:
- Customer cooperation and satisfaction
- People over processes
- Frequent delivery of software
- Ability to adapt to change
- Face-to-face communication
- Simplicity
- Feedback loops
- Small self-organizing teams
What does this mean practically? Agile, putting aside semantic diffusion and taking it for what the founders intended it to be, does the following:
- Speeds up feedback loops between customers and software development teams.
- Empowers software development teams to adapt to change rapidly.
These principles often manifest themselves in the form of practices like stand-up meetings, sprints based on user stories, and the creation of roles like product owner & scrum master. However, it is important to understand that practices are a means to an end; they are not in and of themselves Agile. For an Agile team, what works as a practice today, may need to be modified tomorrow to ensure the team continues to take the iterative, customer-focused, and people-oriented approach to development that is Agile.
DevOps Origins and Principles
Damon Edwards, one of the thought leaders of the DevOps movement, does an excellent job of summarizing the “creation” of DevOps in The (Short) History of DevOps. In a nutshell, around 2007-2008, Patrick DeBois found himself frustrated with the silos that existed between Agile development teams that created software and the operations teams that deployed the software and maintained production servers. At the 2008 Agile Conference, Andrew Shafer and DeBois met and went on to form the Agile System Administration Group.
The goal of the group? To improve cooperation between dev and ops. In 2009, John Allspaw & Paul Hammond showed how breaking down silos between dev & ops enabled Flickr to deploy 10 times per day, adding significant credibility to the concept. DeBois was unable to attend Allspaw and Hammond’s presentation, and was encouraged to create his own conference as a result. The name of that conference? DevOpsDays. The #DevOpsDays hashtag on Twitter helped people keep track of events and thoughts related to the movement, and with time, it got shortened to #DevOps. As the benefits of breaking down the silos between dev and ops became clear, DevOps gained popularity and has grown to be one of the most important terms related to software delivery today.
While that tells us where DevOps comes from and that it is designed to solve the problems created by silos between dev and ops, it doesn’t explain the underlying principles. We’ve explored what DevOps is in-depth in our How (not) to implement DevOps culture? piece and the aforementioned What is DevOps? article, so here we’ll simply summarize “what DevOps is” and the principles that guide it.
DevOps principles may seem abstract and hard to nail down, but The Three Ways makes them easy to understand. The Three Ways are:
- The first way: Systems Thinking – DevOps stresses focuses on the system as a whole and institutes a “shared responsibility” approach. It means dev teams care about production performance and ops teams care about how code is developed and tested. No one focuses on their silo only. Instead, the entire team gathers around the overall system. Specific tools and tech do not solve “human” problems like silos, so the first way is important to understand.
- The second way: Amplification of Feedback Loops – Right (the ops side of things) to left (the dev side of things) feedback loops enable continuous improvement.
- The third way: Culture of learning & experimentation – Taking risks and learning from failures help drive improvement and lead to more resilient systems.
The Three Ways define the underlying principles of DevOps in a way even purists agree to, but there are several practices common to DevOps including:
- Automation of (almost) everything, namely Continuous Integration, Continuous Delivery, Continuous Deployment, and Continuous Monitoring
- Configuration management
- Infrastructure as Code
- Adoption of Cloud Native technologies and DevOps tools
By breaking down the silos between dev and ops, DevOps has been able to deliver tremendous results. Teams that successfully adopt DevOps culture and leverage the right tools can deliver code faster, shorten feedback loops, and improve overall software quality. For example, a Boston Consulting Group analysis has shown that DevOps can reduce can reduce the software development cost by 15-25%, reduce provisioning and deployment times by up to 90%, and increase quality by 50-70% (measured by reduction in change failure rate).
Comparing DevOps vs Agile
Now that we have some background and parameters for discussion let’s thoroughly answer that “How is DevOps different from Agile development methodology?” question. Typically, we can see that Agile is a software development methodology that improves feedback loops between customers & software development teams, while DevOps is a combo of culture, processes, and tools that breaks down silos between dev and ops teams.
This high-level difference helps explain the different areas the two focus on. Now let’s dive into some of the more nuanced differences:
- Agile is a project management approach, while DevOps focuses on optimization of the development pipeline.
- Agile focuses on flexibility in requirements and feature development, while DevOps stresses continuous testing and deployment of the software that is being developed.
- Agile is often associated with frameworks like Scrum, DaD, LeSS, and SAFe, DevOps isn’t generally associated with any particular frameworks and could even be achieved with Waterfall.
- Agile emphasizes people over processes, while DevOps focuses heavily on process optimization and automation.
- Agile focuses strictly on software development and testing, DevOps adds IT operations to the mix
That last point may be the most salient. As Ian Buchanan of Atlassian noted, “DevOps is Agile applied beyond the software team.” Both cultures emphasize speed and quality. Both are malleable enough to allow for integration to a variety of business models and industries. Neither inherently excludes the other. That brings us to an important point: you can have one without the other, but DevOps and Agile complement each other well.
Agile enables teams to emphasize delivering business value to customers in a flexible, rapid, and high-quality way. DevOps provides the underlying operational culture and infrastructure to do so from a technical perspective. Viewed in this light, the complementary relationship becomes intuitive. Well- informed product owners and sprints that run like a well-oiled machine mean nothing if your underlying infrastructure falls apart due to discrepancies between development and production environments. Similarly, the reverse is true. A well-maintained and automated development pipeline doesn’t do much good if you’re not focused on bringing value to your customers.
The takeaway: DevOps & Agile are different but complementary
The reason for all the confusion surrounding DevOps and Agile is simple: many of the fundamental concepts overlap. Collaboration, speed, feedback loops, even the term “continuous delivery” can be associated with both. As you develop a deeper understanding of the two cultures, you understand how and why they are different, and, more importantly, that they can complement one another.
Want to learn more? Contact the experts!
The team here at Cherry Servers is passionate about providing private, secure, and high-performance bare metal cloud servers to small and medium businesses. We believe the democratization of high performance (HPC) computing will help drive innovation across the globe. If you’d like to learn how you can implement Agile and DevOps principles to enable HPC initiatives in the cloud or discuss a specific use-case, contact us today!
