Welcome!

Java Authors: Jerry Melnick, Liz McMillan, Esmeralda Swartz, Michelle Drolet, Kevin Benedict

Related Topics: Java, SOA & WOA, AJAX & REA

Java: Article

What Makes Agile Agile?

What qualifies a methodology as agile?

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 5th 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, 4th and 6th 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

More Stories By Udayan Banerjee

Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world. The focus is mostly on...

  • Keep the hype out and project a realistic picture
  • Uncover trends not very apparent
  • Draw conclusion from real life experience
  • Point out fallacy & discrepancy when I see them
  • Talk about trends which I find interesting
Google