Why Agile?

A friend of mine sent me email telling me he'd been working with some Agile projects and was looking at working with a new group. The new group's management was used to traditional project planning and he wanted to know "Basically my question is that I am looking for material that has testimonials on what kinds of project management obstacles some medium sized companies have faced and how they overcame them while using the Agile methodology. Any links or references would be great if you have them."


Here is my response:
A good place to ask your question would be the Agile Project Management group. There's lots of PMP types on there or people who work with traditional PMs that might have some good advice.

Good cases I've seen usually start with "what we're doing now doesn't work" (because if it did we wouldn't need to change). Some of the reasons why and why other approaches are better:

• Development is an exploratory endeavor. Traditional project plans work great if we're doing repetitive tasks that are pretty well understood. Software development doesn't usually fit this pattern and so it is hard to lay it all out ahead of time. When we're wrong on the schedule, due to tasks taking longer than estimated (and we inevitably are), people still want to drive to keep the date and the scope, which leads to short changing the tasks at the end of the development cycle such as testing and documentation.
• Recognition of value can occur sooner. If we're developing in a truly iterative and incremental manner, we can release software that does something (and these should be the most important ones) sooner. So, we can start to get some of the value now rather than waiting until the end of a really long development cycle. Just like in time value of money sense, getting the value now is ore valuable than getting down the road in the future- we accumulate more of it over time
• In a related sense, being able to get software out early makes it better software in the long run. Developing software is encoding knowledge (see a post on that here), but the people who know how to do the encoding are not the same as the people who have the knowledge, typically. Only when the people with knowledge get it in their hands can they say what isn't quite right about it or how it could be better. So, the sooner we can get that feedback the sooner we can get it in the right direction, with less invested in the "wrong" direction. It wasn't intentionally the "wrong" direction but there is just only so much you can get right trying to elicit or review requirements.
  

Anyway, the 1st step- recognizing what is broken in the existing state is what can make the strongest case for change.

What would be your answer for why groups should adopt agile methods? And what material would you point them to?