Agility and Agile are Brand Names!

In Enterprise Agility, an Attempt to Get to the Bone, I mentioned that agility and agile are not brand names although vendors would like the idea.  Apparently, I was wrong.  I admit the mistake!

When reading all that is being written about agility and agile I can only conclude that I was terribly wrong.  Seemingly the tsunami of marketing indoctrination by vendors and consultants has done its work: Agile and agility have become brand names!

Why am I writing all of this? Just a few (contradictory) statements that I have found:

  • Agile is a method, a production method in fact, of course delivering agility.
  • Agility is an attribute of an organisation or a business unit.
  • Organizations don’t simply become agile. They’re either agile or not.

Once again,  for just a small moment, let’s return to the original meaning of both words:

Agility noun the ability of moving quickly and easily

Agile adjective marked by the ability of moving quickly and easily

As an act of freedom, I broaden “moving” by replacing “moving” with “changing”, as moving is changing and changing is moving, and that word is better suited for what I am interested in:

Agility noun the ability of changing quickly and easily

Agile adjective marked by the ability of changing quickly and easily

First of all,  agile is a marker, or better an attribute, in fact a “quality” attribute associated with and exhibited by “something”, the object being marked.

Agility is neither a binary “present” or “absent”, and agile neither “true” or “false”. It is however better or worse, and that only with a specific purpose in mind.

I don’t read anything of a method, neither a production method.  Consultants have seemingly made many believe that everything agile is about, is their method.  And seemingly that has worked.  Agile is about methods, isn’t it?

No, it isn’t!  Or better, not necessarily. If “something” is the method, or better the method is the object, agile can be an attribute associated with the method.  Can that method be agile?  It depends what the purpose is. For one purpose the method can be agile, for an other it may be not at all.  Enterprise agility is yet an other matter, it is about an other object, and probably an other purpose as well.

I’ll illustrate further with an example:

If someone – a human as object – is wandering across the savanna, to be suddenly surprised by leopards approaching and that someone is able to move quickly and easily so to escape and survive, that someone is agile (marked by the ability) for the purpose of escaping and surviving. The ability could be better or worse. There is a tipping point when worse becomes too bad. With a Land Rover nearby that (s)he could drive, having foreseen the future purpose, (s)he would have been in a superior state of agility than with no means at all.  But there may be even less risky states to be in.  What if (s)he could be beamed up? Wouldn’t that be even a better state to be in? Because, what if the leopards would be able to run faster as the Land Rover could progress?

The state of agility may be good or better aligned with the purpose of escaping leopards. If however the area is abruptly and majorly flooded, the Land Rover may not help at all, and (s)he may drown.  The state of agility may not be aligned with an other purpose, surviving a flood. The more advanced technology solution would still help. Technology doesn’t matter?

Object and purpose!  All that matters is object and purpose!  In fact agility is about the ready ability of an object to timely arrive at a purpose legitimate in a suddenly changing context, here the ability to survive.

With the enterprise as the object that enterprise architects apparently care about:  What is the purpose of the enterprise?

In Re-Creating the Corporation and in even greater detail in On purposeful SystemsRussell L. Ackoff has offered great explanation that systems – and for the purpose of illustration I just accept the abstraction of the enterprise as a system – come in 4 flavors:

System Parts Whole
Deterministic Not purposeful Not Purposeful
Animated Not purposeful Purposeful
Social Purposeful Purposeful
Ecological Purposeful Not purposeful

An IT system is deterministic, having no purpose of its own, neither its parts. A human is animated, having a purpose of his/her own, but for example his/her stomach, being a part, hasn’t. An enterprise is social, having a purpose of its own, and humans, being parts, having as well.

So what is an enterprise’s primary purpose?  Russel L. Ackoff goes to great lengths to explain that social systems have one  primary purpose and that is surprisingly enough survival.  Hence:

If for an enterprise survival matters, in an ever changing context, the ability of changing quickly and easily is essential because, one day, its state of agility may be too bad.

So next question is:  what are events that the enterprise wants to survive?  One cannot have it all.  Choices will need to be made. Next, getting the enterprise in an aligned state to survive, is what increasing enterprise agility is about.

I admit: the prime purpose of surviving may sound abstract in relation with the enterprise. Therefore I really recommend Russell L. Ackoff’s work.

What about this one?

  • It solves world hunger too.

In fact, it may.  If that is the purpose!  Let’s think about the object!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s