Defining Agile Is More Illusive Than Ever

There is a long discussion thread in the Agile Business Analyst LinkedIn Group on how to define agile.  In my post last year, The Illusive Definition of Agile which contained a link to a post from Jim Highsmith on this topic, it was alluded that defining agile would not be straight forward.  In the post I said “To me agile is not something you do, but something you are.  If you don’t subscribe to the agile values and principles and only follow the agile practices, then you are certainly going to miss the point of agile.”  The amount of active discussion in the discussion forum seems to indicate getting an agreement on the definition of agile would continue to be more illusive than ever.

The dictionary defines the adjective ‘agile’ as

characterized by quickness, lightness, and ease of movement; or nimble

And Wikipedia describes agile as:

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

While each of the agile methods is unique in its specific approach, they all share a common vision and core values.  They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.  They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software.  They are all lightweight and nimble, especially compared to traditional waterfall-style processes, and are inherently adaptable.  As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively.

No process is perfect.  Every approach to development has some potential for improvement.  Ultimately, the goal is to remove every barrier between teams and the success of projects, and fluidly adapt the approach, the process and the software as conditions change.  That is agility.

Can any set of principles really represent agile development?  After all, Agile is just an umbrella term for a variety of methods, most of which came about long before the term ‘Agile’ was coined.  The answer is yes:  Agile methods do share common values and principles as outlined in the Agile Manifesto.

In the end its the essence of agile you are after, not a specific method, practice or technique, hence why the Agile Manifesto is the best canonical description of the mindset, culture and philosophy of agile.

In my chat with Alistair Cockburn recently, he indicated when they formed the Agile Manifesto, the original signatories could only agree on the 4 Values and 12 Principles and couldn’t define a third level as they couldn’t find a common ground.

There are people who are relatively unknown but have substantial agile knowledge and ‘get’ the agile culture contributing to the discussion forum.  For example, Mark Hunt says:

Those of us who follow one of the agile practices don’t follow each style, practice, method, etc. as defined.  And the leaders who originated them categorically state you shouldn’t.  So many of us point to the Manifesto, as that really drives why we do what we do, and whether an idea we might want to try fits — if you can justify it under the ideas behind the Manifesto, try it! There is a whole shopping list of practices, techniques and approaches (daily scrums, using burndown charts, etc.). Therein lies the rub — just because you follow x number of these doesn’t categorically make you agile.  Nor does doing more of them or doing them quicker make you “more agile”.

He further adds:

The focus is on finding things that could improve their project, their team, speed up development somehow or other specific problems.

In addition Godfrey de Zilla contributes to the discussion:

The quest for definition I think distracts from us making genuine progress in improving this industry.

Whilst trying to define agile may give us something hang our hat on and say “we are Agile”, it is easy to lose sight of what we are trying to achieve.  The I.T. industry is a messy place and we need to make it better.

Agile is not binary, instead it is a continuum and you can become ‘less agile’ or ‘more agile’.  You can employ many different practices and if you don’t use one it doesn’t mean you are not agile.  Also with each practice you can have more or less of it.  Agility is not an end in itself; it is not a capability to be maximized for its own sake – being agile is a journey rather than a specific destination.  Rather than attempting to achieve total agility for its own sake, our goal is to achieve a sufficient balance of agility for optimum results in each project context.  Therefore, the optimum goal to pursue is Requisite Agility, which is a level of agility that balances the costs of attaining it with the consequences of not having it, given the specific details of the situation.  The Requisite Agility objective is not a fixed target. It is likely to vary over time, as the business environment invariably changes.  However, Requisite Agility can be reached and sustained over time through focused increments of work process change and continuous learning.

I think Jim Highsmith sums it up quite well in the following statement:

Agile is one of those illusive things that the harder you try to grasp it, the more it slips through your fingers. For me, the day we explicitly define agile, is the day it becomes sterile and lifeless.

Once you start defining agile with a concrete definition, it will become too prescriptive.  And once agile becomes too prescriptive, it will no longer be characterized by quickness, lightness, and ease of movement; or nimble – it will become ‘Watergile’.

Chat with Alistair Cockburn about 10 years of Agile and more

The photo here is a picture of Alistair Cockburn and me earlier this week (it was taken on my iPhone and its bit blurred due to poor lighting).   A few colleagues and I had the opportunity to have a hour chat with Alistair.

We started with one of my colleagues asked Alistair about what were the main points of contention amongst the signatories of the Agile Manifesto, that couldn’t be mutually agreed?  (e.g. promoting specific practices or techniques in one discipline over another).  This was an interesting question and the response was equally interesting.  Alistair said the creation of the 4 values was easy and all parties agreed quickly as they all had a common belief.  However, there were a lot of disagreements when forming the 12 principles as each method (Scrum, XP, Crystal, ASD, DSDM etc) had differences.  In the end, the original signatories agreed to disagree and finally settled on the 12 principles as you see them today after much debate.  Each wanted to go their own way to build their brand and increase market share.  You can see how some Agile certifications are part of building that brand (as well as making money).  As a result of the diversity of each method they couldn’t find enough common ground to go to a third level of detail of the Agile Manifesto.

Hearing Alistair talk about the creation of the Agile Manifesto was a good segue into a question I had – I asked Alistair to provide a brief summary of Snowbird 10 and his thoughts of the event.  He started off by saying holding it anywhere else but Snowbird Ski Resort, Utah where it all began, would not be the same.  Besides the original signatories, he also invited CTOs from Rally and VersionOne and Lean proponents  (e.g. Alan Shalloway, David Anderson).  The Vice President of PMI was also invited, but unfortunately couldn’t make it.

It seemed many good discussions were had at the gathering.  There was a lot of discussion around the concept of leadership in the Agile community and that the Agile Alliance needed to do more in this regard.   Another discussion was around Agile needing to exit the world of software and become more enterprise wide and across the entire organization.  It was also interesting to hear that there was a small contingent of people at the event who wanted to go and create a new Manifesto of some sort.

Other topics we talked about included how important it is to increase collaboration between people and across the enterprise and that is imperative that we have a continuous flow of value.  One point Alistair did make towards the end of our chat was that Agile was becoming too prescriptive.  I couldn’t agree more – teams and organizations I have assessed or come across have very prescriptive Agile approaches which is ironically not very Agile in my opinion.  I am finding that I have to coach teams to think for themselves and stop ‘doing’ Agile.  I might blog about this more in the future.

I would like to close and thank Alistair.  He was great to talk with, very insightful and he was very generous with his time to have a chat with us.

Here’s a few related links on Snowbird 10 that you might be interested in –

• 10 Years of the Agile Manifesto website
• My Thoughts on Snowbird 10 – Alan Shalloway
• Reflections on the 10 Years Since the Agile Manifesto – Mike Cohn
• Reflections on 10 Years of Agile – David Anderson
• 10 Years Agile and Snowbird 2011 – Ryan Martens