1. I do agile at work :-p

I write some code and we release it next week. Our manager prioritizes work for us and protects us from the rest of the company.

2. I don't do agile at work

We don't have stand up meetings, There is no KanBan nor User Stories, We don't pair program unless we feel like it.

Take your pick both are true.

The article (the one inside) simply says that one size doesn't fit all.

Agile (or, as I like to call it, short and iterative waterfall with priority management and pipeline solution), fits some scenarios well, but not others.

It fits startups because it's quick to release. It fits non-scientific products (or non-algorithm heavy products) as features can usually be contained in a single sprint or easily broken into deliverables. It fits huge products on maintenance mode when most of the development are customer features and issues.

However, it doesn't fit algorithm-heavy products (algorithms are usually "one-go" and require a sustained effort), it doesn't fit big products during intense development (architecture can't be ignored or it'll crumble under the product weight), it doesn't _always_ fit corporate environment (because of "impedance mismatch").

[very personal opinion, flame-shield on]

It fits average developers since it maximize oversight, reduce the time an error has to propagate and forces the work to be split into manageable, chewable parts.

It doesn't fit great developers ("distinguished", "level 4", "star"...) because, just like any other artificial framework, it hinders creativity and the free flow of code. On the other hand, a great developer is also measured by his/her ability to ship - which negates the need for such artificial systems.

[/very personal opinion, flame-shield on]

The relevant parable: http://www.ckwop.me.uk/Meditation-driven-development.html

Looking at the Slashdot, there's a lot of No True Scotsman remarks turning up.

Saying whether agile "succeeded" or "failed" requires a number of things. You need to define "agile" (good luck) and then define success or failure (good luck).

Then you need survey respondents who can answer those questions accurately (good luck) and honestly (good luck).

Perhaps you could come up with a list of practices and indicators that show how "truly" agile a company is. Call it the Agility Maturity Model, and ...

Oh drat, I just reinvented pre-2000 software engineering literature. They'll kick me out of the cool kids club for this.

That analyst can go suck an egg. The majority of startups these days use some form of Agile. As far as 'developer backlash' -- you're damned right: backlash against 500 page spec docs that are, for the most part worthless the second the software is released.