DevOps ROI and how to measure it efficiently Solidify

DevOps ROI and how to measure it efficiently

Published April 26, 2017

When companies <a href="http://solidify.se/why-devops-is-a-necessity-for-software-development/">embrace DevOps</a> they often do so because of a few thoroughly investigated and understood reasons. Working with DevOps creates an overall higher speed of software development as well as contributes to higher quality and better problem solving capabilities. With DevOps comes many clear advantages. Every development department should have Return on Investment (ROI) in mind, regardless of if they’re working with DevOps or not. So why is DevOps ROI so hard to measure? <h2>Unmeasurable and misguiding?</h2> Some consider DevOps ROI to simply be unmeasurable. These people mean that DevOps is not an investment in itself but instead takes form of <a href="http://solidify.se/7-keys-success-with-devops/">various processes and ways of working</a>. With this follows that the number of variables and dependencies in an organization is too many to give a correct and useful result regarding ROI. The other side of the same coin is that ROI can, and should, be measured. In that case, there are a number of mathematical methods – including economical measurements – to reach a profitable result: <ul> <li>Time savings</li> <li>Quality rases</li> <li>Productivity improvements</li> </ul> Let’s take a closer look at these and try to explain how these can lead to a measurable DevOps ROI. <h2>Time savings</h2> One of the best reasons to start working with DevOps is <a href="http://solidify.se/increase-release-frequency/">the increased speed</a>. With DevOps you can faster deliver value in the form of new features, more releases and fast recovery times, which in turn leads to shorter lead times and more opportunities to meet the market. If you make the assumption that sales and income will increase with every release and then gradually drop until the next one (a reasonable assumption), you quickly see the value of an increased number of releases. With a doubled number of releases you can therefore could on almost a doubled income, thereby associate it to the DevOps ROI. Unfortunately, the reality is not so simple. Every release is far from equally profitable and the fact is that not every release is profitable at all. With DevOps you normally work in incremental and small updates that in many cases not directly lead to increased sales but instead aim to meet feedback, fix bugs or other related updates. It’s simply not reasonable to apply this way of counting. At the same time, these are numbers that can be measured. Income is indeed important and can be distributed to products, time periods and other things. By customizing the analysis, you can create a better model for your organization and use it to compare the flow before and after your DevOps initiative. <h2>Quality raises</h2> Another way to measure DevOps ROI is to see the increase in quality and calculate the savings made thanks to this. By breaking down the DevOps investment into the hours saved, you can quickly find a value to use and measure. If you successfully assume a cost per hour for every developer, tester or other coworker as well as a correct number of hours saved, the calculation becomes simple. Such measurements become easy to track over time. They can also be combined with other measurements such as <a href="http://solidify.se/devops-metrics-mean-time-to-recovery-mttr/">Mean Time To Recovery (MTTR)</a> and the number of production failures. <h2>Productivity increase</h2> A third way to calculate DevOps ROI is by looking at the overall productivity and especially any inactive time. Pete Cheslock, senior director of operations and support at <a href="https://www.threatstack.com/">Threat Stack</a>, says that leaders can point to productivity increases as a part of success: <blockquote>IT leaders need to connect the strategic objectives of the business to the work their teams do in order to create a DevOps transformation. If a goal-oriented culture is being achieved, it will lead to more efficient collaboration. The easiest way to measure this is by looking at the number of deployments per day per developer.</blockquote> However, it’s not entirely easy to measure productivity this way. You need to try to measure the efficiency of the development, which can act as a value of cost reduction for every release. <h2>DevOps ROI to think about</h2> There is no doubt that DevOps ROI is a challenge to measure. Change is always tough to measure, especially when it comes to soft values such as collaboration and flexibility. You need to remember that the DevOps concept is still fresh and that developing efficient measurements takes time. In the future, measuring and calculating ROI for DevOps hopefully won’t be necessary. It might even be comparable to measuring ROI of an Internet connection or e-mail.   Have you started measuring your DevOps ROI? What kind of measures do you find being the most efficient? Comment your favourite measurement below!