A while ago I got involved in following little Twitter conversation:
Not only did this little discussion show me the limits of Twitter conversation in making a point, it also provoked some further reflection and an effort to write a post …
Ask a bunch of people what ‘agility’ means and how to get increased agility, and you are likely to find as many explanations as people.
The troubling consequence is that the concept of ‘agility’ is often turned down as being valuable or even worth discussing, and classified under “just another hype”. That is unfortunate as agility is really a fundamental ‘enterprise’ concept that deserves serious attention. But before that can be accomplished, its meaning and the path leading towards ‘increased’ agility should be clear.
In getting to the bone, I am in favor of returning to the original meaning. After all, it is an English word that can be looked up in the dictionary; not a brand name, although some, if it would be theirs, would like the idea.
A look-up in Oxford English Dictionary reveals the following:
able to move quickly and easily
A look-up in Merriam-Webster Dictionary brings forth:
the quality or state of being agile
1. marked by ready ability to move with quick easy grace
2. having a quick resourceful and adaptable character
Agility as a ready ability
The words ‘able’ and ‘ability’ hint, indeed, to competence; the competence to swiftly change even when change is fundamental, with hardly any ripple effects so to speak. Whether that competence is either high or low can eventually mean the difference between succeeding or failing.
The paradox is however that competence naturally is enemy of change. How can that be, you ask?
Ten years ago Seth Godin wrote a classic article “In the Face of Change the Competent are Helpless” about that disturbing fact. I urge anyone to read it.
The reason is that competence is built by factoring out variance, by casting in stone how things should be done over and over, to reach the same quality standards over and over. Once a competence is in place, high impact or abrupt change will destroy it. Naturally, sustained competence can only cope with slow-paced change.
The bitter consequence is that the options for abrupt change in competent enterprises are usually very limited. Any of possible efforts to realize high impact change without destroying competence will simply take too long, will come too late to yield relief:
Agility as a quality or state
Luckily Merriam Webster mentions other words that provide further clues. Agility is the quality or state to be agile, hence indeed not an action.
But the path towards ‘increased’ agility is inevitably full of it. Increased agility asks for reaching a better ‘fit-for-future-purpose’ state by resolving above paradox, thus action. Without action, no reaching.
Resolving the paradox is about transforming the enterprise, moving it into a state in which minimal enterprise structure change, hence non-disturbing change, can result in abrupt high-impact enterprise operation change. In fact configuration options, realizing the quick resourceful and adaptable character, are to be embedded into competences, competences which inevitably become less specific. Once in place, competences can be reconfigured to realign with an evolving environment with the desired results. Let it be clear that the inclusion of the capability of configuration has a profound effect on Architecture and the Remainder of Design:
The action should also be focussed on working on what seems yet another paradox: Agility increases by reducing change options.
In fact much of found change options in enterprises are non-differentiating. It are options that lead to variance and personal judgement and that do not contribute to a well-shaped ‘lean’ enterprise.
The imperative is to determine what change options do not really matter and are in effect counterproductive, to identify inconsistencies between current and possible future states, and with that knowledge in mind, build core competences with embedded configuration options where necessary. Next one can drive efficiency to the extreme after which natural slow-paced non-disturbing evolution is considered sufficient for any of the desired future states. That way possible future states are brought closer in line with current state, even when, being observed from the operational side, they appear fundamentally different.
Fortunately being the easier part, reducing change options is a good start.
From there, strategic choices regarding alternative future states are to be made and needed configuration options to be derived. As those choices are about the future, the act of prediction is never far away. So does agility require predictability? My answer is: Preparation for any change is preparation for no change.
However do not forget about velocity as Seth remarks!