In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them.
I've seen statements very much like this for a number of years now. Others have been more focused on the project management quadrants:
Perhaps it has just been my personal experience, but I've found that in reality most projects have been much further down the Uncertainty axis than most people thought. Even rewrites of existing systems where we've been told "the old system IS the requirements!" contain uncertainty, and almost always have higher complexity owing to changes of language or platform.
I haven't yet mentioned Mike's 3rd criterion: urgency. So, um, has anyone ever worked on a project where there wasn't pressure to deliver? Seriously.
Mike goes on to state later in his post,
So let’s see how these three factors–urgency, complexity, and novelty–mix on various projects, starting of course with software projects. There couldn’t be a better fit. Software projects are notoriously complex. Each software project is largely a new endeavor. And in today’s world, there is almost always a sense of urgency.
The only missing variable that can preclude using an Agile approach is the one with the greatest impact - People. If the people involved aren't interested in transparency, visibility, accountability, collaboration and soliciting and acting upon feedback, then an Agile approach will not work. In those cases, any approach will find itself challenged because the issue isn't the approach but rather the people using it. What Agile will do in those circumstances is make the pain of the dysfunction tangible and acute.
What separates good people and organizations from the rest is how they act on reducing the pain.