Risk is Lack of Agility

In an earlier post, I talked about how risk decisions are often compromised by the status quo bias. In this post, I would like to present an alternative way to think about risk—a way that fits well with today’s business practices. To be precise, I want to try to demonstrate that risk in a business is more or less proportional to lack of agility. I realize that this may seem like an extreme claim. But I believe that once you overcome the status quo bias, the truth of this principle becomes more and more evident.

First, let me give a few quick definitions. Agility means the ability to change course when it makes sense to do so; we find out when it makes sense to do so by learning and by observing changes in our environment. In the IT world, this is usually framed as the ability to “inspect and adapt,” and there are a variety of IT frameworks for systematizing a manner to do so. In the context of delivering IT capabilities, one important factor in agility is the organization’s ability to shorten lead times, and the best techniques we know for doing so today go under the name of DevOps. It is hard to change course when you are in the middle of doing a lot of things at once; shortening lead times, on the other hand, lets you finish things, get feedback and adjust, and move on to the next thing.

So let’s work with this definition: agility is the ability to respond to learning and changing circumstances, quickly and inexpensively, and is facilitated by rapid delivery cycles and feedback from the market.

Good—now back to risk. Risk is the possible negative consequences of the uncertain future. And we know that the future is quite uncertain, especially in the digital world. Startups suddenly arise and disrupt industries. Customers are fickle and change their tastes quickly, sometimes in the process just of reading a short tweet. Countries Brexit and dismiss treaties they have previously signed. Regulations are put in place and then rolled back. And technology changes in nanoseconds—when you leave the room your programmers begin studying a new programming language like Kotlin and when you come back they’ve already rewritten your systems. The business environment is uncertain and unstable.

Uncertainty, however, does not always lead to negative consequences—on the contrary, it also opens up opportunities. When an unforeseen event happens, what determines whether it is an opportunity or a loss? You guessed it…agility.

Let’s say that you spend $10 million to build a factory to produce bobble-head dolls of Sir Isaac Newton, everyone’s favorite scientist. Suddenly Albert Einstein announces some Theory of Relativity and the market for Isaac Newton bobble heads immediately dries up. Is your $10 million investment down the proverbial black hole?

Yes, if your factory can only produce Queen-Anne-era Cantabrigian scientist dolls [1]. But if your factory is agile enough to quickly and cheaply re-tool and begin producing Albert Einstein dolls, then it will become worth even more, because you will be the first bobble head vendor to enter the Relativity Market. In other words, when you first built your factory building it to be agile would have lowered your risk: you would have been able to deal with changes that took place in the uncertain future. Your expected loss would have gone from $10 million at a particular percentage to much lower (the cost of re-tooling) at that same percentage.

Given an uncertain future, anything that increases your cost of change increases your risk. Anything that decreases the former decreases the latter. Agility is the practice of “building in” the ability to change quickly and inexpensively.

In an IT organization, there are practices that help you build agility and thereby decrease risk. Among them are organizing around empowered small teams, using Agile or Lean frameworks like Scrum or Kanban, implementing a DevOps approach, architecting around microservices, reducing the amount of technical debt (qualities of the code that resist change), and creating automated guardrails to maintain security and compliance while moving quickly. Most importantly, there is the cloud. The cloud not only makes these other practices practical but provides agility on its own. Infrastructure can be provisioned in minutes instead of months, and de-provisioned or changed just as quickly. New markets can be reached cost-effectively and quickly through the cloud’s global reach. And building blocks are available as high-level services that can quickly be accessed and used to help you change course.

Does this notion of risk encompass all of the types of risk that we normally think of as inherent to a business? I think with a few tweaks it does.

For example, there are certain types of risks that—while they still result from the uncertainty of the future—are partially under our control, as opposed to the risk of Einstein discovering relativity.

One of those is the risk of mistakes or malicious behavior from people within or outside the enterprise. We usually address this risk through security controls and quality controls. Does agility also mitigate this risk? I think the answer is yes, both because of what it means to be agile and because of some of the specific techniques we use to facilitate agility. The threat landscape is constantly changing, and security controls must change along with it. When a vulnerability is found (as they constantly are), it is the speed with which the company can deal with it that determines its risk. When an attack is in progress, or when suspicious behavior is detected, it is agility that frustrates it or reduces its impact. One of the biggest sources of vulnerabilities today is that companies do not patch their third-party software often enough or quickly enough after the vendor releases a fix. We do not patch often enough because we are afraid we might break something; we are afraid because we haven’t set ourselves up for agility.

Another type of risk we have traditionally concerned ourselves with is project risk—the risk of a project not delivering the planned scope on the planned schedule and at the planned budget. I would propose that this has been meant as a proxy for a different risk, which was more difficult to measure. The true risk is (and always was) that the investment in that project would not be justified by the results, given all of the uncertainties of managing and executing a complex project, generally with many dependencies. Again, agility is a mitigator. An agile project delivers quickly, in small increments, and then gets feedback on whether it is actually achieving the intended business purpose of the objective. If it is not meeting that purpose, then changes can be made or the project halted without committing further resources. The point is to set the organization up to learn and change plans based on that learning. With an uncertain future, we cannot be sure that our project will have the results we want or will cost what we believe it will cost.

There is business value in reducing risk. This suggests that building agility into our technical practices and technical architectures, the skills that our employees have, and the way we manage and oversee investments is adding business value. The converse is true as well; any action we take that reduces agility carries risk. The amount of risk depends on the amount of non-agility—the degree to which our actions limit our future choices.

Why do we often build things in a way that limits our agility? One reason is that we think the cost of building in agility is high. There is good news on that front: in a cloud-enabled, software-dominated world, the cost of agility is actually quite low. A second reason might simply be the status quo bias. Agility is the ability to change. But who wants change? We’re fine just the way we are.

–Mark
@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value

[1] I realized as I was writing this that I need some help from my readers who are historians. What is the proper adjective for the Queen Anne era? Annian? (like Victorian, Elizabethan, and Edwardian?). Please let me know!