Business Agility (#2)

This is our second essay on Business Agility. See here for the first.

Background

In my opinion, "Agile" needs to be re-envisioned.

In some parts, this is like trying to rekindle the romance again in a 20-year marriage. That is, a classic problem.

In another way, I think "Agile" was mainly seen as a techie thing, and the Agilistas did not pull in "the Business side" nearly enough.

The Business side (and even their customers) want many things. Agile is useful still to address lots of these wants (although we need to understand and explain it better).

One thing the Business side wants is "Business Agility." Yes, it is a buzzword, but I think the basic need is really there, and growing! We can work with this, if we think it through more carefully. And Agile offers significant help for Business Agility.

There are other factors affecting "Agile", but let's stick to Business Agility for today.

We need to think through how Agile and Business Agility are connected. This essay is a start.

Introduction

This phrase, Business Agility, is not well defined.

I am about to give you my definition.

Premise: We always want more business success and to reduce the risk of business failure.

Definition: Business Agility is the ability (a) to identify changes, (b) to evaluate their potential impact and the possible adaptations, (c) to select and implement well these adaptations, and then (d) to establish a feedback loop that tells us whether we are becoming more successful at business agility.

That is, business agility gives us outcomes:

• more business success (or at least less negative business impact from the change than we expected or than our competitors)
• somewhat reduced risk

Risk

Risk is a hard or tricky concept. Yes, the idea that adaptations can reduce risk is commonplace. The idea that businesses regularly take some risk, and that is the REASON that their profitability is high -- that is also a commonplace. The idea that reducing risk is good, so long as there is no reduction in profitability - again, a commonplace.

The problem is, retrospectively, how do you judge whether your Business Agility reduced risk appropriately? That is a harder topic. Let's leave that for later.

The Four Parts

Identify

The first thing is to identify changes (that are relevant to us). This really includes some rough selection that separates (hopefully correctly) meaningless changes from meaningful changes. At least, meaningful to our organization.

And these changes can come from a known field or domain (eg, battery science or politics or international relations or disease) or from an unknown field or domain (Ex: I think AI was an essentially "unknown" domain for lots of businesses who are only now waking up to its potential impact of their business.)

Evaluate

There are too many changes happening "out there" (which includes, by the way, inside your organization).

So we must evaluate and prioritize.

Commonly in this evaluation we look at both the IMPACT of the change and the LIKELIHOOD of that impact occuring.

We must also identify and evaluate a range of actions or adaptations we might take.

Select and Implement

Then, we must prioritize those actions that (we think) will give us the biggest ROI. (Yes, more complex than this, but let's simplify for now.) And decide. That is to select one to work on today. (For our simple model today, let's assume the "actor", a person or Team maybe, can only work on one thing at a time.)

And then implement those actions well. Our bias is that a well-implemented action will be notably more beneficial than an "average" implementation.

In general, organizations are using agile teams for some of the implementation. To get speed and faster feedback.

Feedback

Anyone who knows the famous Deming cycle (Plan-Do-Check-Act) will be unsurprised that we want to get feedback.

Feedback about what?

First, and probably most obviously, feedback about how successful our chosen and implemented adaptation was (to the change that we were trying to adapt against). Do we get this feedback well and use it well?

Second, we want feedback on the end-to-end process. If you like my words, on the Identify, Evaluate, Select/Implement, and Feedback steps (yes, even including the Feedback step itself). Do we do this well?

Where are we?

Does the community have a common definition of Business Agility? Well, mostly no. It is not nearly understood and common enough for a good discussion.

Have we taken "Business Agility" one step down to actionable steps? No, I think in general we have not. I just proposed some steps. Others may have proposed better ones. But these steps are not well-understood and agreed. And really, this must be agreed for each organization, in its own context. With specific examples.

Have the Business people and the Agile people agreed on Agile's role in Business Agility? No, not nearly well enough. Surely some people have had a good discussion about this. I think largely people are not discussing it, because no one feels like they know where to start. (Many detailed reasons for this.) But, start the conversation we MUST.

Conclusion

Let's conclude this essay for today.

"Responding to change" is important. Notably more important today than in 2001. (Some will recognize that phrase from the Agile Manifesto (2001).

I think Business Agility is quite important. But not well understood.

Agile (as we know and love it today) definitely has a big role in helping organizations attain a higher level of business agility.

Equally, "Agile Teams" by themselves cannot "take care of" business agility. Many other changes are needed to build robust business agility into an organization.

Well, I jumped ahead. I did not justify my assertions here, but I hope you can start to see how the earlier discussion about "what is business agility" sets up a discussion about "what do we do and how does agile fit in."

Unlike others in agile, Joe has a CST and an MBA. A more holistic perspective on the uses and benefits of agile. Happy to help you if we can.