Silly question – or is it? How do you judge if a methodology can be classified as agile methodology? Can Iterative or Spiral development methodology be classified as agile? What about Six Sigma or Lean process? On what basis will decide will you decide? If you go by the Forrester classification, Iterative or Spiral development methodology is not agile where as Six Sigma and Lean is agile.

In the survey report Agile Development Management Tools, Q2 2010, Forrester classifies Scrum, Agile Modeling, Feature-Driven Development, Test-Driven Development, eXtreme Programming, Lean Development, Microsoft Solution Framework for Agile, Agile Data Methods, Adaptive Software Development, Six Sigma, Crystal, Behavior-Driven Development and Dynamic System Development Methodology under agile methodology but classifies Rational Unified Process, Iterative Development or Spiral under Iterative Development.

Is there any accepted definition for agile methodology which can help us determine if specific methodology can be classified as agile? I have looked and have not found any.

Can we fall back on the agile manifesto or the 12 principles behind the agile manifesto? If you study them carefully you will realize that they are more of an aspirational statement rather than specific guideline which can be used to evaluate a methodology.

For example, take the first statement in the manifesto – “Individuals and interactions over processes and tools”. Does is mean – don’t bother with tools and processes? Is it feasible in today’s fast passed, complex world? It is like the statement from John Zachman – You can run an enterprise with pencils, paper and file cabinets – reality in the past; unthinkable today.

Similarly, have a look at the 5^th principle – “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Does it mean – don’t bother with process? If there are multiple agile projects going on in an organization then can each team chose to follow a different agile methodology?

For that matter, 4^th and 6^th principles state – “Business people and developers must work together daily throughout the project” and “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. This will mean physically collocating business people and developers. In the current globalized and virtually networked world, I wonder how this is feasible.

What we need to do is to take a couple of step backward and try to extract the essence and formulate clear yardsticks which can be used to qualify any methodology and agile or non-agile. I suspect that most of us know intuitively what those yardsticks are but it will still be good to have it in black and white.

Essence of Agile – two dimension
Before we can formulate the yardsticks let us understand the spirit behind the manifesto.

Change is inevitable because …

• …software cannot be unambiguously and completely specified through a document or a model
• …people don’t know and cannot completely visualize what the software should be till they play with it
• …communication is never perfect and correction through feedback loop is essential
• …environment around us is never static and useful software needs to evolve to match the revised requirement

Thus, any methodology to qualify as an agile methodology needs to have specific recommendation on “how to effectively manage short iterations”. As a corollary, any methodology which tries to lay down standards on how to “unambiguously and completely” specify different aspects of the software cannot be considered as agile.

Individuals create software and better software is produced …

• …by motivated individuals
• …through regular interaction among individuals
• …when individuals working together figure out how to be more effective
• …where the environment has minimum roadblocks and illogical restrictions

Therefore, “how to help individuals to work together” is the second dimension that an agile methodology needs to address.

Yardstick of evaluation – two positive and one negative questions to ask

(+ve) What recommendations does the methodology provide …

1. …for managing short iterations: Obviously any methodology which does not recommend iterative development gets immediately disqualified.
2. …to help create a self-motivated team: Recommendations need to be specific and actionable and not philosophic statements.

(-ve) Is there any mandate that makes it necessary to produce a document or a model which is expected to be a complete and unambiguous representation of a specific dimension of the software?

Evaluating methodologies and extracting principles
In subsequent posts, I plan to use these criteria to evaluate different methodologies.

Related Posts

• Why Does Agile Work?