DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog Why change deployment frequency results in big gains

Why change deployment frequency results in big gains

One of the 5 key DevOps metrics championed in the annual Google “State of DevOps Report” is “deployment frequency” (for reference the other 4 area change lead time, change failure rate, mean time to restore (MTTR), and availability).

Changing deployment frequency

I was curious about the impact of changing deployment frequency so I ran a little thought experiment – what would the benefits be in terms of delivered value an organisation changed deployment frequency from quarterly to monthly to daily?

This partly draws on the ideas of “marginal gains” championed by cycling coach Dave Brailsford – it’s better to focus on making a 1% gain frequently, than trying to make large gains on a larger time scale. Small gains add up, just like compound interest.

So my experiment was this – one team deploys daily, delivering a 1% increment of value every deployment, the second team batches up their deployments into a 30 day release cycle (of 30% gain, the sum of the daily increments), and the thirds team on a 90 day (quarterly) release cycle (with a 90% improvement). Who is ahead at the end of the year, and by how much?

DevOpsGroup - Deployment Frequency Graph

It’s fairly easy to plug these numbers into Excel starting from a base value of 100 and calculate the result.

  • Team 1 – Daily – has improved their value to 3740
  • Team 2 – Monthly (30 day) – has improved their value to 2329
  • Team 3 – Quarterly (90 day) – has improved their value to only 1303

So in total team 1, by only changing 1 thing – deployment frequency – has outperformed team 2 by 61% and team 3 by 187%.

Whilst this is only hypothetical it does show the mathematical power of small, frequent, incremental delivery of value to customers (one of the core values of Agile software development).

In reality, in order to release daily Team 1 would have had to make other changes which would have had other knock on effects:

  • Their “batch size” has shrunk to a batch size of 1 (compared to the batch size of 30 or 90 for the other teams). The smaller the batch size, the easier it is to test, the easier it is to deploy and the easier it is to roll if back if it fails – so we’d expect change failure rate to go down, lead time to go down, MTTR to go down, and availability to up as a result of more frequent deployments and smaller batch sizes.
  • Given each deployment is an opportunity to learn what our customers actually want and need we’d also expect wasted effort to go down. Many teams spend time building features that the customer doesn’t really want and never use (some estimates are as high as 50% or more of delivered features add no value to the customer and hence are waste). By deploying more frequently, in smaller increments, we avoid batching up large chunks of work that ultimately deliver no value. Remember that unused features are a form of technical debt – they slow you down by forcing you to test pathways that no-one every uses, and forces Ops to support ever more bloated systems which costs time, effort and compute resources.
  • Team morale is likely to go up. People like to feel their work has value and purpose. By putting working software in the hands of their customers on a daily basis the team gets to feel that satisfaction of a job well done EVERY DAY not once a month, once a quarter or in some organisations sadly only once a year.


So, in summary, aiming for a daily release cadence will have all sorts of benefits for your team and organisation… and even if you decide you don’t want to release daily or even multiple times a day, knowing that you CAN, that you have the capability to do so if you wish, is a powerful agent for change and improvement.

Can Cloud and DevOps adoption accelerate growth? Why not download this whitepaper to see how it can help.

Leave a Reply

Your email address will not be published. Required fields are marked *