In my half-time consulting job, the cow is definitely not a sphere. I don't know how agile could possibly fit in and I can't imagine how I could have any influence on it fitting in, given my status as an advisor, many times removed from the actual development. But God what a mess.

Yet isn't that the reality of developing software? A big mess? Aren't all organizations dysfunctional in their own special ways? Software gets developed and delivered anyway. That's what I love about the business.

One thing that has occured to me is that "branding" it may have been a good idea–people are usually more likely to buy into a methodology for some reason.

I think most of the problems with Agile methods can be summed up in that one quote.

Unless you're actually in the business of SELLING software, then the goal is never to deliver software. Software is at best an enabler of other, more important business goals. Agile gets sold as something that makes development better, but it requires a great deal of commitment from business folks who are likely to respond with a "so what?"

A development method that benefits the business will be adopted no matter what developers think of it. Waterfall has two major benefits: a) it allows for (at least the perception) of being amenable to planning, control, and most of all budgeting; and b) it allows line managers to limit disruption and interruption of their routines and processes to scheduled periods that are under their control. From the functional managers, those are big benefits. You want to sell them on Agile, show them how it makes their lives better, right now, than the alternative. "Better software" won't cut it. Having their most requested features start to show up quickly might.

Also–I think you're asking the right question here. However, there's a LOT of literature in the management field pertaining to this. People have been trying and failing to make businesses "agile" for the last 30-40 years, at the very least. It's not an easy thing to do.