World Class On-Call & Alerting - Free 14 Day Trial: Start Here.

The Real Definition of Agile for IT Operations

Kelsey Loughman December 12, 2019

DevOps Release Collaboration
The Real Definition of Agile for IT Operations Blog Banner Image

System configuration, testing, release management, service desk management, security, network upkeep and incident management have always been core responsibilities for IT operations and security teams. For years and years, developers wrote code and shipped it over the fence to IT operations where they were tasked with finding out how to get it to production. Then, Agile software development practices took over and developers started to ship code faster and faster – creating a backlog of work for IT teams who weren’t equipped to actually deploy the code reliably at the same speed.

So, developers were getting frustrated with how long it was taking for their code to reach production and IT teams were frustrated with their ever-growing backlog of work. There needed to be a process that took some responsibility off the plate of IT and allowed developers to take more accountability for a successful deployment process. This pain between developers and operations teams is when the idea of Agile infrastructure first started to get popular.

Agile infrastructure eventually led to the more holistic concept of DevOps – a way to tighten feedback loops between engineering and IT, continuously test and deploy, automate manual tasks and improve visibility and collaboration across the entire business. While there are numerous articles defining Agile, they almost always omit the operations portion of it. So, we thought we’d lay out the real definition of Agile – including development teams AND IT operations.

The history behind IT operations, ITSM and ITIL

For decades after the original invention of the computer, software was developed for on-premises use only. Then, the rise of personal computers increased the amount of software being built and released to the public, still served via disks for local systems only. But, the internet changed the way developers and IT professionals could deliver their services to end-users.

At first, it took anywhere from six months to a year to build, test and compile the final version of a piece of software. Now, developers can release updates to the production application or service multiple times in one day. Before the internet, there was really only one way to approach IT operations and software engineering – leading to the IT Infrastructure Library (ITIL). ITIL was a set of best practices for IT Service Management (ITSM) to help teams align their IT infrastructure and applications with the rest of the business.

For a long time, ITIL and ITSM principles were the gold standards for building and serving applications and infrastructure to end-users. But, continuous integration and delivery (CI/CD), cloud-based infrastructure and functions, microservices, DevOps and so much more changed how everyone approached software. Soon, organizations all approached their development and deployment pipelines in slightly different ways for different purposes, meaning that one singular set of best practices wouldn’t work for everyone.

Why DevOps Matters

The growth of Agile development practices

Soon, businesses were realizing the faster you could develop and release software could be a competitive differentiator. The more features you could release to end-users, the more value you create between yourself and competitors. So, this hyper-focus on speeding up the development pipeline took over. Iterations of different practices and methodologies led to Agile, which became the standard process for most businesses looking to create faster software engineering teams.

But, as I mentioned earlier, this led to development teams who were actually too productive. There was an abundance of code but there wasn’t any plan for getting this code out to customers quickly and reliably. IT operations teams still had to run tests, configure VMs, networks and servers for deployments – all while keeping up with any current issues in the production environment. So, tightening communication and visibility between developers and IT operations became a key differentiator between highly productive engineering teams and slower ones.

Where Agile meets IT operations

Obviously, instead of slowing down development in order to give IT the time they need, you need to find a way to speed up IT. So, teams started to look at how they can apply Agile practices to IT operations. But, as teams started to dive into this implementation, they found that Agile adoption for IT would look a whole lot different from Agile in software development. Instead of keeping the organizations siloed and applying separate Agile practices to each of their workflows, managers found that building the connection between dev and ops was the most effective approach.

Hence, the rise of DevOps. Agile applies to IT operations is really just the application of a true DevOps mindset. With greater input from IT into the development process and more developer involvement in production upkeep, both parties gain more exposure to the system as a whole. More exposure leads to more workflow transparency and better collaboration – driving faster, more reliable results.

Defining Agile in the context of modern DevOps practices

So, you’ll find the real definition of Agile in today’s world is about much more than a rapid development process. In the context of today’s focus on continuous integration, delivery and testing, a DevOps methodology is the only holistic application of Agile in an engineering organization. IT professionals can test on smaller sections of the codebase throughout the development process and developers can take on-call responsibilities for certain production environments. This way, everyone is accountable for the resilience of the product and ensures more positive customer experiences.

Agile is typically thought of as moving in one direction – forward. But, in DevOps, you need to work on communication and workflows both upstream and downstream in order to create feedback loops that don’t create bottlenecks. In DevOps, it’s crucial to think about project workflows in both directions when trying to create bidirectional “Agile” success. For too long has ops been ignored in the Agile conversation – it’s great to see the growth in DevOps and more attention being paid to speed and reliability across the entire system, not just development.

Check out our recent guide, Why DevOps Matters to learn more about the benefits of DevOps for overall team chemistry, development speed and service reliability.

Let us help you make on-call suck less.

Get Started Now