The quest for the agile enterprise
The Xpragmatic View #51
November 2002
by Marc Buyens, Xpragma
Download as PDF-file ![]()
Over the past couple of years, business agility has become one of the more interesting new paradigms of the Internet economy. Unfortunately, it remains a very hyped subject with very little practical applications. The IT vendors are claiming to bring us the solutions that will enable the agile enterprise, but is business agility really something you can buy and install?
Business agility
As we write November 2002, the expression "business agility" has become common business terminology. Searching the web for the combination of these two words will give you several thousands of hits, most of them (at least within the first couple of hundreds) from sites that have some linkage with the IT sector. A wide variety of companies such as IBM, Microsoft, HP, SUN and a bunch of smaller "innovative" IT vendors, they all can offer you the solution that will enable the agile enterprise.
But what do we really mean when we talk about "business agility"? What does it give you? How can you get it? These are much more difficult questions to answer. Of course, we all know that business agility has something to do with reacting to business change and a widely used definition therefore is:
Business agility is an organisation's ability to rapidly respond to changing business or market conditions
Some will argue that this definition is incomplete and that we have to limit the scope to "unexpected" changes in the business environment, this in order to make a clear distinction between business agility and other approaches such as "agile manufacturing". Indeed, also these types of approaches try to address the challenge of business change, but they do so in a much more limited and more predefined context of change.
As always, a generally accepted definition will only emerge once the problem has been solved, but this is not where we are today. Anyway, this type of definition does not give us much more than some "post mortem" information. It does tell us something about what it will give you (the ability to respond), but it does not give us any clue as to how this ability is visible before the change occurs. How can we identify whether our organisation is agile today or how can we increase our business agility?
The look inside
Therefore, the present Xpragmatic View is a first small step in a quest for the fundamentals of business agility. In other words: we try to discover what type of organisational form, what type of infrastructure, what type of leadership, etc. have to be present in order to be(come) an agile enterprise.
Some of the ideas that we will present hereafter are rather controversial. They might question some of the more established theories and practices. For some of these ideas, we do not yet have formulated our own final opinion. We somewhere have the feeling that these ideas are important, but we cannot yet delimit their exact scope and importance. Therefore, this is more the type of reading for the researcher and the explorer, the individual who is not looking for the ready-made answer, but is willing to participate in the thinking process and who is willing to question and challenge whatever existing theory.
As a start, we bring a couple of reflections that are based upon some theories that were recently published. Some of this research work is not really focusing on business agility, but on other business practices. Anyway, what we present here are only a couple of examples and are not necessarily a representative sample of today's thinking about business agility.
The agile virtual enterprise

The agile virtual enterprise
Cases, metrics, tools
H.T. Goranson
A first example is "The agile virtual enterprise", authored by H.T. Goranson.
Goranson was involved as a researcher in a number of research projects for the US Department of Defence. In this book, Goranson presents an overview of the outcome of a research project for what he calls an AVE (Agile Virtual Enterprise).
In defence projects, the scope of the development of a new "product" has grown to such level of magnitude, complexity, cost, time span, etc. that it mandates the collaboration of a large group of enterprises. This again, increases the level of complexity of the project. Additionally, today's technological evolution is such that the technology used for the final product typically doesn't exist at the beginning of the project. Enough complexity and uncertainty to give it some solid thinking.
In this View, we cannot go into the details of the results of this research project. For our current needs, it is enough to know Goranson's definition of a VE (Virtual Enterprise; an AVE is the "agile" version of such virtual enterprise):
A virtual enterprise is a temporary aggregation of core competencies and associated resources collaborating to address a specific situation, presumed to be a business opportunity.
Thereby, it is important to understand that this collaboration only exists in the context and for the duration of a specific business opportunity. Participating organisations or their roles might also change during the project. There is no guarantee or need that the individual strategies of all organisations involved share a same goal. Neither is there a guarantee that this same group of organisations will ever again collaborate.
For our current thinking about the fundamentals of business agility, this gives us an interesting insight: it might be so that agility can be (must be?) achieved by limiting the need for change at the level of the individual actors in the game.
Indeed, in this example of the AVE, we do have a number of actors (read: complete organisations) who, in the context of a given market change (read: the need for a new type of defence "product") collaborate in order to achieve a common business goal. To a large extent, the need for "change" is being addressed by the set-up of a specific collaboration, NOT by the change of the individual actors. Every individual company continues to address challenges that are aligned with its own business strategy, but that, in this given instance, also address the needs of the AVE.
If we replace the concept of the AVE by an IT integration infrastructure and the individual companies by "components" that plug into this architecture, we get the IT-equivalent of an AVE. So, there might be some value in the statements of the IT vendors regarding business agility, although...
Good to great

Good to great
Why some companies make the leap and others don't
Jim Collins
Another source where we found some interesting ideas is the book "Good to great" written by Jim Collins.
Jim Collins' research did not specifically focus on aspects of agility. Instead, it was more a general search for good business practices. More specifically, Collins wanted to answer the question: "Why do some companies succeed much better than their direct competitors, even when their initial starting positions are nearly identical?"
Of course, you can argue that such "ability to do better" does not necessarily have anything to do with business agility. Correct thinking. However, if we accept the idea that business agility is of great value to an organisation, it is very likely that those companies who were able to excel in the past, also did master the necessary level of agility. Indeed, Collins examined organisations that, over a period of 15 years, continuously outperformed the market by a factor of three. It is hardly conceivable that these companies were able to achieve this growth without having to face a fair amount of change and the book gives ample examples of such radical change.
Again, we cannot go into the details of this work, but we merely pick a couple of interesting statements:
Technology and technology-driven change has virtually nothing to do with igniting a transformation from good to great. Technology can accelerate a transformation, but technology cannot cause a transformation.
The good-to-great companies paid scant attention to managing change, motivating people, or creating alignment. Under the right conditions, the problems of commitment, alignment, motivation, and change largely melt away.
The first statement isn't of course a big surprise and has already been discussed in one of our previous Xpragmatic Views. Nevertheless, it is strangely in conflict with the claims of the IT vendors regarding business agility.
The second statement is much more intriguing in the context of our thinking. What is said here is that these great companies (who had their fair amount of change) did not have specific problems with the change that was needed. What needed to be done was done and apparently this happened more or less without any special action.
Of course, this does not yet tell us what the wording "Under the right conditions..." exactly means. Nevertheless, it might give us the insight that business agility has little to do with large change management projects, but much more with organisational forms and business cultures that limit the negative aspects that are often associated with change.
Some early conclusions
Although these ideas do not yet give us a valid basis for conclusions, they do invite us to some more freewheeling. Does this mean that we do not need a change management discipline? Does this mean that, by definition, any company that has change management projects running is not an agile enterprise?
Intriguing thoughts, but as said, it is still too early for conclusions. Nevertheless, while planning for new change projects, it might be worthwhile to review the goals for these projects. Instead of aiming for the new and better "stable state", we might prefer to work towards an organisational form and business culture that does not really require a "stable state", consequently where unexpected change no longer is an issue but is merely part of "business as usual".
Today, change projects are often very difficult and create a fair amount of negative sentiment within an organisation. Worse, this situation is no different for future change projects. Therefore, let us think about what types of organisation, culture, infrastructure, etc. we do need in order to get to a status whereby the right things get done, fast, effectively and efficiently whenever the boss says so. Change management seems to be a non-issue in the agile enterprise.
Have fun...
Categories: Business change and innovation

