It's not Agile itself that I personally am against, though the methodology doesn't allow for significant testing unless you've already got recursion test scripts in place and an environment that can mimic heavy concurrency.

I'll reference this wiki article, and for once the wiki is the most likely best source for this discussion. Instead of being 'actual rules', it's the publically best known set of them.

Let's take a few of the core principles:

Customer satisfaction by rapid delivery of useful software

My definition of rapid and your definition of rapid may agree. Management's? Not so much. Rapid is subjective. There's rapid and there's stupid, and I find some places ride the line. "It's part of Agile!" "Rapid does not mean ludicrous speed, we've gone plaid!"

Welcome changing requirements, even late in development

Another subjective term. If you're doing 1 month code runs 4 days before the end of the run is not 'late in development', it should be 'see you next month'. Rushing to push things through two days before version go live is insane... but it's "Part of Agile!" Gah. Notice a theme forming? It's not Agile itself, it's the implementations.

Close, daily co-operation between business people and developers

Don't know about you, but the last time I saw a business person even remotely give a hoot about a Scrum Standup was when something had gone horribly, horribly wrong. Yes, it means generic communication, but that's part of the theoretical implementation of it. I know there are other ways of interpreting it, but a lot of shops feel the standup is a good time for generic business so we don't get Dilbert meetinged to death. Specific issues, of course, you get up and go cube visiting.

Projects are built around motivated individuals, who should be trusted

You trust your Juniors how much? I sure don't, that's why they're Juniors. Implementation vs. principles.

Simplicity

That's a riot. I've yet to meet a team who could 'simply' impliment scrums and Agile. It works, yes, but there are people taking courses just to learn how. That's not simple.

I'm not against Agile. I happen to like the theory behind it. I also like the theory that pretty women go for the nice guys. That's why I own a leather jacket and just bought a motorcycle... The implementation of Agile, however, is something that still needs to be worked on. I agree with the original article, that there's not a lot of testing and it's difficult to make a comprehensive design in an Agile environment. You end up with a very modular database. Now, that CAN be a good thing, but more often then not something you did six months ago is now going to be a serious problem, because you had no idea the requirement was even coming.

Add to that, sometimes a month is simply not enough time to get through all the research, analysis, and rework it'll take to fit a single requirement. Yes, I know, you then split it across sprints (or whatever you're calling your time cycles). I've rarely met the place that'll let you take an entire sprint on 'research'. We've got work to do! Code to produce!

We've got... a database that is locking... everything. Why's it slow? We did it quick!

If you'd known before hand you wouldn't have had to spend the extra month and a half spinning your wheels to correct an previously undisclosed design flaw, you could have done it in the first place.

There have been exceptions to everything I've said here in my own working experience, but these are common enough problems at this point in the implimentation of Agile. If everyone had every problem I listed above the system would break down and die and the company would sink. All of those are some significant issues I've ran into along the way so far, and usually everyone's got some combination of them.

However! I have met places that did Agile well, as well (honest, I'm not JUST ranting). It is pretty, and it can be done intelligently. They used a combination of waterfall and Agile. They planned projects in waterfall style, and all project pre-prep work was done in the waterfall method we all know and love/hate. Design screens, intended results, mock-ups, expectations. Basic architecture design work (Expected ERDs, that kind of thing) and any significant algorithm locations were marked and mapped, if at least at a 10,000 foot view.

Then, once we had a roadmap, we went into a sprint breakout, figuring out what we could deliver in a cycle, but always, always, with the entire design in mind. Some sprints never put a single thing in front of a user, they were infrastructure and/or research. One sprint there every year was dedicated to old code cleanup (it meshed nicely with the end of year reporting lockdowns that business preferred).

But there was a lot of prep work there before you started a cycle. A project didn't 'sprint' until the tech spec got written up, and unless an end user could say "Yeah, that looks like about everything", it didn't sprint. There were some significant benefits to the waterfall method, even if it is old and musty.

Alright, this post has wandered across the map, and I should probably take my soapbox and go home now.