Towards business agility 2.0

Soon after the introduction of agility in software development, the notion of business agility was introduced as well. The basic idea was to scale the concepts behind agile software development to larger scopes, with the ambition to reach the entire organization, including R&D and IT. In practice, however, for many organizations, it proved difficult to go beyond the software part of the organization and things often got stuck at DevOps. Also, the basic mindset often was to treat changes as disruptions in a steady-state system, focused on returning to a steady state as soon as possible. Agile was concerned with minimizing the impact of changes by rapidly responding to them. The notion of business agility was very popular around 2010 and then started to fade as it didn’t provide the benefit that companies were looking for. To quote a manager in one of the Software Center partners: “We use Safe and say we’re all agile but we didn’t change a thing…”

More recently, we can see a development that’s not entirely dissimilar to the first incarnation of business agility (1.0) but that has a number of unique characteristics and is leading up to a 2.0 version of business agility. This version has, at least, three unique aspects: business models, technology scope and fast feedback loops.

First, many companies have started to realize that agility at the business level starts with the business model that you employ. It has to start with a transition from a transactional to a continuous model. If you build the capability to deliver value to customers but don’t have a way to monetize the continuous value capture, there’s no business incentive at all. If you improve the product, system or offering along some dimension, you need to be able to capture some of that value. For instance, if you run a truck company and you conduct A/B testing on the engines of your customers in the field to improve fuel efficiency, you want to capture some of the savings that your customers are enjoying. Why else would you bother with experimentation in the first place? So, whereas business agility 1.0 started bottom-up with the software development teams, the 2.0 incarnation starts top-down from the business model.

Second, in the embedded-systems industry, there’s a growing awareness that continuous deployment or DevOps doesn’t need to be limited to software. Under the right incentives and business models, it’s entirely feasible to periodically update electronic and mechanical parts of systems in the field to improve system performance. Among others, Tesla offers chip upgrades and hardware retrofits providing significantly improved capabilities, which the software can then use to improve the functionality in the car. So, business agility 2.0 doesn’t just focus on software but extends to electronics and mechanics on the one end and includes data and AI on the other.

Third, the focus in business agility 2.0 is on fast feedback loops across the company and all technologies. This has two aspects. First, each technology has an optimal feedback length where the customer and business benefit of new releases are balanced with the cost of manufacturing, distributing and installing. This of course means that software (including AI models) can afford to have very fast cycles as the cost of distribution and installation is very low and there’s no manufacturing cost. For electronics, especially when keeping the mechanical interface constant (pin configuration, power usage, EMC, and so on), the cost is higher and perhaps a yearly or biannual cycle makes the most sense. Finally, for mechanical parts, the update frequency should be even lower as they’re even more costly to manufacture, distribute and install. Still, when the continuous business model has liberated you from the “let’s save all improvements for the next product” attitude, also improved mechanical parts can be distributed, say, every three to five years.

Business agility 1.0, digitalization and business agility 2.0

The second aspect is that no slower cycle can slow down the faster cycle. Traditionally, the software release frequency was bound to the product release cycle. In business agility 2.0, no faster cycle (software or electronics) can be slowed down by a slower cycle (eg electronics or mechanics).

We’re entering the era of business agility 2.0, which starts from the adoption of a continuous business model and then optimizes the entire company to capitalize on fast feedback loops that allow for all technologies in products to improve at their own pace. Even if your customers aren’t asking for it yet, your suppliers are complaining and your partners aren’t yet ready to play ball, you better get going on this as the second incarnation of business agility provides major benefits, as well as improvements in efficiency and effectiveness that you can’t do without. Go agile, but go 2.0!