Agile agile agility

If you are familiar with Jeffrey Moore’s Crossing the Chasm, you know a key aspect of his model of the propagation of new ideas is that there is a point where ideas transition from Early Adopters to larg(er) Early Majority organizations. That is it goes from those who are early enthusiasts of an idea and cross a gap (the “chasm”) to those who need more confidence in the idea. The Early Majority organizations exhibit a pragmatism about adoption of new ideas and seek signs of legitimacy of those ideas. Beyond that we find Late Majority organizations who are conservative about adoption of new ideas and wait for Early Majority organizations to accept the new ideas (at least at some level). After the Late Majority are people/organizations consider Skeptics who may never adopt the new ideas.

I become aware of the Agile Manifesto’s values and principles in 2002. After attending my first Agile Development Conference in 2004, I decided that I want to work according to those values and principles and step away from the phased-sequential (“waterfall”) approach I had been involved with since the mid-1980s. Before that, I worked in small companies where I cannot say we had any specific lifecycle and much was done somewhat ad hoc. However, in one case, when I read eXtreme Programming Explained in 2002, it seemed to me that, in the early 1980s, we worked in a way that was similar in spirit to Agile ideas.

Now, during two decades pursuing Agile ideas, I have o heard people ask, “What is the definition of Agile?” or say, “There is no definition of Agile.” It seems to me that lack of clarity around Big “A” Agile, small “a” agile and agility has been a problem. I think part of this is because of the wide acceptance of Agile frameworks and their associated certification programs by the Early and Late Majority organizations seeking confirmation of the legitimacy of Agile ideas. For them, “Agile” has meant the structures and practices advocated by these frameworks and there are many of them.

But the authors of the Agile Manifesto had different ways they were practicing “little” methods before the Manifesto. When they came together and created the Manifesto, they adopted the word “Agile” (with the capital “A”). It was not necessarily a wildly popular choice for them, but it is what the settled on at the time. For me, therefore, the “definition” of Agile is what exists in the Agile Manifesto’s values and principles. Until that Manifesto, there was no Big “A” Agile. If an organization claims to be (or be doing) Agile, the Manifesto must be their definition.

Of course, before Big “A” Agile, there was always the word “agile” with the lowercase “a.” Dictionaries clearly defined with in terms suggesting things such as:

· marked by ready ability to move with quick easy grace;

· being resourceful and adaptable;

· quick and well-coordinated in movement.

Similarly, dictionaries will define “agility” as:

· the quality or state of being agile.

So, to be “agile” means to demonstrate behavior that fits the definitions above. For example, I think of mountain goats as being agile in the way they easily move in mountainous terrain. Another example would be gymnasts such as those performing on the balance beam as they perform actions on that narrow beam with great fluidity.

On the other hand, there is an aspect of being truly agile that the definitions do not explicitly state, though “well coordinated” approaches the idea. That aspect of being agile is maintaining stability while moving quickly and easily. If the mountain goat slipped on the rocks and the balance beam gymnast fell of the beam or otherwise missed a move frequently, we would not likely find them good examples of “agility.” I believe an important aspect of Agile ideas is how one maintains stability while carrying out the Manifesto’s values and principles. That stability contributes to confidence in what a team does so they feel willing to move forward easily and adaptably.

So, regardless of the practices an organization pursues to “do Agile,” they must be able to understand and show how they meet the Manifesto’s values and principles as well as maintain stability while they do so. People have said that, since it has been over two decades since the Manifesto was written, there are things that have been learned and things the Manifesto did not cover. I don’t question that, but this does not mean to me that the Manifesto values and principles have become obsolete as the base definition of “Agile.”