DevOps emerged out of frustrations between development and operations, whereas Agile was born out of teams not being able to deliver what the customer actually wanted.
Traditionally, development and operations teams — separately — would work on relatively heavy waterfall-style projects, but as soon as these started to attract users, it became clear the problem wasn’t being fixed — hence, the rise of DevOps.
With Agile, internal project managers doing date-based delivery used to plan a three-year projects for building software. ‘In three years, we know where this software is going to land,’ they would say. But, the industry has learned that software development doesn’t work like that.
Initially, DevOps was more focused on solving internal organisational problems, whereas Agile had a much more outbound aspect to it; “let’s go interact with customers, get their feedback frequently and bake that into the software as we’re building it,” continues Kersten.
The four values of Agile are: individuals and interactions over processes and tools; working software over documentation; customer collaboration over contract negotiation; and responding to change over following a plan
“Both are structured, but lightweight, with the focus on efficiencies. They also both follow iterative processes, which contrasts with Waterfall — where the expectation is that a fully functional product is delivered at the end.
“With Agile, tasks are prioritised and then organised into short sprints or ‘timeboxes’. This sprint approach works well with DevOps’ cyclical processes – and a toolset designed to offer various reusable components. With Waterfall, however, you would restrict the key benefit of DevOps – namely, continuous delivery.”
Indeed, the two ways of working are inextricably linked and have an awful lot in common.
Agile came out of the development world, as opposed to operations. And DevOps was originally called “agile system administration,” according to Kersten. This term was a “little clunky” and didn’t quite have the “brand sizzle” of DevOps.
The rule of thumb for Agile: always value people over process. DevOps, similarly, puts people at the centre much more and recognises that human interaction patterns are a big cause of problems, in between development and operations.
“I think of DevOps as being Agile plus culture applied to infrastructure, but that’s a relatively simplistic definition,” says Kersten.
But, he highlights that there are a few subtle differences.
He says that “Agile looks more at application development and its associated processes, while DevOps extends into the release and deployment phase and the technologies that rely on continuous integration. However, neither can be 100% successful alone; they must work in tandem, ensuring value for both the business and the customer.
“The underpinning elements of Agile permeate to teamwork and accountability, traditionally implemented within smaller teams. And DevOps is all about collaboration between developers and IT operations. Collaborative working and visibility ensure technology and applications are fit for purpose, and takes into consideration the business’ needs.”
What is DevOps? A complicated principle with transformational outcomes
As mentioned, Agile came out of the development world where software engineering principles were already well understood — “the idea of version control, code review, just releases, tags and branches all worked,” confirms Kersten.
However, when DevOps started a lot of operations people didn’t understand these basic software engineering principles.
It is common that the people Kersten speaks to will get nervous when he mentions the term DevOps, because “they’re an operations person, they’re not a sophisticated programmer and they think they’re just not going to have a job,” he says.
This is one of the more unfortunate aspects of the term DevOps, because it makes those in operations think they have to be the equivalent of an enterprise systems architecture to actually do a DevOps role — really it’s just about basic software engineering.
Agile started from a place where software engineering principles were relatively well understood; and DevOps is about taking those principles, but also having to educate those in operations about how to adopt these tools.
“Although some might argue that there is a shortcoming of communication with Agile at the deployment stage — as this is where different teams come together with different code — by combining the development, operations and quality assurance functions, DevOps removes that separation and, therefore, resolves this weakness,” says Greenwood.
How DevOps works in the enterprise
The big difference
The big difference between DevOps and Agile is that DevOps is much more concerned with understanding the value being delivered.
Similar to the way Agile and DevOps contrast with software engineering principles, those in IT — in the 1990s — were essentially away in a cave running infrastructure for the sake of infrastructure.
They weren’t necessarily well connected to the rest of the business. This is the most positive aspect of the whole DevOps movement, that those in operations have been pulled out of the cave, blinking into the sunlight, and being asked to actually deliver business value and start to understand what those terms mean.
“I don’t think you can be an ops person anymore in the way you could in the 1990s,” says Kersten. “That idea of needing to understand the value of what you’re delivering, I think that’s been a huge factor for DevOps.”
Why do we need DevOps? For the business and consumer
Agile before DevOps
Today, it’s pretty rare that Agile hasn’t entered an enterprise in some sense.
For most places that are undergoing any kind of DevOps transformation, Agile ways of working need to be understood. But sometimes “that’s happening at the same time as the DevOps transformation,” says Kersten.
It’s entirely possible to have a world-class DevOps team delivering applications in a waterfall way, and not using agile practices. “But, there’s still an impedance mismatch and I think to really get the benefit out of automation and sophisticated APIs, you need to be doing development in an Agile way,” says Kersten.
“As someone who has spent a fair bit of their life project managing engineering projects, Agile is just a huge relief — it takes that pressure off you of unrealistic deadlines that you’re essentially making up out of thin air, because this still isn’t science, there’s a lot more art to it.”
Top DevOps interview questions and answers revealed
Agile and DevOps: enterprises don’t have a choice anymore
DevOps and Agile are mandatory for success — enterprises don’t have a choice any more.
The businesses that aren’t adopting those practices “don’t realise how badly they’re failing,” believes Kersten. “Or maybe they do and they’re unwilling to change,” he says.
It is true that for any large enterprise, it is very difficult to change and adopt new ways of working, such as Agile and DevOps.
This is one of the interesting aspects of the DevOps enterprise movement: leaders are recognising that there’s no magic bullet in this area. Transformation requires the embrace of many different disciplines and cultural change. And can take two to three years to implement.
Agile and DevOps skills
For both, there’s base expectations around software engineering. “It’s how to; use version control, ode review, structure commit messages and it’s the idea of testing,” explains Kersten.
Both Agile and DevOps are reliant on testing; “having an idea of what’s the difference between a unit test, a black box test, acceptance tests, all these different ways of testing your infrastructure and your application,” he continues.
“They’re the guard rails in many ways to give you the trust to be able to work in a slightly more free way, because I think this is one of the huge fears in enterprises when they adopt either Agile or DevOps. There’s an awful lot of people in these organisations whose job it is to exert control, to run gantt charts, to keep track of projects, to keep the whole machine humming, and a lot of that kind of work goes away because you’re having to trust individual developers and operations folks much more.”
The DevOps challenge: outdated IT estate architectures
Polluted by consultants
There’s a lot of scepticism around both DevOps and Agile. And in many ways, Agile — its name and brand — has been somewhat polluted by the huge wave of consultants that came in and promised radical change in organisations and promised to deliver it quickly — none of that happened. So, there’s an awful lot of scepticism around agile at the practitioner level. “That’s definitely arisen in the past few years around DevOps,” confirms Kersten.
“Maybe this is just a natural consequence of the life cycle, but I’d say I think those terms are going to fade into the background and just become how we do development — similar to the cloud — and we won’t even talk about DevOps vs Agile vs waterfall or traditional IT versus,” he says.
“But I do feel that DevOps in the enterprise is likely to be a strong movement for the next decade.”
The DevOps engineer: fulfilling the software development life cycle
Nominations are OPEN for the Tech Leaders Awards, organised by Information Age and taking place on 12th September 2019 at the Royal Lancaster, London. Categories include CIO of the Year, CTO of the Year, Digital Leader of the Year and Security Leader of the Year. Recognise and reward excellence in the tech industry by submitting a nomination today