Here's how I see it: if dev teams have the capability to reliably release working software at any time, and can sustain that for years, then being agile becomes entirely a business decision.

But if the dev team can't, then it makes little difference what the business decides.

Let's look at a Venn diagram

And if you work backwards from "reliably release working software at any time, and can sustain that for years", you get #CodeCraft. It's the secret sauce, and most businesses don't have the recipe.
@jasongorman heh very true, although I would emphasise that dev is part of the business and most commercial people are not used to working in an effective way with an Agile dev team to enable an agile business. I think it’s better to be proactive in helping the business be agile if that is at all feasible. A couple of reasons why: a) Developing software no one uses is really depressing b) Successful businesses pay developer salaries not Agile engineering practices.
@jasongorman semi-counter: this business (people) often forces rules on the software team that reduces agility.
http://webseitz.fluxent.com/wiki/ProjectOrientedRoadmapsAreCounterProductiveForSoftwareProductTeams
Project-oriented Roadmaps are counter-productive for Software Product Teams

Project-oriented Roadmaps are counter-productive for Software Product Teams

WebSeitz
@jasongorman I wonder "if dev teams have the capability to reliably release working software at any time, and can sustain that for years" what do they change to become agile? Working software does not mean "software with improved usefulness" of course, but I am convinced that no team has trained and is capable releasing working software at any time if they would not have the need to release often