[justinkramp]

>as we have already seen it corrupted into anti-Agile in the enterprise

I've definitely experienced this. A large waterfall development group decides to call themselves Agile. They start proclaiming their mutant fast-waterfall as the One True Agile, adopting terms and structures to appear Agile.

Then you get invited to the hour-long "standups" attended by dozens of un-involved people, "stories" that amount to poorly worded system requirements, "grooming sessions" filled with chickens and "sprints" with development/release cycles that look oddly similar to what we had before they started calling themselves Agile.

It's just a rapid waterfall. Call it "rapid waterfall," or just keep calling it "waterfall" and increase your velocity. It confuses things when people that have worked in Agile shops come around and try to understand what you're doing.

Sidenote - I'd probably title the article "How a ten-person team moved a government agency forward twenty years in two days."

The permalink says "spring" so "sprint" is an improvement on the draft title anyhow. :)

[tbrownaw]

But despite the piled-on bogosity, it still achieves some measure of incremental development. And because of this, it also achieve some measure of flexibility.

Which are two of the main benefits of Agile (the third being efficiency due to process refinement).

So as far as enterprisey stuff goes, it's really not that (relatively) bad.

[justinkramp]

You're right, it's not that bad from a delivery perspective. We're getting some stuff faster than before. To some degree my frustration is in the semantics. It does get practical when bringing someone onboard who has worked in a traditional Agile shop and it's like re-learning everything to figure out what we're doing.