Since the summer, I have worked with several companies that are starting to see continuous deployment on their horizon. This is great progress and brings many advantages such as fast feedback on quality issues in the field as well as the ability to quickly fix any issues that customers experience. Internally, more frequent deployment often triggers a wave of automation of the activities surrounding the release processes.
The realization that escapes many of the companies that I work with is that continuous deployment also allows for some fundamental changes to your development processes. Our research, as well as that by others, shows that somewhere between half and two-thirds of all new features being developed are never used or used so seldomly that the R&D investment in the feature was not justified. And yet, most R&D organizations are steered on cranking out as many features per time unit as possible. That means that the focus is on efficiency, but at the price of building many useless features that might even prove to be harmful as they clutter the system and user interface and result in higher maintenance cost than strictly necessary.
Once a company reaches continuous deployment – which I define as releasing at least once per agile sprint – we can adopt a different development process where we do not build the entire feature top to bottom and including all bells and whistles. Instead, we can afford to build only a slice of a feature, deploy it together with the necessary instrumentation and measure how it performs in practice. If it performs as expected, we can decide to build the next slice. However, in case the data does not match expectations, but we may also decide to cancel the feature or re-implement it in a different way that we hypothesize performs better. This of course focuses the R&D resources on things that actually add value to customers because we have a feedback loop that gives us immediate data on the extent to which we are delivering on customer value.
Most R&D organizations tend to pride themselves on their efficiency rather than their ability to maximize delivered customer value. However, R&D of course expected to deliver value to customers as that’s the only way we have to monetize our products, systems and services. A quick example to illustrate my point is the following. Most companies express R&D budget as a percentage of revenue, say 10%. For an agile team of 5 people using 3 week sprints and on average costing 1K€/day/engineer, this means that a sprint costs around 75K€. Using the aforementioned numbers, this means that this team needs to generate 750K€ in business value in order to justify their investment. In my experience, very few agile teams think in these terms.
Concluding, we need to shift our perspective from efficiency (delivering as many features as possible) to effectiveness (maximizing the amount of business value per unit of time or resource). Continuous deployment and the associated feedback loops allow us to fundamentally change our ways of working in R&D and through that significantly improve the effectiveness of R&D. So, stop focusing on efficiency already and start focusing on effectiveness!