A big reason for that is that projects, tasks and estimates are a hell of a lot easier to tack dollars onto than "sprints."
A big part of Agile is "We think this story might take x, but it can take x+y divided across 2n weeks of progress." Unless you have a PMO that can say "Okay, fine, but we're giving you $x to do it, manage it yourself," you'll always fall into waterfall because y is too difficult to financially forecast.
Rally by CA Technologies "solved" for this and gained lots of enterprise adoption somewhat quickly by trying to tack dollars onto sprints; from what I've seen, this essentially created a "scrumerfall" culture where teams have sprints with stories ("functional requirements") that come from epics ("design requirements"), but everyone has tasks and they'd better be estimated with hours.
This is what "Lean Enterprise" tries to address. PMOs should use data from their customers to drive their projects, and projects should be "invested into" instead of "estimated and rationed."
A big part of Agile is "We think this story might take x, but it can take x+y divided across 2n weeks of progress." Unless you have a PMO that can say "Okay, fine, but we're giving you $x to do it, manage it yourself," you'll always fall into waterfall because y is too difficult to financially forecast.
Rally by CA Technologies "solved" for this and gained lots of enterprise adoption somewhat quickly by trying to tack dollars onto sprints; from what I've seen, this essentially created a "scrumerfall" culture where teams have sprints with stories ("functional requirements") that come from epics ("design requirements"), but everyone has tasks and they'd better be estimated with hours.
This is what "Lean Enterprise" tries to address. PMOs should use data from their customers to drive their projects, and projects should be "invested into" instead of "estimated and rationed."