[=] Equal Experts

Our Thinking

Thu 30th November, 2017

Welcome to the world’s simplest agile maturity model

Agile_Maturity_Model_Header

At Equal Experts we get to work with a large variety of clients and we keep getting asked about agile maturity and our view on what a good model might look like.  

How it looked before

A quick dive into Google brings up a large number of options and most will look something like thisIt’s a matrix that’s useful for determining how mature you are across a number of agile practices and what you can do to progress to the next level.  However, it does also have its flaws: it’s subjective, only offers a partial solution and doesn’t really tell you ‘why’.

To address this, we’ve developed ‘The world’s simplest agile maturity model’.

How our model differs

Under our model agile maturity is measured by how frequently you release new features into production. The underlying assumption is that if you’re working on a complex system, and can deliver new features into production with a low defect rate, on a weekly or daily basis, then you’ve reached a high level of agile maturity.

How it works

Count the number of releases made and how frequently.  It’s that simple.

Agile Maturity Model3

It’s worth noting the scale, as moving from monthly to weekly releases is a big transition.  To get to this point you need to change many more practices and processes than you would going from annual to quarterly.  

We’ve also used the illustration below as a simple way to view multiple projects within an organisation. When you ask product leads in a company that’s only beginning to move to agile to place a post-it note next to the frequency of their product releases, you might get a profile that looks something like this:

Agile Maturity Model4

Over time, as a company moves to agile,  when you repeat the same exercise and get the result below, then the company is making some real progress:

Agile Maturity Model5

Why it works

Any team that reaches the point of releasing multiple times a day must have solved a number of key issues that agile delivery and technical practices attempt to address.

Whilst it won’t be universally true, there are a number of ‘maturity’ indicators contained within a full-blown maturity model that become increasingly likely as you release more frequently.  This is because it’s hard to release frequently without ‘doing the right thing’.  

Examples of agile maturity

  • Zero downtime deployments – i.e. deployment to production without an interruption in service.  It’s unlikely that people would accept multiple downtimes in a day just because you want to release multiple times during the day.  Therefore, it follows that if there are multiple deployments in a day, a team has more than likely developed the capability of performing zero downtime deployments.
  • High levels of automation – pushing through code and configuration changes manually lots of times per day would test the patience of a saint, so the process must be highly automated.
  • Loose coupling – a system’s design and architecture must be loosely coupled to allow small changes that do not have unforeseen impacts on distant parts.  If you have a complex system that’s tightly coupled – good luck getting up to even weekly releases.
  • Quick testing and verifying – the way the system is tested and verified must be quick enough (highly automated) and thorough enough to capture errors at the different levels (unit, integration, infrastructure, configuration etc). Remember – we did qualify releases as having a ‘low defect rate’.
  • Fewer silos – It’s difficult to reduce cycle time below a certain threshold when there are handoffs of work between silos, so organisational or team silos are likely to have been reduced or eliminated.

There are many other examples of increased maturity naturally emerging from the simple act of releasing more often.  Taken together, these start to inform you of your level of agile maturity.  

Overall you can see this is a lightweight model, applicable both when looking at a single product or across a portfolio.  Because it’s simple, it’s never going to be complete – but we find it a good basis to work from that’s easy to measure and understand.