From the Blogosphere
Four Tests to Determine If You Are Following Agile Development
Do you necessarily have to have a small, co-located, cross-functional team to be able to claim that your process is indeed agile
By: Udayan Banerjee
Jan. 19, 2013 02:00 PM
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.
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:
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:
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.
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.
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:
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?
I am eagerly waiting for you feedback.
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week