If your business is going to survive, you must be able to read and react to changes in your markets and continuously improve your competitive position.  It’s more important now than it’s ever been.

SWOT is a model often employed to characterize a company’s competitive position in terms of Strengths, Weaknesses, Opportunities and Threats.  If a competitor creates a new offering that you can’t match, that’s a weakness.  If you have one that they can’t match, it’s a strength. 

Weaknesses often present themselves as outside-in problems: that is, the threat appears from outside the organization. However, you must respond to them inside-out: that is, you respond to the threat by exercising your capabilities to get new products or services into the market.  But if you are lacking the required capabilities, then your ability to respond is weak.

Strengths are the converse.  If you have superior capabilities, then when you identify an opportunity you can develop new products or services and get them to market, hopefully before your competitors can.  Competitive analysis must always reflect both outside-in and inside-out perspectives.

A model we’ve discussed before is the OODA loop, created by Colonel John Boyd, a pilot who flew during the Korean War.  OODA stands for Observe, Orient, Decide and Act.  The steps it describes are sequential; you must execute each step in the process before going on to the next.  Because of this, to accelerate your response to a stimulus, you must shorten the execution of each step in the loop.  You have to recognize something to alert you to begin to determine whether to respond.  Once that’s happened, you need to understand what you’re seeing.  Then, given your understanding, you need to determine what you should do about it and, finally, you can execute your selected action.

The SWOT and OODA models intertwine nicely.  SWOT is a lens through which you can evaluate your competitive position and identify situations warranting attention and OODA characterizes your ability to evaluate and act on them.

Business Agility is represented mainly within the first three steps of the OODA model; it’s the ability to recognize and decide how to react to threats and opportunities at speed.  Of course, there is no value in knowing what to do without being able to do it.  Digital Agility is the ability to create and refine digital products and services rapidly, and it is largely related to the last OODA step—action.

Culture is a critical foundational element of both forms of agility.  To build and enhance agility, you must recognize the kind of culture your organization needs to have and the capabilities you require to respond to opportunities and threats: Ironically, most “Agile” programs focus obsessively on the “A” in OODA—the acting, or constructing a product.  Yet that is not where agility chiefly arises from.

Not that the acting plays no role in agility—it does.  If you feel you know what product is needed and have the resources arranged to produce it, then you are positioned to act.  I refer to it as Digital because many products today have digital elements or adjuncts and, of course, many products or services are entirely digitally enabled.

Crucially, neither Business Agility nor Digital Agility alone will enhance your competitiveness.  It will do you little good to have superior market insights and excellent tactical skills if you cannot act on them quickly.  Similarly, it won’t buy you much to be able to produce digital products and services rapidly if they are not the right ones.  Effective Business Agility, from perception and ideation to the ability to influence competitive position, is the ultimate goal of companies that adopt Agile and DevOps frameworks or undergo Digital Transformation.  However, while Agile and DevOps may provide Digital Agility, they don’t guarantee Business Agility.

So, where is the disconnect?   Two factors contribute to it.

The first is management that clings to the legacy notion of a project, with fixed deliverables, budgets and schedules, which precludes agility.  Projects are approved and funded with a triple constraint attached.  The politics surrounding them creates inertia and induces resistance to change, which is anti-agile in the extreme.  The critical killer is the up-front commitment to a defined deliverable (an output) as a prerequisite to business decision-makers even considering funding a project.  In previous articles, I’ve spoken about the value of just-in-time design and planning informed by continuously updated information.  The legacy approach eschews all of that, resulting in initiatives designed and planned on information that becomes out-of-date almost immediately. New information is invariably generated during solution development and ignoring it to remain consistent with a project’s approved definition amounts to throwing potentially important knowledge away.  Nothing was ever improved by doing that.

The second is Agile that is not agile.  Companies adopt commercial Agile frameworks hoping to increase flexibility, accelerate solution delivery and decrease development expenses.  Alas, few actually realize these benefits.  Why is this?

Commercial Agile frameworks prescribe processes and ceremonies and don’t address what really drives productivity and agility—how people work and solve problems collaboratively.  Solution development is an event-driven process.  Problems arising and new information emerging are events that teams must respond to immediately.  Agile frameworks herd teams into responding within the structured project ceremonies that they prescribe.  Something that a team should jump on mid-sprint is instead tabled until the next one; time is wasted while an initiative travels down a path that will ultimately have to be retraced and unwound.  If an issue impacts multiple teams, a scaling framework, such as SAFe, only increases the delay.

This results from a risk-averse preference for managing output instead of outcomes.  Why do companies operate this way?  It’s discomfort with change.  It’s much less cognitively taxing to monitor a list of deliverables whose status can be articulated in a sentence or two than to spend time continuously shaping and refining them.

Many managers, whether consciously or not, engineer their operations to minimize the amount of change they must accommodate, often in the name of efficiency.  They are comfortable segregating much of the responsibility for their Agile adoption or Digital Transformation within their technology teams because it doesn’t affect them directly that way.  They can remain a customer, aloof from direct responsibility for the success of the transformation. They don’t see that their approach to product strategy and market development and organization designs that separate their PM resources from the development teams (largely to maintain control over them) constrain agility.  They persist in project thinking when product thinking (outcomes over outputs) is what they really need to do.  It is largely a failure of imagination and nerve.  Many managers are simply unwilling or unable to commit to continuous product refinement or to delegate decision-making authority in the manner that agility requires.

Why do managers act this way?  It’s because this is the way that the senior executives to whom they report manage.  Executives, as we all do, adopt mental shortcuts to counter the cognitive load of juggling too much detail.  It’s inherently easier to form and apply a mental model of outputs than it is to maintain focus on managing the evolution of capabilities.  It’s less taxing to know that you have to get from point A to point B than it is to work out how to increase your ability to travel at an accelerating rate.

Clearly, Business Agility, in the form of new and evolved products, is crucial; but so is Digital Agility, and a business that manages projects instead of products impairs Digital Agility just as much as cookie-cutter application of commercial Agile frameworks do.  Unfortunately, it’s easy to think that by adopting Agile you’re becoming agile, but there’s more to it than that and if you are unwilling to make the kinds of changes required to succeed, you won’t.

In short Business Agility depends on Digital Agility and Digital Agility depends on how your teams collaborate and problem solve as much as how agility is integrated into the context of how you run your business.  You don’t swing a nail gun at a nail as you would a hammer and you shouldn’t apply legacy project management approaches or out-of-the-box commercial Agile frameworks to create and evolve your products.

It’s time for real change.