The difference between Agile and DevOps
DevOps is one of the hot topics at the moment, and is well on its way up the hype cycle curve. Some are even saying DevOps replaces agile, thus spelling the end of agile software development.
Is DevOps on its way up the hype cycle?
That isn’t true, though if you’re interested in agile, you should start learning about DevOps.
Some people say DevOps replaces agile. That’s not true, although it complements agile very well. This article will explain the difference between agile and DevOps.
So the main difference between agile and DevOps is:
- DevOps is an approach to how a firm manages and runs the end-to-end deployment pipelines in DevOps for deploying and managing software (i.e. Continuous Integration / CI and Continuous Delivery / CD pipelines)
- Agile is an approach to how we think about, define and build / test software
- You can (and should) do both agile and DevOps, to get the best of both worlds.
Let’s now look at the relationship between agile and DevOps in more detail.
DevOps is not a tool
This is important: DevOps is not a tool or a product. I cannot emphasise this enough.
Some vendors and snake oil salesmen will tell you that it is. They say “buy our complex deployment toolset and you can instantly do DevOps!”.
DevOps is not just a toolchain!
Don’t listen to them and don’t believe them. You can’t tool your way out of bad processes and poor ways of working.
DevOps is rather an attempt to rethink the value chain of software development, especially the end part of the chain (getting it out to customers), and how it fits into an organisation.
Now I do understand that many organizations have a DevOps toolchain, and that this is an important part of how they work. So we do have and use tools, but the crucial point is that there is more to DevOps than the tools.
DevOps is a rethinking of how we configure and deploy software
Traditionally in software development (whether Waterfall or even agile), there were “development people” who built software. They would move software through some environments. Possibly via manual processes, or maybe via automated processes like build pipelines.
Usually, this involves moving software from a “dev” environment, to some kind of “test” environment, and then probably to some kind of “staging” environment. And that was all fine, but that was as far as they could go. Why?
Because on the other side of staging was the land of Production. It is the mysterious land where magic, opportunity, threats and risks abound. It is the part of the map with “Here Be Draggyns” written on it. And it’s a place where developers are not allowed to go.
Instead, they do a big “handover” to an Operations team. And the Operations team were responsible for doing a bunch of “deployment” activities to move the code from the Staging environment to the Production environment.
This production deployment was complicated, more so than all of the other deployments, because:
- the production infrastructure was often different to the dev or test or even staging infrastructure
- there had to be extra checks and balances and processes to make sure it was all ok because hell, this was production!
- this deployment was done by different people, who had usually never seen or heard of any of this software before. The developers threw it “over the fence” to the operations team. Who didn’t usually understand the software and wouldn’t know what to do if it stopped working.
At this point, people stopped doing “software development” activities and instead did “software deployment” or “service operations” activities. And the people who did that were different to the people who had done the development activities.
DevOps breaks the boundary between development and deployment
So DevOps tries to fix all this. It says:
- what if we could put software into “containers” (like a mini virtual server and OS that the software lived inside) and the containers got shipped around to different environments? Then moving a container from test to staging to prod wouldn’t really matter, because the software is still sitting inside the same container and thus doesn’t care where it is.
- what if we had streamlined checks and tests and processes (i.e. you’re doing test automation in agile / Test Driven Development) for every environment so moving to production was not a big deal?
- what if we had automation of not just our tests, but all of our configuration management in DevOps, environment management, and release management in DevOps?
- and what if we abstracted and virtualized our infrastructure until we had Infrastructure As Code (IAC)? Which meant environments could be managed just like they were software resources instead of hardware resources?
- This is the key one: what if the people moving it to production and looking after it once it is there, worked closely with the people who built the software? Or even better, were the same people who built the software?
Kent Beck was a major figure in TDD and Extreme Programming
This is a major rethinking of the structure and roles in a software organisation. It basically says “you build it, you run it”. You are responsible for it working in dev, in test, in staging, AND IN PRODUCTION. And if you do all this properly, with not just automated tests like a good Agile kid, but also by turning your infrastructure into software by containerisation (is that a word? urgh unfortunately, I think it is), then doing this should be a simple process.
Devops complements agile instead of replacing it
So what really is the difference between agile methodologies (such as the Scrum framework) and devops? To answer this Agile vs DevOps comparison, we need to understand that DevOps principles do not replace Agile or Lean. It complements the Agile development cycle (and Lean) very well.
DevOps is all about improving flow and collaboration
The DevOps lifecycle does this by killing waste, removing handovers, and streamlining deployments to allow faster and more continuous deployments to production. Many organisations do Agile, automated DevOps testing and continuous delivery but only push their pipelines as far as staging. Because the Operations people say “hey hey you can’t cross that line. That’s our territory: you stay in yours, and we look after ours”.
Agile is the bit in between Lean Startup / Design Thinking and DevOps
If you have an idea for a startup and you want to operationalise and scale it, you need to do three things:
- you need to find product / market fit, i.e. find if there is a sufficient market for your idea
- then you need to quickly build your idea
- finally you then need to release, manage and scale up your idea.
So what is the difference between DevOps and agile methodology?
Agile principles are about software development, DevOps is about software deployment and management. Then you also have product management, i.e. defining your product.
So we have three separate but related practices. And there are three good techniques for doing each of these things:
- Use a mix of Lean Startup and Design Thinking for your product / market fit
- Then have some agile teams doing some form of Agile Software Development / agile project management for building your idea – you’ve probably seen this before, cross-functional teams doing user stories in agile to build a backlog, and sprints in agile to deliver product increments
- Then use DevOps practices / DevOps automation for releasing and managing it in production.
This Agile-DevOps culture can be very powerful, and can be found in many successful and leading software firms. You often end up with a Scrum team with an agile Scrum Master, applying DevOps principles to how they manage and deploy their product versions. We know that collaboration in agile is strong, and DevOps is all about collaboration. So it’s a natural fit.
DevOps teams are a danger sign
A “DevOps team” might sound good but is often a danger sign. DevOps is meant to be a change in the way organisations package, manage and deploy their software (and infrastructure). It is meant to remove the barrier between development teams and Operations teams. So a pure DevOps team structure might sound great but is usually the wrong path.
A separate DevOps team is usually a bad sign
Creating a DevOps team and telling them they are basically an operations team but are using DevOps tools / toolchains (and giving them all the job title “DevOps engineer”) is defeating the point. Often, this is just renaming the operations team and keeping the boundaries just like they were before!
Remember, DevOps is not a tool or toolset. It is a change in mindset, approach and processes. If those all stay the same, you are doing it wrong. You want to distribute operations-type activities amongst the development teams, so you remove handovers and silos.
Summary and Frequently Asked Questions
What is the difference between agile and DevOps?
This article has shown that the difference is agile is focused on product discovery, innovation and delivery, while DevOps is focused on quality, flow of work, consistency, configuration and automation. Which allow for frequent, safe and scalable deployments to production.
Is DevOps considered agile?
No, they are different approaches, though they work together very well.
Are agile and DevOps similar?
Kind of. They both are inspired by Lean Thinking, though have a different focus.
What is the relationship between agile and DevOps?
They are complimentary ideas in software development. Agile is an approach focused on fast and frequent learning and discovery of customer value. DevOps is more focused on code configuration, management and deployment.
What is the difference between DevOps and Developer?
A developer is someone involved in development. Normally this is shorthand for “software developer”, though the Scrum framework calls anyone doing any sort of product development work a “developer”.
Can you apply the agile methodology in DevOps?
Sort of. As I’ve shown in this article, they go together very well. The key is to understand that DevOps is not a separate operations team using DevOps tools, but a whole new approach to how firms do software configuration, management and deployments.
So agile teams do Scrum and DevOps teams do Kanban?
This is another misconception. There’s no problem with doing Kanban in DevOps. And Kanban can be used alongside of Scrum. But remember, you don’t really want separate DevOps teams. Kanban often does make more sense for production support teams. But proper DevOps encourages moving away from production support teams, and getting agile development teams to support their own products.
I hope this clarifies the difference between agile and DevOps: more specifically, how DevOps complements, but does not replace agile.
What are the current DevOps hot topics?
The current hot topics in the DevOps world (as of 2023) are:
- Infrastructure as Code (e.g. Terraform)
- building in security into pipelines (i.e. DevSecOps)
- the ongoing evolution of automation and AI (artificial intelligence)
- Multi-cloud support via IaC (Infrastructure as Code)
- Cloud-native techologies.
If you’re still unsure on the role of the agile methodology in DevOps, this video might help clear it up.
