[actf]

I agree with what you're saying, but I also wonder, if not agile, then what do you see as a better alternative?

It sounds like you're suggesting that Agile methodologies have flaws that allow projects to be easily sabotaged. While I agree with this, I'm not sure I see an alternative? Is any development methodology going to be immune to this problem?

Human communication is messy, subjective, and open to all the imperfections that come along with the human condition. Unless you're working alone, any development methodology is going to be susceptible to "people problems". I don't see this as something that's unique to agile. I'm sure I could come up with hundreds of ways that idiocy, incompetence, and maliciousness could sabotage waterfall projects as well.

[logfromblammo]

People within the software industry have a great advantage, in that they use their skills to both solve business problems and automate the solutions. Increasing the efficiency and effectiveness of the software team is a business problem.

There are some common elements to that problem that encourage the re-use of certain solutions--source control, for instance. The only mandate that needs to descend upon the team from above is to examine and improve your own processes.

There is only one other profession of which I am aware that can, given the opportunity, make every tool that is required for the job. That is the blacksmith. If a blacksmith discovers that a certain specialty tool would be useful for a routine task, he could either modify an existing tool or make the new one from scratch. No sane customer would barge in and demand that he use the "wrong" tool for the job. You might just find that red-hot tongs are the wrong tool for proctology.

But that happens to software professionals all the time. And that's where the weaponized idiot comes in. Allowing the customer to tell the skilled worker which tools to use sets up the situation where you could be performing surgery with a grapefruit spoon, while wearing oven mitts, or knocking down a brick wall with a rubber mallet and a hamburger spatula from an outdoor grill set. The unbelievable outcome is that sometimes that task still gets done.

A development process is a tool that software professionals use to do their jobs. If management needs another tool to help them do their jobs, those software professionals would be all too happy to make one. But let's not try to weld those two different tools together and call it a supertool. Agile is one of those welded-together things now, and the different parts might not work well together in your shop.

If your team cannot work without such a process, it may be because the business has neglected to hire a workable mix of masters, journeymen, and apprentices. Too many masters, and they may come into conflict. Too many apprentices, and they may struggle for direction. Too many journeymen, and they will leave to be masters elsewhere.

The only development methodology you really need is to make sure that every team has at least one master on it, and to let them pick their own tools and apprentices. If they can't get the work done with that level of autonomy, fire them and hire someone else. That's not a problem you can fix by going Agile.