Well, if I had to choose between doing a waterfall project with a 300 page PJM document, which is not uncommon in companies with big enterprise-level software stacks, and an agile project, even a poorly implemented one, I'd have to still choose agile.

The part I've always disliked the most are standups. "Scrum masters" are rarely "masters" at the art of scrum. They're just randomly assigned people who run stand ups, in my experience.

Then the standups devolve from what is supposed to be a two minute status update by each person in the meeting to endless discussions on problems at hand.

The scrum master rarely says, "We'll take this issue offline and set up a meeting to deal with it" for the two or three people who need to be there. It happens, but it has been rare in the sprints I've taken part in, and I've taken part in a lot of them.

So what happens is that a bunch of people are held captive while a couple of people are grinding through a problem.

The best sprints I've taken part in are those where planning pokers offer a ballpark estimate. I don't mind the planning pokers themselves, because they offer perspectives from a variety of people, and give project managers insight into the realities of their sometimes unrealistic goals.

In those best sprints, if an estimate isn't met, then it is moved over to the next sprint, and a short, and I mean, short, analysis is undertaken after the sprint to explore the reasons why the estimate wasn't met. Was it a bad estimate? That's fine. It's planning poker. It happens. Did the developer run into issues? Also fine. It's just information gathering. But, here is the key, if the developer is running into issues, those should appear during the standups, so there should be no surprise when an estimate isn't met.

At its essence, agile is a tracking mechanism. It's not designed to be an all inclusive project management tool.