I don't know how I can constructively with you. I'm aware that there are things other than Agile and Waterfall. I'm also reasonably sure that you don't think good project managers magically make teams more productive. But you've done nothing other than trash Agile, dismiss Waterfall, and offer no alternatives of your own. How do you like to develop software?

I get what you're saying about "tell me what you want to do first, and we'll work together from there". I mentioned a few times in my post that it's always important to not blindly implement Scrum, but to see what works well from you. But having Scrum defined is still useful for a lot of people, since:

- It gives you a starting point to work from. Every project is different, but there's certainly common elements to projects as well. It's a bit like design patterns in software - applied blindly and religiously, they're impractical and can lead to pitfalls, but that doesn't they can't serve a purpose.

- It takes a lot of time to learn what works and what doesn't in regards to project management. Telling new managers and developers to figure out what works for them with no guideposts is just going to lead to a whole lot of inefficiency as everyone stumbles towards a (mostly) shared goal.

In regards to projects taking longer under a waterfall approach vs. an agile approach, there's a lot of different reasons for this sort of thing happening.

- Working on small sprints (or whatever you want to call them) instead of month-long projects saves you a tremendous amount of integration time. Show me a project under active development that's existed outside the production branch of a codebase for more than a month that isn't going to be a nightmare to integrate.

- Forcing yourself to make decisions up front, especially when you have a strong product management component to your team, can result in drastically more time working on requirements instead of starting with some unknowns and letting them work themselves out.

- I can probably point to several bits of these projects that we would have avoided doing or would have done differently with Agile, but the requirements said otherwise. It's amazing how much power requirements documents have, and how much inertia they can add to a project.

- Stuff generally gets done close to the due date on a project. This is as close to a universal truth as I've ever seen in project management. By keeping everything in tight iterations, you can control the flow somewhat by putting pressure to complete releasable software every week, rather than one massive due date that everyone scrambles for at the end of a project.

- Being able to "re-evaluate project plans" is a hallmark of Agile, not Waterfall. I agree, being able to re-evaluate and iteratively arrive at a solution outside of rigourously documenting things up front would make things a lot more efficient. That, far more than planning meetings and retrospectives, is what Agile is all about, so I'm not sure why you're so intent on trashing it.

I'm not sure why my example is ludicrous. If the process used doesn't have any effect on how long it takes to develop a project, what's the point of any process in the first place? Of course using different methodologies will have different results - even if you aren't an Agile fan, that's completely obvious.