Is DevOps no more than automation?

One big misconception about DevOps is that it is just automation, no other purposes. Nothing is more wrong. Automation is a mean to a very different goal. The purpose of DevOps is to optimize and maximize the value delivered to users through the IT chain of work.

To maximize value, we need to reduce the size of our releases. Each release has less features, but we release more frequently. More frequent releases are less efficient if we manage them manually. You know how it works: open a ticket, get access to the systems, block traffic to the system, install updates, check that it works, reopen the traffic, close the ticket. To release more frequently, we must automate the release process as much as possible.

I have still to explain why smaller releases maximize user value. Let's say we release three features during a quarter. Each feature brings a 10% increase in revenue as we increased the number of paying users attracted by the new features. Clearly a hypothetical situation but it helps to understand. If we consider the entire quarter, for three months there is no increase in revenue (due to the new features) until the day of release at the end of the quarter. The next day, the first of the next quarter, we have a 30% increase. Consider instead releasing one feature each month. We would earn 10% more after the first month; at the end of the second month we get another 10%. So, with a massive release, we get 30% more after the third month. Using smaller releases, we could have a 10% increase during the second month and a 20% during the third. This means that we get the 30% increase a month in advance.

In addition to the direct economic benefit consider the indirect benefits. The first, most evident, is the reduction of risk, either technical or entrepreneurial or both. The technical risk decreases because we change fewer components (at least fewer lines of code) per release. This results in simpler troubleshooting and resolution of problems, faster deployment (potentially), shorter outage duration of (again potentially), and so on. The entrepreneurial risk decreases because we can know earlier, through telemetry or user surveys, if the functionality pleases users. With feedback we can correct the aim, risking only a month of development instead of three. We become able to change priorities each month, each week, even each day, with much less waste than a less-frequent, larger, release with greater interdependencies. Consequently, the commercial risk, of offering something that is not of interest to my users, is reduced because my offer becomes more dynamic, and I can quickly adapt to the competition. The smaller interval between releases, the lesser the risk.

Automation is therefore instrumental to reach the goal of releasing less changes more frequently. If my organisation takes three days to release, it is impossible releasing multiple times a month. It is imperative that my releases fall below four hours threshold overall. At least to start releasing multiple times a month. To release multiple times a week, we must go below 30 minutes.

The above reasoning is based on Lean principles. While traditional management emphasizes efficiency, whereby the size of a work lot is cost-driven and optimized at each stage of processing, the lean approach aims to optimize the final product. I recommend a book as The Goal to familiarize with these ideas.

What do you think? Am I wrong?