What are some situations where Agile is inappropriate?

I have been hearing and reading about Agile for years. I own a book or two on it and I like the idea.

I am finally in a position where I could roll something like this out where I work, but I have serious concerns about whether it's the way to go for us:

Isn't there a minimum size for this? Big design up front must be more efficient for a three or four week project... Right?
Our customers usually require fixed prices. They need to know what they're dealing with, except in special cases where we are up against an obvious black hole and even then people are more comfortable with a cap. So how can you provide a quote if you're going with a process that is tolerant of ongoing requirement changes?
I understand that Agile may provide better odds of success in more complex projects, but won't it drive up costs to the customer? And of course there is the cost of failure to consider - perhaps we are back at the minimum size question here.
How in the world would you explain this counter-intuitive approach to customers? Non-technicial stakeholders might not have the experience to wrap their heads around anything beyond Waterfall.
Even for internal projects, there are budgets. What am I missing?
It seems like there is some backlash against Agile lately. Is something else going to start gaining traction soon?

Note: We are a 5 dev shop with projects ranging from a day or two all the way up to several months. I don't believe that there is one methodology to rule them all, but it would be great to find something flexible enough that we can adapt it to all of our projects.

Thanks a lot!

Brian MacKay

Solution

I don't think one methodology can rule them all. I am sorry. I am a firm believer in finding the right model for the right project. For example how would you feel if your were into surgery and you knew the machine which was keeping you alive was developed in a rapid iterative cycle with little design upfront.

But anyway, on to your question. I am a big believer in agile approaches, of keeping your iterations short, focusing on what the user wants, and not building the battleship but only building exactly what you need. I would say 95% of all projects could use agile approaches, and if they can't it's usually a cultural issue, not a project issue.

Now as far as BDUF (Big Design up Front), we had great success with a 20 person team on a 4 month project, we took the project broke it down into 3 four week cycles, at the start of each cycle we all meet in a room, and said ok here's what we need to build, here's how we will build it, and we took a stab at what our interfaces would look like, what data we needed etc...But it was only a stab, we then went back to our desks, and whoever owned the various pieces flushed out the details.

Essentially we did enough BDUF upfront to jumpstart the team (And ensure we covered all the business requirements). We used to call these sessions Developer Days and it was a good way to jumpstart the team. If you have the cash take the team off site you can stuff them in a conference room at a hotel feed them lots of junk and watch the juices flow.