Business agility is nearly universally acknowledged to be a prime goal for companies looking to make themselves sustainable in the VUCA world in which we currently operate. Achieving it requires a journey of transformation and continual evolution. The evolution of your company can be conceptually modeled in similar terms to physical motion. In making changes, you get to a new place. If it involves incremental improvements, it may be viewed as being near and if it is a substantial transformation, far. Implementing change requires time and results in displacement, dimensions that describe velocity. Once we become preoccupied with velocity, we also begin to focus on acceleration—increasing the speed with which we are able to get things done. Now we are beginning to address agility, but there is another factor to consider—it is called jerk.
Velocity measures how fast your location is changing, acceleration describes how fast your velocity is changing and jerk measures how fast your acceleration is changing. Differential calculus describes the relationships between these three things in terms of derivatives. Velocity is the first derivative of change in location, acceleration is the second derivative and jerk is the third. (There are any number of additional derivatives, each with its own ‘cute’ name, such as ‘crackle’ and ‘pop,’ but these three are enough for now.)
Velocity is a fraught term in agile development. Scrumists use it to describe the number of story points a team completes within a sprint. Critics of using this to measure the productivity of a development team, and I am one among many, disdain making velocity a key performance indicator as it can be misleading and counterproductive. Yes, a team cannot produce value without output, but it can (and often does) produce output without value and perseverating on it leads to false agility. You get nowhere but do it quickly.
For the purpose of this article, I will use velocity to mean the rate at which a company can transform its value proposition and product offerings, enabled partially by its ability to develop or evolve digital things. Increasing the velocity of value creation can only result from combining a flexible approach to how the business is run—business agility—with the ability to create and evolve digital enablers rapidly—digital agility. As I’ve said before, if you wrap something that is agile, say, digital development, in something that is not agile, say, traditional project management practices, the end result is not agile.
It’s reasonable to assume that if your company employs a standardized development methodology, it will be able to build or evolve things at a reasonably constant and predictable rate. This makes traditional project managers happy but doesn’t necessarily do much to enable the company to maintain or improve its competitive position when the markets in which it operates are changing so rapidly. You must look at your enterprise as a system in which ideas are generated, experimented on, evaluated and matured into product or service offerings, or determined to be not viable or feasible and discarded.
Adopting agile development techniques may increase your development velocity until you reach the natural limitations of your people’s knowledge, your adopted approach, the technology you employ and the processes you execute. You need to look further than that if you want to realize the benefits of new business and operating models, transformation methods and technologies.
So, the first derivative—velocity—is applied by many Agile thinkers to only one part of the system that determines your ability to create value—your ability to develop and evolve digital assets—but not the other—your ability to evolve your business and operating models. Your first challenge is to change your thinking about velocity to focus on measures that reflect the performance of the entire system: outcomes. When you do that, you stop asking questions like “have we finished building the product we were working on?” and start asking questions like “are we shortening our life cycle from ideas to products?” or “are we getting better at identifying winners and losers earlier in the process?” This is where you begin to focus on the second derivative—acceleration.
You can adopt an Agile framework and DevOps to accelerate your ability to implement digitally-enabled products, but without the willingness to change how you operate—business agility—it is only a measure of output, not the outcomes that can create value for you and your customers. It’s something agile wrapped in something that isn’t.
The organizational skills and technical capabilities you must develop to achieve business acceleration all relate to change. You must be flexible and your organization malleable in order to read, react and respond to the market. As Darwin said in Origin of Species:
“It is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment in which it finds itself.”
What this implies to me is that you can’t survive by focusing merely on velocity, you must remake yourself to mature your transformation capabilities in order to improve your ability to accelerate your responses to a changing environment. This correlates well with a common Agile tenet—continuous improvement. When applied at this level, we are talking about the rate of change of your rate of change—jerk, the third derivative. So, if you aspire to make your enterprise more competitive and sustainable, you must reimagine your company as a holistic system and focus on increasing your velocity, acceleration and jerk. You have to minimize the cycle time from ideas to products, equip your organization to remake itself to exploit new ideas and ways of doing things as they emerge and maintain scrutiny on how you can change thinking in order to accelerate your ability to accelerate your ability to deliver competitive outcomes.