The Agile Enterprise

Assume with me that the digital world is a world of fast change. Organizations need to excel at responding quickly to those changes—that’s what we call agility or nimbleness. When it comes to technology, we have well-understood ways of increasing agility and making technology delivery processes lean. Organizations worldwide and in all industries are moving to the cloud, adopting agile and DevOps approaches, using flexible software architectures based on microservices, and retiring technical debt that has slowed them down.

But achieving enterprise agility is clearly more than just a technology challenge. For example, when I was the CIO of US Citizenship and Immigration Services (USCIS), I saw that even when we began using agile technology approaches, our actual agility as an enterprise—our business agility—was severely limited by our contracting approaches. In the terms and conditions of our contracts, we were signing away our flexibility. For example, we might contract with a software development firm to deliver against a fixed set of requirements but allow the contract to include punitive terms against us if our requirements ever changed (i.e., if we needed “contract mods”). Or we might sign a contract for a fixed amount of some resource without provisions for increasing or decreasing that amount if circumstances changed.

Falling into this trap is easy because organizations traditionally find it difficult to assign a business value to flexibility. We value higher revenues and lower costs, but anything that cannot be shown to have a direct relationship with these metrics is harder to value—and that is exactly what agility is: an ability to earn revenues or lower costs or risk when something changes unexpectedly. Since agility had no value in our mental model at USCIS, we were happy to negotiate it away. To build a truly agile organization, executives must examine their supplier and customer contracts to see where they inhibit flexibility; any such place represents a risk to the business and an effective reduction in the company’s value.

That’s just contracting—the same applies across all activities of the enterprise. Another area to examine is human resources. We’ve typically hired employees by defining a role, specifying what abilities are necessary for performing that role, and hiring someone with exactly those skills. That makes sense on the face of it, but what if the role changes or we want to use the employee in a different role? By hiring specialists, we reduce agility; someone with generalist skills or an adaptable personality adds value over and above filling a single role—again because we’ve learned to value agility.

By organizing a company into functional silos, we do the same—an employee develops skills only along a predetermined career track rather than be exposed to other parts of the organization. A marketing person develops skills in marketing but not necessarily in sales, operations, or finance. As circumstances change, that employee only has limited use for the company.

Even those companies that are asking employees to return to the office can increase their agility by making sure they have systems and technology in place so that—when necessary—employees can change their work locations easily. The organization can reconfigure itself in whatever way best suits its environment and immediate needs.

For supply chains, how much flexibility do we have in sourcing the materials we need? Are we relying too much on particular suppliers, perhaps because they offer the lowest cost? There is a short-term sense in that, but it reduces our agility when that supplier is suddenly unavailable or unable to produce a new component we need. A supply chain with flexibility, and perhaps even redundancy, adds value by increasing agility.

How about our cash available for investment? Healthy cash flow doesn’t just indicate a healthy company—it is also strategic because the company can use the cash flexibly if it needs to. Cash on hand is an agile asset. And what is our process for making spending decisions? Do we set budgets in stone a year or more in advance with detailed granularity, or do we have a way to reallocate funds or fund newly discovered initiatives? Who can make spending decisions, and will they be available when an unexpected disruption occurs?

Does our data just tell us only what we need to know today, or will it help us make good decisions when circumstances change tomorrow? In a stable environment, we know more or less what data we need and how to make it available. But assuming stability may be a mistake. Instead, a company can think of its data as an asset that supports flexibility and make it available in a way that involves fewer assumptions about what the future holds.

Flexibility might sound like poor governance—we often think governing means controlling the activities of a business by locking in what it will do. That’s a misconception. The governance need today is precisely to govern for agility. Therefore, signing a contract that limits critical flexibility should be forbidden by the governance process. Governance should enforce flexibility but, of course, enforce it in a way that is responsible to the organization’s stakeholders. There is a cost of flexibility that should be balanced against the cost of inflexibility.

Good governance establishes guardrails and mechanisms within which the company can be flexible. Knowing that guardrails are in place, employees can move quickly as circumstances change without the risk of falling out of compliance or triggering a disastrous chain of events. Scenario planning can also be useful since it allows the company to do some of its planning in advance, freeing up employees and leaders to focus on responding when a disruption occurs.

Even if it achieves technical agility, a business must alter its processes to take advantage of that technical flexibility to turn it into true business flexibility. Agile businesses realize that requirements can be flexible and priorities can change; frequent, incremental deliveries reduce risk, and building resilience into their IT systems is essential. If the technologists have an agile way of working that lets them easily change course whenever necessary, but the rest of the business insists on planning huge long-term projects with inflexible requirements, the result is not an agile organization. It’s a clash of incentives.

Making an organization agile is subtle and goes well beyond fostering technical agility. In a predictable environment, such agility has little value. But our environment today is anything but predictable. The more uncertainty we face, the more change we expect, and the more business value there is in nimbleness and flexibility. What are the impediments to true agility in your own organization, and what do you need to change to make your company future-ready?

Mark

(originally published on the Amazon Enterprise Strategy blog)