{"id":5051,"date":"2017-11-30T11:37:04","date_gmt":"2017-11-30T11:37:04","guid":{"rendered":"https:\/\/ee.yelkdev.site\/?p=5051"},"modified":"2023-09-25T16:14:37","modified_gmt":"2023-09-25T15:14:37","slug":"welcome-to-the-worlds-simplest-agile-maturity-model","status":"publish","type":"post","link":"https:\/\/www.equalexperts.com\/blog\/our-thinking\/welcome-to-the-worlds-simplest-agile-maturity-model\/","title":{"rendered":"Welcome to the world’s simplest agile maturity model"},"content":{"rendered":"

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. \u00a0<\/span><\/p>\n

How it looked before<\/b><\/span><\/h3>\n

A quick dive into Google brings up a large number of options and most will look something like this<\/a>.\u00a0<\/span>It’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. \u00a0However, it does also have its flaws: it\u2019s subjective, only offers a partial solution and doesn\u2019t really tell you \u2018why\u2019.<\/span><\/p>\n

To address this, we\u2019ve developed \u2018The world\u2019s simplest agile maturity model\u2019. <\/span><\/p>\n

How our model differs<\/b><\/span><\/h3>\n

Under our model agile maturity is measured by how frequently you release new features into production. The underlying assumption is that if you\u2019re 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\u2019ve reached a high level of agile maturity.<\/span><\/p>\n

How it works <\/b><\/span><\/h3>\n

Count the number of releases made and how frequently. \u00a0It\u2019s that simple.<\/span><\/p>\n\"Agile\n

It’s worth noting the scale, as moving from monthly to weekly releases is a big transition. \u00a0To get to this point you need to change many more practices and processes than you would going from annual to quarterly. \u00a0<\/span><\/p>\n

We\u2019ve 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\u2019s 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:<\/span><\/p>\n\"Agile\n

Over time, as a company moves to agile, \u00a0when you repeat the same exercise and get the result below, then the company is making some real progress:<\/span><\/p>\n\"Agile\n

Why it works<\/b><\/span><\/h3>\n

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. <\/span><\/p>\n

Whilst it won\u2019t be universally true, there are a number of \u2018maturity\u2019 indicators contained within a full-blown maturity model that become increasingly likely as you release more frequently. \u00a0This is because it\u2019s hard to release frequently without \u2018doing the right thing\u2019. \u00a0<\/span><\/p>\n

Examples of agile maturity<\/b><\/span><\/h3>\n
    \n
  • <\/b>Zero downtime deployments \u2013<\/b>\u00a0i.e. deployment to production without an interruption in service. \u00a0It\u2019s unlikely that people would accept multiple downtimes in a day just because you want to release multiple times during the day. \u00a0Therefore, 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.
    \n<\/span><\/li>\n
  • <\/b>High levels of automation \u2013<\/b>\u00a0pushing 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.
    \n<\/span><\/li>\n
  • <\/b>Loose coupling<\/b>\u00a0\u2013 a system\u2019s design and architecture must be loosely coupled to allow small changes that do not have unforeseen impacts on distant parts. \u00a0If you have a complex system that\u2019s tightly coupled – good luck getting up to even weekly releases.
    \n<\/span><\/li>\n
  • <\/b>Quick testing and verifying \u2013<\/b>\u00a0the 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 \u2018low defect rate\u2019.
    \n<\/span><\/li>\n
  • <\/b>Fewer silos \u2013<\/b>\u00a0It\u2019s 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.
    \n<\/span><\/li>\n<\/ul>\n

    There are many other examples of increased maturity naturally emerging from the simple act of releasing more often. \u00a0Taken together, these start to inform you of your level of agile maturity. \u00a0<\/span><\/p>\n

    Overall you can see this is a lightweight model, applicable both when looking at a single product or across a portfolio. \u00a0Because it\u2019s simple, it\u2019s never going to be complete – but we find it a good basis to work from that\u2019s easy to measure and understand. \u00a0<\/span><\/p>\n

    Contact us!\u00a0<\/b><\/h2>\n

    We hope you find this article useful. If you\u2019d like help in building your team’s agile maturity, or you simply want us to share our experience with you, get in touch in the form below.<\/p>\n\n\t\t\t\t\t\t