First of all, I like Agile.
But, as well known, "there is no silver bullet". Obviously, if agile methodologies still not "rule the world", agile approach have some shortcomings.
So, questions are:
Agile methodologies and frameworks are better suited where technology is fast moving and requirements either cannot be stated fully upfront or tend to change often.
Let us take the example of a B2C (business to consumer) software project that has a graphical user interface (GUI). You will build many gates for validating usability or user experience:
Wireframe testing prior to the development of a functioning website.
Alpha testing when a website is barely functional and populated with just enough data for participants to complete the essential tasks.
Beta testing when a website is fairly stable and approaching full function.
A/B Testing post launch.
At every one of these stages, you look at the feedback and make changes to your design so that the final outcome is easy and appealing to the users and, most importantly, accomplishes the business goals.
To take another example, in one of my previous projects, we had integrated with a vendor product for media storage that was a key feature of our web site. Half way through the project, we found that the vendor support was so bad and the cost was so high we decided and built the capability ourselves and eliminated the need for the vendor.
These are the reasons why among software developers you hear such extreme statements like, "Most GanttCharts are lies from the get-go. Most GanttCharts' lies get bigger as time goes on."
Looking at the Stacey Complexity Matrix above, Software Development, New Product Development and Applied R&D Projects all belong in the complicated or complex category. Use an adaptive planning methodology, such as Agile, for these. Frequent inspection and adaptation is key here.
What are disadvantages of agile methods?
Cannot track dependencies as precisely as in a Gantt Chart (try creating FS, FF, SS and SF dependencies in an Agile tool).
Cannot monitor cost and schedule variances very well (goal oriented product roadmaps will work to some extent).
Not well suited for functional specialization (prefers cross-functional resources).
In what kind of projects better not to use agile approach?
On the other hand, Construction and Engineering projects benefit from clearly contracted requirements and well established technology. The type of changes that we see in software requirements is neither expected nor is easy to accomplish in construction. Predictive planning works better for these. That is why very large construction projects are run successfully with the help of good upfront planning Gantt Chart and exception reporting.
This is an odd question, but let's see if I can give you a good answer. First, in the comments you said that you're thinking about the agile manifesto itself, not a framework like Scrum. The agile manifesto contains 4 value statements and 12 principles. It would be difficult to answer the question "On what kinds of projects would having a ton of documentation and no working product be a preferable outcome?" or similarly "On what kinds of projects would sticking to a plan with the clear understanding that the plan is wrong be preferable to modifying the plan?"
There are cases where the agile manifesto may be too difficult to follow all at once in an organization. For example, one of the principles states "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." If you have a whole development organization used to huge swings of downtime and crunchtime, they probably don't know how to set a sustainable pace and this principle becomes more of a goal to work toward.
So the best answer I can think of to your question is that I can't think of any project type that wouldn't work with these values and principles, but there are organizations and engagements that don't have an existing culture that will support them and cultural change takes a lot more time.
Agile methodologies is not just about methodologies, is a lot about culture. And, as it is related to culture, a very long time is needed to run it in the best way you can.
You can think the agile methods as a framework and adapt this to your reality and not just as a process or method.
To know the pillars of agile methodologies: http://agilemanifesto.org/
So, reading the agile manifest we will can ask: When it doesn't work?
When following a plan is more important to respond to change (civil construction, some factories);
Contract negotiation is more important than customer collaboration;
Comprehensive documentation is more important than a working product;
Processes and tools is more important than individuals and interactions.
Is important to mention that the agile manifesto doesn't say the documentation, contract negotiation and tools/process aren't important. It say that theres other things that you need to look first if you want to become more agile.
Normally is because of that is so hard to run agile in a big company, for example, theres a lot of cultural change needed for run this type of framework. So, if you can't ensure in any way you will follow the agile manifesto values in your company, maybe you can't run agile methods. But, if you really want to run agile, you will need to be a culture change agent first.
