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’.
RSS - Posts
I loved Jim Highsmith’s comments (which I found on your blog, Chris) and it was almost an epiphany. After first becoming a Scrum Master, I found I just couldn’t follow each and every ceremony as taught and found myself tweaking and modifying behaviors when my teams ran into issues or had barriers not covered in the literature.
I also lead an Agile SIG at our local IIBA chapter and the questions most often raised there are ones like “we don’t follow this ceremony at our company so are we still Agile?”, or “our sprints last a month, is that still Agile?” It became obvious to me that people following Agile are looking for some cookbook or formula to follow and fear some ‘Agile police’ will come down on them for not meeting some arbitrary criteria.
While I gradually came to the feeling Agile is more of a meaning of “being agile” rather than “following Agile standards”, more than most other authors and writers on the topic Jim nailed it right on the head– there is no Agile formula, Agile is how you think and act.