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 it replaces agile, thus spelling the end of agile software development.
That isn’t true, though if you’re interested in agile, you should start learning about DevOps. Why?
Because although it doesn’t replace agile software development, it complements it very, very well. This article will explain the difference between agile and DevOps
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 haz DEVOPS WOOO!”. Don’t listen to them and don’t believe them. You can’t tool your way out of shitty processes and bad 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.
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 legendary 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 deployment was complicated, more so than all of the other deployments, because:
- the production infrastructure was very 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” 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 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, environment management, and release management?
- 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?
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 and devops? DevOps does not replace Agile or Lean. It complements Agile and Lean very well.
It does this by killing waste, removing handovers, and streamlining deployments to allow faster and more continuous deployments to production. Many organisations do Agile, automated 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 agile and devops?
Agile is 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 use some form of Agile Software Development for building your idea
- Then use DevOps for releasing and managing it in production.
I hope this clarifies the difference between agile and DevOps: more specifically, how DevOps complements, but does not replace agile.
