I find that people have pet issues which they are always looking for a new way to solve. Often, when a new way of doing things is introduced, people ask if this new thing will solve one of their pet issues. Agile development is a new way of doing things. Thus, people often ask if it will solve one of their pet issues. As an Agile advocate, it is tempting to find a way to answer such questions in the positive.
Unfortunately, Agile development is not a panacea. It will not cure all your software development problems. Here are some of the issues that Agile development does not directly address: technical problems, choice of which technologies to use, personality conflicts, mismatched skill sets, insufficient management skills, poor listening skills, or poor communication skills.
However, there are two aspects of Agile development which can be applied to all software development problems: frequent feedback, and reduced complexity. The frequent feedback provided by Agile development provides a better problem solving environment than traditional development. The environment surfaces more problems, surfaces them faster, and provides more opportunities for addressing problems and gaging the effectiveness of those solutions.
Agile development also reduces the complexity of your software development projects by breaking it up into smaller pieces. It is much easier to complete 6 projects which are each 1/6th the complexity of a large project than it is to complete one large project. This is especially true when you take into account the fact that the planning required for the large project must cover a larger time frame and take more variables into account.
Consider this rough analogy. You want to transport 300 people from Boston to San Francisco and you are given the choice of two methods. The first method is to create a rough plan and have a pilot who can make adjustments as needed as you go. The second method is to line up the plane, set it to hit a cruising speed and altitude and go straight for a set length of time and then start its descent at a specific time. And there is no autopilot. Basically, you set the parameters at the beginning and that's it.
In the first case, you can adjust for changing conditions as they come up. These might include weather, air traffic, or natural disasters. There is a medium degree of difficulty for this method.
In the second case, you must accurately predict every possible condition and plan for it accordingly in order to have the plane safely hit the tarmac at the destination at the right time so as not to interfere with other planes. If there is a change in one of the variables affecting the flight that you didn't take into account, it could make for a rough landing. The degree of difficulty here is pretty much incalculable. Suffice it to say that it is very high.
As I write this I'm reminded of another analogy: golf! The variability involved in golf is exactly what makes it such an interesting game. It is also why there are only a small number of people in the world that have ever gotten a hole in one. Considering that traditional development is very similar to expecting to hit a hole in one on every hole, it is no wonder that so many software projects end up being sub-par.
Next: Agile Product Management