I think people are getting too religious about following Agile methodologies. Agile principles and best practices are valuable for applying important lessons that have been learned in software development. However, the drawback of following methodologies is that it takes experience and wisdom to know which of their practices work best in a particular situation. Best practices and even principles that are blindly followed may do more harm than good, even if they are Agile.
To illustrate this, consider the following two Agile principles (http://agilemanifesto.org/principles.html):
Business people and developers must work together daily throughout the project.
This may sometimes be desirable but this is not common. Business people need their time to do business. Business involvement is important for software development, but the amount of time that is required from business people can vary a lot between projects. Following this Agile principle too rigorously may do more harm to the business than is justified by the increase of quality and speed in software development.
The best architectures, requirements, and designs emerge from self-organizing teams.
If you have a small team of motivated and skilled people that know about the business and the technologies that are used, this is certainly true. However, I have seen this principle fail in several projects. These projects usually scaled up too fast with people that were too randomly selected. Having a RUP elaboration phase would have helped more than hoping for something good to emerge spontaneously.
If Agile principles are not generally applicable to all projects, this is even more the case for the rules prescribed by specific Agile methodologies. I will give some XP examples. If 100 JSPs need to be developed that are technically similar, it is not be the best choice to do pair programming for all production code that is developed. If half of your project can be based on existing production code, it may not be worth the investment to refactor whenever and wherever possible because its design could have been better. It may also not be a good idea to write unit tests for all its classes.
Don't get me wrong. I think the Agile movement has resulted in many ideas that can help software development projects a lot. However, for every team and for every project, the set of Agile ideas that will work and the level in which these ideas should be applied for an optimal solution will be different.