Agile development used to be front and center in the conversation about software development. Now, DevOps has taken over the conversation. How do agile and DevOps relate? Both ideas began as ways to improve different aspects of software development. Agile embraced the changing nature of requirements and prioritized working software over rigid processes. DevOps collapsed the development and operations silos to improve both development and production operations. Each shares some fundamental ideas, but each target different stakeholders and set different business goals. Given the overlap, people ask is DevOps agile or if we do DevOps do we also need to do agile? Or, is agile even still relevant? Or, what’s the point of either of these things anyway? This post answers those questions and also demonstrates how DevOps is different than agile and that both are still useful, and required for successful software development. (You can also watch our Recipe for DevOps Success webinar and read our post on The Four Tactics for Cultural Change in DevOps Adoption to learn more about what can be achieved in the enterprise with DevOps.)
Context and Background
Agile development traces back to the 1990s with practices like scrum, extreme programming (XP), feature-driven development, and user stories. The agile manifesto was written in 2001 by prominent software developers like Martin Fowler, Kent Beck, Ward Cunningham, and Bob Martin. The primary section of the manifesto reads with bold highlights:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile was a response to constraining software development processes like waterfall. The idea was to be flexible, iterate, work with stakeholders to produce software that met their requirements while also increasing predictability. Generally speaking, agile development is a set of practices for developing software in teams and largely focused on planning and requirements.
DevOps traces back to the late 2000s and early 2010s. Organizations tended to have dedicated development and operations teams where development threw their compiled code over the wall to operations for them to run it. This created problems since operations was disconnected from the code they’re supposed to support in production, and development was also disconnected from the operational aspect of their software. Each group had conflicting goals. Operations wanted stable environments and to minimize changes. Development needed to ship features as quickly as possible to build new product features. These two groups were at odds in fundamental ways. The DevOps idea was to break the silo between operations and development (hence “dev” and “ops”) and replace it with a shared feedback loop.
Today, DevOps is an umbrella for technical practices like continuous integration, continuous delivery (or deployment), high levels of automation, and cross-functional teams.
There’s no official manifesto, but the DevOps Handbook is the best reference for the ideas and practices behind DevOps. The DevOps Handbook documents the three ways of DevOps:
- The Principle of Flow: decrease the time from commit to code running in production. This metric is called lead time.
- The Principle of Feedback: increase the feedback from production back to development (through practices like real-time monitoring and automated alerting)
- The Principle of Continuous Learning and Experimentation: continuously improve and evolve processes
Each principle mandates technical practices such as building a continuous delivery pipeline, adding required production telemetry, and conducting outage post-mortems.
Simply put, Agile tackles the problem of building software and DevOps focuses on getting code into production and improving that process. Each addresses a different—but equally valuable—part of software development. Agile set the stage for DevOps. Agile provides teams a way to build software faster and thus deploy more often. DevOps provides teams a formula to deploy more often and increase quality.
How Agile and DevOps Differ
Agile and DevOps each target different actors in the SDLC. Agile covers project management and requires strongly defined roles like Product Owner. DevOps targets more technical work and requires engineers to accept shared responsibility for building and deploying software while requiring management and product owners to think of their software in a certain way. Here’s how this plays out in practice.
There are plenty of different methodologies such kanban or scrum. Both focus on the procedure for accomplishing tasks—regardless of the technical details. Kanban has a set of principles to limit work in progress, track bottlenecks, and promote visibility. Scrum aims to make software development more predictable by setting a fixed time and scope for a sprint, then letting the team self organize and work through the issues as they arise. This is where many people encounter agile development and it is often driven by whatever software the team uses to track work.
DevOps comes in when code needs to be written. The first principle of DevOps focuses on getting code into source control and then into production. It makes no assumptions about the process used to spec out customer requirements or how to prioritize a backlog. The premise is simple: whatever work is done should ship to production as quickly as possible. However, a successful DevOps implementation requires back-pressure from development that agile methodologies supply. This is the opposite of waterfall development, which is incompatible with DevOps and for with is the antithesis of Agile.
Agile calls for fixed roles and responsibilities. Product Owner (or PO) is arguably the most important role since the PO is responsible for setting requirements and clarifying how the product should work for engineers. Scrum uses a dedicated scrum master to manage the process. There are even certifications for scum masters. DevOps makes no proclamations about dedicated roles. DevOps is closer to a set of behaviors than a defined role. In fact, there’s a trend in the industry to post job “DevOps Engineer” roles. This goes against the DevOps ideas of shared responsibilities and technical practices. DevOps cannot be a dedicated role.
Agile-Backed DevOps is the Way Forward
It should be clearer now how Agile and DevOps are both ideas and apply to different areas in the SDLC. Agile is a framework for building products and DevOps is a set of technical practices for deploying and running production systems. Given these two ideas are different and equally powerful, you should adopt both in your SDLC.
Agile practices such as pair programming is a fantastic way to distribute knowledge and improve code quality, regardless of what the code is for. Such practices can produce new features, fix bugs with internal tooling, or lead to infrastructure as code in your deployment pipeline. DevOps calls for shared responsibility and understanding of the deployment pipeline and other associated infrastructure. Pair programming is a great way to expose engineers to this environment and grow their knowledge.
Again, agile development practices apply to most software projects be it working through the product backlog or building out internal tooling. All software projects benefit from faster cycle times and quicker feedback from production. In fact, that’s key to a successful agile process. The agile process focuses on stakeholder feedback from interacting with working software. The faster working software is released to stakeholders, the faster changes happen, thus the overall process accelerates. Adopting agile without bringing in DevOps principles will inhibit your organization’s velocity and slow your software release cadence.
Accelerate – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations researches the traits behind the best performing teams. The authors find that implementing DevOps practices such as trunk-based development and continuous delivery are clear indicators of high performance. Their 2017 research found high performers compared to low performers have1:
- 46 times more frequent code deployments
- 440 times faster lead time from commit to deploy
- 170 times faster mean time to recover from downtime
- 5 times lower change failure rate (1/5 as likely for a change to fail)
The first two points stand out since they demonstrated just how fast an agile process backed by DevOps may be. These factors build on each other to create more successful businesses. In fact, Accelerate also found that high performers had 50% higher growth in market capitalization over three years compared to low performers.2 Again, bear in mind that these achievements are possible when the agile process provides adequate back-pressure to DevOps behaviors.
This post covered the relationship between Agile and DevOps along with their historical context and target area. Just by looking at the history, we find that DevOps is a technical continuation of Agile’s ideas. Both philosophies favor fast iterations and quick reactions to changing conditions. They’re similar ideas but target different phases of the SDLC. The most successful teams apply agile development practices and DevOps deployment practices. The odds are that your organization is already working with agile development in some way. Improving your DevOps practices is the next step to boosting velocity and quality in your organization. Reach out to us to request a demo and learn how we can guide you in your digital transformation journey.
- Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Locations 434-436). IT Revolution Press. Kindle Edition. ↩︎
- Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Locations 2734-2735). IT Revolution Press. Kindle Edition. ↩︎
New Content: Azure DP-100 Certification, Alibaba Cloud Certified Associate Prep, 13 Security Labs, and Much More
This past month our Content Team served up a heaping spoonful of new and updated content. Not only did our experts release the brand new Azure DP-100 Certification Learning Path, but they also created 18 new hands-on labs — and so much more! New content on Cloud Academy At any time, y...
Docker Image Security: Get it in Your Sights
For organizations and individuals alike, the adoption of Docker is increasing exponentially with no signs of slowing down. Why is this? Because Docker provides a whole host of features that make it easy to create, deploy, and manage your applications. This useful technology is especiall...
Constant Content: Cloud Academy’s Q3 2020 Roadmap
Hello — Andy Larkin here, VP of Content at Cloud Academy. I am pleased to release our roadmap for the next three months of 2020 — August through October. Let me walk you through the content we have planned for you and how this content can help you gain skills, get certified, and...
New Content: Alibaba, Azure AZ-303 and AZ-304, Site Reliability Engineering (SRE) Foundation, Python 3 Programming, 16 Hands-on Labs, and Much More
This month our Content Team did an amazing job at publishing and updating a ton of new content. Not only did our experts release the brand new AZ-303 and AZ-304 Certification Learning Paths, but they also created 16 new hands-on labs — and so much more! New content on Cloud Academy At...
New Content: AWS, Azure, Typescript, Java, Docker, 13 New Labs, and Much More
This month, our Content Team released a whopping 13 new labs in real cloud environments! If you haven't tried out our labs, you might not understand why we think that number is so impressive. Our labs are not “simulated” experiences — they are real cloud environments using accounts on A...
New Content: AZ-500 and AZ-400 Updates, 3 Google Professional Exam Preps, Practical ML Learning Path, C# Programming, and More
This month, our Content Team released tons of new content and labs in real cloud environments. Not only that, but we introduced our very first highly interactive "Office Hours" webinar. This webinar, Acing the AWS Solutions Architect Associate Certification, started with a quick overvie...
DevOps: Why Is It Important to Decouple Deployment From Release?
Deployment and release In enterprise organizations, releases are the final step of a long process that, historically, could take months — or even worse — years. Small companies and startups aren’t immune to this. Minimum viable product (MVP) over MVP and fast iterations could lead to t...
DevOps Principles: My Journey as a Software Engineer
I spent the last month reading The DevOps Handbook, a great book regarding DevOps principles, and how tech organizations evolved and succeeded in applying them. As a software engineer, you may think that DevOps is a bunch of people that deploy your code on production, and who are alw...
Linux and DevOps: The Most Suitable Distribution
Modern Linux and DevOps have much in common from a philosophy perspective. Both are focused on functionality, scalability, as well as on the constant possibility of growth and improvement. While Windows may still be the most widely used operating system, and by extension the most common...
How to Effectively Use Azure DevOps
Azure DevOps is a suite of services that collaborate on software development following DevOps principles. The services in Azure DevOps are: Azure Repos for hosting Git repositories for source control of your code Azure Boards for planning and tracking your work using proven agil...
Docker vs. Virtual Machines: Differences You Should Know
What are the differences between Docker and virtual machines? In this article, we'll compare the differences and provide our insights to help you decide between the two. Before we get started discussing Docker vs. Virtual Machines comparisons, let us first explain the basics. What is ...
DevOps: From Continuous Delivery to Continuous Experimentation
Imagine this scenario. Your team built a continuous delivery pipeline. Team members deploy multiple times a day. Telemetry warns the team about production issues before they become outages. Automated tests ensure known regressions don't enter production. Team velocity is consistent and ...