Introduction
In this rapidly evolving world Enterprise Agility is critical to enabling you to survive and thrive. But what is agility, really? Everyone seems to think they’re agile because they’re doing Agile, but this is not agility. The terms Agile, agile and agility have been applied so randomly and batted around so widely as to have become almost meaningless.
So, what is agility and how is it achieved? For the purposes of this article, let’s agree that it is the ability to transform your enterprise at speed in response to threats and opportunities. Achieving it requires that you can recognize events to which you should respond, decide how to respond and act rapidly. You don’t just fall into agility, though, you need to evolve how you do things with great intentionality to realize it. You need to implement an organization structure and decision-making processes consistent with what it requires.
To begin with, what is the Enterprise? It is your Brand and Reputation, the Products you sell, the Capabilities you employ to create them, the Enablers you leverage that equip you to exercise your capabilities and, ultimately, the financial value of the whole thing. Products, Capabilities, and Enablers are entities I employ in my simplified enterprise architecture model palette. If you run a bakery you might offer cakes, exercise your capabilities to sell, design, produce and deliver them and employ your recipes, bakery staff, mixers and ovens to create the value that you provide to your market.
In this context, what does Transformation mean? Transformation is anything that produces a change in the state of your business as represented in your EA model at a point in time. This would include adding a new product, implementing new capabilities or acquiring new assets or people to enable them. If you purchase a new piece of equipment to increase your capacity to turn out cakes, then you are transforming your bakery.
Transformation must be considered in the context of both independent and dependent variables. Independent variables are the things you control—investments, reorganization or process revisions. Dependent variables are the outcomes that result from changes you make—increases or decreases in costs or market share, for example. You can define, evolve and create Products; write and deliver Branding and marketing messaging; implement and evolve Capabilities and acquire and implement Enablers in support of them. Based on decisions you make and actions you undertake, you transform what the marketplace sees when it looks at you. From your branding, products and services, the world will form an impression of your company and its value proposition, and the financial markets will determine a valuation for it.
So, what is Enterprise Agility? It is the ability to recognize Opportunities and Threats in the marketplace and execute rapid transformation of your current architecture to exploit or defend yourself from them. You transform yourself by changing your messaging, products, capabilities or enablers hoping to improve your brand image, sales, market share and financial valuation.
SWOT and OODA are two paradigms employed to inform your approach to this. SWOT (strengths, weaknesses, opportunities and threats) is a framework for assessing your competitive position in the markets and OODA (observe, orient, decide, act) describes the process of decision-making and transformation. SWOT is about what you should set about doing and OODA is about how you will make decisions along the way. Sharpening your SWOT muscles improves your ability to scrutinize your markets and recognize and identify events to which you should respond. This improves the rapidity with which you can execute the first two stages of the OODA loop and informs your decision-making process. The two frameworks are tightly intertwined.
How is agility measured? Agility can be measured in the end-to-end time required to identify a need for and then achieve a transformation—the right transformation. Clearly, faster is better; however, fast and wrong does not dominate measured and right. Festina lente, (make haste slowly) should apply to all product development initiatives.
The ‘fail fast’ mantra from the early aughts has some validity, but only in circumstances in which your company is intentionally experimenting and prepared to pivot and iterate. In this paradigm, initiatives are small and iterative, limiting what’s at risk. In a traditional project-oriented paradigm with a budget, scope and schedule intended to deliver a final product, failure is failure. It creates a substantial loss which is not offset by the eventual success of a revised initiative.
OKRs (outcomes and key results) is an approach to defining business goals that informs and guides Product Discovery and transformation processes. The OKR discipline is highly nuanced and to employ it properly, you must learn and adopt the thinking behind it. Jeff Gothelf’s Continuous Learning blog is a good place to start. Properly articulated OKRs will set you on the path to identifying product opportunities that are worth pursuing. Lean product discovery processes will create efficiencies that accelerate your identifying them, while saving money and reducing risks.
The notion here is that you cannot assume, ex ante, that you know the details of the product you need to develop to achieve the key results that you believe will allow you to realize your targeted outcomes. It is only by combining market research and customer insights to inform incremental product evolution that you will arrive at the right combination of offering characteristics, features and messaging to solve problems that your customers will pay to have solved. The faster and more parsimoniously you can do this, the more agile, efficient and competitive you will be. This is what will make your product and your company successful.
All this has some profound implications about how you should lead your company and how you should approach the continual process of transformation that is essential to your success.
A Pattern for Decision Processes Within Your Organization
The route from concept to product traverses three layers of decisions:
- Strategy, in which you determine where you should compete and how you can win. Typically, these decisions are made by executive-level management at the corporate or business unit level.
- Business Model (product definition), in which you determine what you should offer to the markets and segments you have targeted. A critical issue is identifying a problem that represents a real opportunity. This, if done correctly, will lead you to a problem-solution fit and then a product-market fit. These decisions are usually the purview of the product management team.
- Execution (delivery), in which you determine how to implement and produce what you will sell. These concerns are addressed by the delivery and development teams.
Now, many companies do not have a formal structure that incorporates the entities and roles as I have identified them. Regardless, the decision train between ideas and products must always make stops at each of these stations, regardless of order and no matter who is making them. It is also not always the case that the train takes the direct route from strategy to product definition to delivery. Agile organizations elicit ideas from each of the three areas and propagate them to the others. Trying to enforce a top-down hierarchy in which strategy always drives the rest of the decision process can obstruct creativity and impair agility. However, the organization must concern itself with coherence. Product ideas that are out of sync with strategy or delivery or operational capabilities that cannot support them impair agility and competitiveness.
Coherence can only come from constructive collaboration and communication between those responsible for adjacent layers in your decision-making architecture. Strategy must be in sync with product management, and product management must, in turn, be in sync with the delivery team. In the course of transforming, new ideas can emanate from any of the layers and ripple across the others. Echoes will reflect back to the originating layer, creating even more potential for change. Imagine dropping a stone in a pool with irregular edges and maybe some objects sticking out above the surface. Waves will reflect in different directions from all of them, be reinforced in some areas and attenuated in others. Actionable decisions, ultimately, are like areas of quiescence that result from the dampening effect of convergence. This is a healthy thing as long as each of the three layers of decision-making are represented in the process. If any of them is not, conjunction between the other two will not avert the potential for inhibiting true convergence and impairing the quality of your decision-making.
Agile organizations encourage and enable this phenomena, change-resistant ones impede it. It’s understandable—accommodating such change, much less inviting it, is a high-cognitive load proposition. It flies in the face of much of what traditional organization design was intended to accomplish, which is minimizing cognitive load to allow a smaller number of senior managers to increase their effective span of control. This was viewed as ‘efficiency’; however, it is often anything but and is anti-agile, to boot.
In the next article, we will look at approaches and techniques for implementing agility in your organization.