Am I the only person who thinks that we need a clear, well understood and unambiguous determine if the development process that you are following can be classified as Agile development process?

Do you necessarily have to have a small, co-located, cross-functional team to be able to claim that your process is indeed agile? If you go by what agile thought leaders are saying then “small”, “co-located” and “cross-functional” is no longer considered a necessary condition for classifying a process as agile.

Indeed, the answer to the following questions is no longer an outright no.

• Can agile process scale to a large team size?
• Can distributed project team claim to be using agile development?
• Can off-shored projects work on agile mode?
• Can agile development co-exist with CMMi?

Obviously, to be able to answer “yes” to these question we would need to come up with a process which different from what you would have followed for a ”small”, “co-located” and “cross-functional” team. Now, how would you determine if this modified process can indeed be classified as a agile development process?

Without suitable tests the discussion would boil down to your opinion pitted against mine.

Can agile projects fail?

Without such a test you can always argue that the project failed because the process chosen was not really an agile development process and that is why the project failed.

Without suitable tests there is no way to counter such an argument.

I prefer “A” over “B” but “B” is also important

I am not criticizing the agile manifesto. It is brilliantly piece of articulation … it conveys, without being explicit, how agile processes are different from the “heavy weight” processes prevailing in 2001.

However, it does not help us in determining when a process can be classified as agile and when it ceases to be agile.

Minimum common denominator

Is it possible to take the popular agile development processes like Scrum, XP and TDD and find out what is common the minimum common denominator and use that as a test?

There are 2 problem to this approach:

1. Which methodologies would you choose?
2. Would you find significant commonality?

Selecting list of mandatory practices

There is a growing list of practices which are classified as agile practice – daily stand-up meeting, continuous integration, pair programming … the list is quiet large.

Is it possible to choose from the list a set of mandatory practices – a necessary condition for a process to be considered as agile development process?

Again, there are 2 problems:

1. Coming to a consensus on what is mandatory practice is a difficult task
2. What happens when an new and better practice emerges as a substitute for one of the selected practice?

Four Tests to determine if you are following an Agile process

Test 1: Software is developed in iteration regularly delivering working code

I think this test is beyond any debate! Nobody … nobody would claim a process to be agile without an iterative approach. Iteration without working code is meaningless. Working code also implies continuous testing.

Similarly, iteration without feedback is again meaningless. So, regular feedback from users is mandatory.

But beyond that there are many variants to iterative approach.

• Should your iterations be of fixed interval?
• Do you need to have a process of continuous integration?
• Is it necessary to have an automated regression test suite?
• Should you focus on always having a potentially shippable product?

These are all good practices, very important in certain situations, but not necessarily applicable in all situation.

Test 2: Never say no to change because it is not there in the plan or because it involves rework

Indeed, there can be many valid reasons why you may have to say no to change.

• The impact of the change may be very significant, involving huge amount of extra work disrupting other planned features.
• The value of the change may not sufficient to justify the effort to incorporate the change.
• The change may be inconsistent with the way the rest of the software is expected to work.

There can be many other reasons for not accepting the change or deferring the change for later.

But, refusing a change because it is not there in the plan or because you have to discard parts of code which you have already done is not an acceptable reason in any process that claims to be an agile process.

Test 3: Accept that everything cannot be explicitly specified

Typical traditional process would work as follows:

• A requirement analysis would be done and a software requirement specification document would be prepared
• User will go through it and approve it
• The software would be built and tested according to what is written in the document
• User will try the software and claim that several important features are missing
• Development team will claim that they have not been specified
• User will claim that they are obvious

This approach is unacceptable in any agile process.

It is not that documentation is not important. What is unacceptable is to insisting that everything has to be explicitly documented.

It is like Japanese approach to communication. In western culture when A communicates something to B and B has not properly understood it then A is to be blamed because he did not check if the understanding is correct. In Japanese culture, the blame in on B because B did not ensure that his understanding is correct.

Test 4: You follow only those processes which you have found it to be of value under the given circumstances

If you have gone through an exercise of spring cleaning you would realize that how every object you pick somehow looks useful and you do not want to throw it.

Same thing happens when you are given a super-set of practices and asked to choose what you should follow. This is the approach followed by all heavyweight processes including RUP. Every practice in isolation would look useful.

So, any process which claims to be agile start with bare minimum practices and allows the project team to choose practices which will add real value in the given circumstances. It also has mechanism of having a regular introspection which allows discarding practices which has not proved its worth.

In Lean parlance it is called maximizing the work not done.

What do you think?

• Are these tests have any value?
• Are they relevant?
• Have I missed out any important dimension of agile?

I am eagerly waiting for you feedback.

Read the original blog entry...