Agile & DevOps

Traditionally, even in Agile organisations, development teams and operational teams are two very distinct entities. They have a separate ethos and seemingly opposing motivations. Development teams focus on maximising change, while operational teams focus on stability, resilience, and reducing risk. They are often managed in different departments and have separate budgets, which increases the divide.

Agile Organisations

Author: Véronique Skelsey

If an organisation is to be truly Agile, its development teams need to be flexible, deliver safely at speed, get fast feedback, and iterate. A critical part of this is the ability to develop, integrate, build, deploy and test (at multiple levels) perhaps many times per day. This may happen in various “test and demo” environments before being released to one or more production environments. The processes needed to allow new and enhanced code to go through the myriad of checks and stages to be used in production can be viewed as a delivery pipeline. 

Therefore, its critical development team must be able to make the whole delivery process as quick and simple as possible. Agile delivery is fundamentally based on producing small (and frequent) changes that realise business benefits quickly, gain fast feedback from actual use, and substantially reduce delivery risks.

BUT (and it’s a big BUT…)

Operations thrive on the stability of service and are usually measured on this. From this perspective, any production release is a potential threat. It always carries the risk of failure or at least the possible introduction of bugs and production issues. The Operations department is at the mercy of the quality of the changes introduced by Development. In some organisations there may be strict Service Level Agreements and even complicated internal and external contracts and commercial arrangements, increasing the pressure.

So, it’s no wonder that the Operations side of IT often feels threatened and left to suffer the consequences of the aftermath of production releases!

Risk management

The traditional response to this issue is to exert more control over the delivery process by enforcing quality controls, usually accompanied by demands for lots of documentation. The aim is to ensure the quality of both the delivery increment and the release process - thereby reducing risk.

In fact, these complicated processes give the illusion of risk management whilst adding substantial risk. The difficulties and overheads involved in complicated controls actively discourage small releases. Instead, many releasable items are packaged together into larger releases and often limited to specific regular release windows (say weekly or monthly, and only at times of low usage). But increasing the size of a release usually means increasing the time and effort required, resulting in much larger and more complex releases which are more prone to error and more difficult to debug. Additionally, such releases are very expensive and require many people to be available to support the release, often at unsociable hours. The delay between implementation and deployment also means that developers need to re-familiarse themselves with the code before they can make any fixes. Small and frequent changes carry less risk and are more easily reversed.

In short, the supposed solution is exaggerating the problem and creating a divide between the parties.


DevOps is a great enabler of Agile. In fact, DevOps (Development AND Operations) could be described as the Agile transformation of Operational teams and processes. Tooling and infrastructure support the DevOps approach but DevOps is fundamentally about practices, processes and a new mindset. DevOps breaks down barriers between the disciplines, often referred to as the “Wall of Confusion” - a term popularised by Andrew Clay Schafer (AgileRoots 2009) and Lee Thompson (Dev2Ops Interview).

Avoid the wall of confusion

So how do we break down the ‘Wall of Confusion’? The CALMS model is a popular DevOps framework.

The acronym can be broken down into:

  • Culture (or Collaboration) – foster an operational mindset in the development teams and reduce the need for a separate operations team
  • Automate – increase automation of testing and deployment processes
  • Lean – make everything as simple as possible, avoid hand-offs and remove bottlenecks
  • Measurement – use metrics to measure the performance of the application, of the development pipeline, and the quality of the software 
  • Sharing – a development team takes on operational responsibility to become a cross-functional and multi-functional DevOps team, accountable for the quality of the product (whether that involves writing software and running tests, ensuring deployments are green, implementing monitoring and alerts, or being on-call for incidents). 

From an Operational perspective, DevOps provides more transparency into changes and allows Operations to be an integral part of the whole process. In collaboration with Development and QA, they ensure that both testing and the delivery pipeline are as automated as possible and are designed to reduce the risk of defects making their way into Production. 

Reduced risk

From a Business perspective, the risk is reduced, there are fewer escaped defects, and less time is spent on releases and fixes. Therefore, it becomes easier to forecast when features will be delivered. The increased trust means that rigid controls can be relaxed.

Development teams and training

Development teams are likely to need additional skills, whether through new team members or through significant training, to become an effective DevOps team.

There is a huge range of tooling that can support DevOps, such as:

  • AWS (Cloud Hosting)
  • Azure (Cloud Hosting)
  • Bamboo (CICD Automation)
  • BitBucket (Version Control)
  • Docker (Container Management)
  • GitHub (Version Control)
  • GitLab (CICD Automation)
  • Jenkins (CICD Automation)
  • Kubernetes (Container Management)
  • Selenium (Test Automation)

And a wide range of supporting practices, such as:

  • A/B Testing
  • Blue/Green slots
  • Canary deployment
  • Dark launch
  • Feature flags

In Summary

For DevOps to work, the processes and practices must be supportable, operable, and observable. When DevOps is running optimally and the Business trusts the teams to deploy without issues, continuous integration and continuous deployment (CICD) become possible. This means every change that is committed to the codebase can - if required - be deployed all the way up to the Production environment.

Without DevOps in place, it is difficult to leverage the benefits of Agile development. Agile relies on fast feedback, enabling changes and adjustments or pivoting the direction of a product early and often, when it is easy and inexpensive to do (because making a change when you have 20 lines of code is simpler than when you have 20,000). DevOps allows a team to truly deliver working software to the Production environment as often as necessary.

Ultimately, DevOps is about tearing down walls and focusing on sustainable delivery into a working operation. The DevOps team maintains responsibility for the products and services throughout their lifecycle, rather than delegating it (throwing it over the wall) to Operations after deployment.


Here at Liqueo, we provide organisations with the skills to implement programmes successfully through our flexible workforce model, tailoring solutions for our clients’ strategic goals. We deliver an exceptional, bespoke service to every client via a dynamic and agile framework. If you are interested in how we can help you implement successful programmes or want more information about Agile and DevOps, contact us.

Our use of cookies

We use necessary cookies to make our site work. We'd also like to set analytics cookies that help us make improvements by measuring how you use the site. These will be set only if you accept.

For more detailed information about the cookies we use, see our Cookies page. Cookie Control Link Icon

Necessary cookies

Necessary cookies enable core functionality such as security, network management, and accessibility. You may disable these by changing your browser settings, but this may affect how the website functions.