I like the definition from the Practices of an Agile Developer book by Andrew Hunt and Venkat Subramaniam:
"Agile Development uses feedback to make constant adjustments in a highly collaborative environment."
I've been attempting to steer various development groups towards Agile for more than several years now, and find that sometimes the less said the better. Finding a clear and over-simplified one-senetence definition has been very useful for me on numerous occasions. It is important to understand that a "simple definition" can lead to unending questions, so you better be ready with answers to the hard questions or comebacks.
Some common "management" hard questions/comebacks include:
- How does Agile scale? I've read that Agile is just for small teams and that it can't scale because... (fill in the blank)
- Our customers are not going to want to do this. They come to us for solutions - we are the experts in their eyes.
- We need to know that everything will be done on time - Agile can't do that.
- How can we plan our resource requirements if we don't have accurate estimates?
- QA is not going to buy into this. How can QA do its work if we are changing things all the time?
I have notes on various converstations and could probably find over 100 questions of this sort that have come up (and that I've bothered to make note of), and I try to be prepared for any direction the converstation moves.
There are various Agile apologetics for any question I have encountered, but for me it often comes down to moving the idea forward with the hope that "planting the seed" will bring improvements. I have often been pleasantly surprised to find someone who was previously "anit-aigle" starts to become a proponent.
However, I have found little opposition to some points. For example, I have never had anyone make a strong argument against "process improvement" or "improving communication". A long time back I was taught by a brilliant salesperson that if you can get someone to say "yes" three times you've made the sale. Here is a (not so realistic) example:
Me - "I'd really like to see us improve our processes here so we can get things done a little faster, what do you think?"
VP - "Yes - that would be great!"
Me - "I think that if we can find a way to improve communication between the business team and the development team we could move things along more smoothly, but I'd like to hear what you think..."
VP - "Yes! Good idea - I've been thinking of that too, perhaps we could get everyone together weekly"
Me - "Also, if the QA team could be brought in a little sooner so they could get a jump start, do you think that would be an advantage?"
VP - "Yes - that seems reasonable."
Me - "Okay, we'll start doing Agile tomorrow and hire a whole bunch of Scrum Masters"
VP - "Ok. Agile it is. Here is a big check for training and hiring a top notch consulting group to guide us through the process".
Well... this is my reply and I can pretend anything I want to. The point is, get buy-in on the big ideas and the details can be worked out later. Perhaps.
[ April 17, 2007: Message edited by: Woody Zuill ]