

Analyst calls agile a scam - philthom
http://developers.slashdot.org/story/12/07/14/1242237/new-analyst-report-calls-agile-a-scam-says-its-an-easy-out-for-lazy-devs

======
zaphar
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.

------
biroran
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]

------
jacques_chester
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.

------
briandear
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.

~~~
nimblegorilla
I'd say many products with 500 page spec docs never even get to the release
stage.

