A New Way to Measure Application Release and Continuous Delivery Efficiency

Think about this. Inventory is risk. Companies purchase inventory; they convert cash into inventory. The risk is that they would buy too little or too much. When one buys too much inventory, it usually must be sold for less, sometimes at a loss. That impacts the bottom line. If you buy too little, you leave money on the table and do not capture all the revenue you could have. That impacts your top line.

Now consider this. Today, all companies are software companies. Marc Andreesen described it in 2011 and it has become even truer today. Just as companies with inventory focus on how to quickly convert inventory back to cash, they also need to focus on how quickly they convert application releases back to cash by continuously delivering application releases.

Very infrequently do companies get inventory management exactly right. In effort to do so, Dell had a very novel concept for manufacturing computers that lead them to be a leader in the PC industry. During the 90’s when companies would sell computers at stores, they would have to make the PCs ahead of time and ship them to the store. If they were wrong on the number they would sell, it cost them a large amount of profit.

Dell wanted to remove that risk. Instead of making a computer and selling it in 3 to 6 months, they would wait until a customer would configure and purchase the computer via phone. Once they received the order and took the customers money, Dell would start to build the computer. But, computers are made of parts: hard drives, mother boards, CPUs, RAM, and more. Dell would have their vendors store these components in trailers, on Dell property, and would take possession after the order. Dell had no inventory. In a sense, the were continuously delivering their product to customers.

This efficiency of their operations made their Cash Conversion Cycle (CCC) the envy of the entire business world. The CCC measures the amount of time it takes to convert resources (inventory) into cash. Dell’s CCC was negative. As a result, last year Dell purchased EMC and other PC from the 90s manufacturers no longer exist.

The CCC metric is calculated as:

DIO is “Days Inventory Outstanding” or the amount of days it takes to sell the entire inventory. DSO is “Days Sales Outstanding” or the amount of days it takes to collect the money from the sale. Finally, DPO is “Days Payable Outstanding” or the amount of days the company has to pay their bills.

So, for Dell, their DIO was 0, zero, because they had no inventory. DSO was actually negative because they collected the money before they even build the computer and shipped in say, two weeks. The DPO was negotiated, so let’s say that was 30 days before they had to be pay Intel after taking a CPU off the truck.

Thus, Dell’s CCC in this example was -44. Negative cycles aren’t odd, Southwest’s was -14 in 2014. They sell a ticket before the customers takes a trip, after all. But to have a negative CCC when you actually make a thing was revolutionary.

The CCC is a key metric to see how companies are handling inventory. If CCC increases in the short-term, it may indicate that collecting money is becoming more difficult from customers (economic slowdown?) or that inventory is sitting on the shelf longer (bad product decisions?). We need the same type of metric to help us maximize our technology investments.

When we make a purchase of technology, say a new Application Release Automation platform to provide Continuous Delivery, we need to know that it truly did improve our company. By focusing on what software really represents, cash, we can evaluate our company with a metric that is truly quantitative.

We need a CCC to represent application releases. I propose the following:

DDO (Days Development Outstanding) represents the number of days a release is spent in development. If your Sprint is two weeks, this number would be 14. DRO (Days Release Outstanding) is the number of days it takes for the release to move into the next environment in the application development lifecycle cycle. So, from final check-in in development, to build, to being in, say the test environment, is the DRO. DEO (Days in Environment Outstanding) is the number of days at that specific environment. In this example, it’s Test, so this represents how long we test the application.

Now, you really should NOT be looking to decrease your application development time, or DDO. Become more efficient with your development by measuring velocity based on story points and seek to drive that number up. We would expect that number to stay static.

Nor should you seek to decrease your testing time, or DEO. You should attempt to have increased code coverage, automated testing, and the like. However, if there are wait states where you just park an application release in an environment due to downstream environments being in use, you can decrease your DEO.

Where you should focus to drive delays out is in the time an application release takes to complete, or DRO. For example, if you have a manual part of your release, that entire time, from release started to release accepted in the target environment, needs to be represented in the DRO. Thus, if you request a database change via a ticket and attach the SQL, the entire amount of time that takes should be in the DRO. An easy way to identify that is to look at the entire flow of your application release process. Then, assign time to each stage. Finally, add those numbers up. I find it very useful to also assign a percentage of the entire time to each stage. This helps you identify your biggest bottleneck in the process so that you can focus on the step that impacts the entire release process the most.

Of course, this version of the Application CCC is only from Dev to Test. What about the production push and previous environments?

We can further

Much like my first-year calculus teacher, I will leave it as an exercise for the class to abstract this out like so:

Where n equals your pre-production environments.

Just like a company that sells a physical good who isn’t done until they sell all their inventory, collect the money, and pay the vendor, you’re not done until the application gets to production.

When you can see the components of the CCC, it’s clear as day what knobs are available to increase your cash delivery. You can shorten your application development time, the amount of time you test, and the amount of time you spend releasing applications. Considering that development and test time directly relate to the quality of your application, your best course to improve is shortening the amount of time it takes to actually release the application. Bottom-line: if that number is not approaching zero, you are going to fail as a company because your competitors certainly are getting that number down.

Much like a company that strives to shorten their cash conversion cycle with respect to inventory, you need to do the same: lower your cash conversion cycle with respect to applications. But, not all efforts are equal. Thus, by having a universal metric across your application release lifecycle, you can evaluate your technology investments and make certain you maximize their return.

To learn more about optimizing application release automation read our white paper, The Evolution of Application Release Automation.