Martin Fowler
Using a agile method is not for everyone. There are a number of things to bear in mind if you decide to follow this path. However I certainly believe that these methodologies are widely applicable and should be used by more people than currently consider them.
In today's environment, the most common methodology is code and fix. Applying more discipline than chaos will almost certainly help, and the agile approach has the advantage that it is much less of a step than using a heavyweight method. Here the light weight of agile methods is an advantage. Simpler processes are more likely to be followed when you are used to no process at all.
For someone new to agile methods, the question is where to start. As with any new technology or process, you need to make your own evaluation of it. This allows you to see how it fits into your environment. As a result much of my advice here follows that I've given for other new approaches, bringing back memories of when I was first talking about Object-Oriented techniques.
The first step is to find suitable projects to try agile methods out with. Since agile methods are so fundamentally people-oriented, it's essential that you start with a team that wants to try and work in an agile way. Not just is a reluctant team more difficult to work with, imposing agile methods on reluctant people is fundamentally at odds with the whole notion of agile development.
It's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that we've found on several occasions that we've worked with customers who didn't want to collaborate, but changed their mind over the first few months as they begun to understand the agile approach.
A lot of people claim that agile methods can't be used on large projects. We (ThoughtWorks) have had good success with agile projects with around 100 people and multiple continents. Despite this I would suggest picking something smaller to start with. Large projects are inherently more difficult anyway, so it's better to start learning on a project of a more manageable size.
Some people advise picking a project with little business impact to start with, that way if anything goes wrong then there's less damage. However an unimportant project often makes a poor test since nobody cares much about the outcome. I prefer to advise people to take a project that's a little bit more critical than you are comfortable with.
Perhaps the most important thing you can do is find someone more experienced in agile methods to help you learn. Whenever anyone does anything new they inevitably make mistakes. Find someone who has already made lots of mistakes so you can avoid making those yourself. Again this is something true for any new technology or technique, a good mentor is worth her weight in gold. Of course this advice is self serving since ThoughtWorks and many of my friends in the industry do mentoring on agile methods. That doesn't alter the fact that I strongly believe in the importance of finding a good mentor.
And once you've found a good mentor, follow their advice. It's very easy to second guess much of this and I've learned from experience that many techniques can't really be understood until you've made a reasonable attempt to try them out. One of the best examples I heard was a client of ours who decided to trial extreme programming for a couple of months. During that period they made it clear that they would do whatever the mentor said - even if they thought it was a bad idea. At the end of that trial period they would stop and decide if they wanted to carry on with any of the ideas or revert to the previous way of working. (In case you were wondering they decided to carry on with XP.)
One of the open questions about agile methods is where the boundary conditions lie. One of the problems with any new technique is that you aren't really aware of where the boundary conditions until you cross over them and fail. Agile methods are still too young to see enough action to get a sense of where the boundaries are. This is further compounded by the fact that it's so hard to decide what success and failure mean in software development, as well as too many varying factors to easily pin down the source of problems.
So where should you not use an agile method? I think it primarily comes down the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular I think that this means you should never try to impose agile working on a team that doesn't want to try it.
There's been lots of experience with agile methods over the last ten years. At ThoughtWorks we always use an agile approach if our clients are willing, which most of the time they are. I (and we) continue to be big fans of this way of working.
Reference:
http://martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevel...