Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.
This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.
The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.
Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
Factors contributing to the success of a development project, in decreasing order of importance:
1. the skill of the team
2. the determination of the team to succeed
3. appropriate choice of technologies
4. process
In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.