
James Shore: The Decline and Fall of Agile - eaxitect
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
======
alextingle
I love the way this guy explains the failure of "Agile" by simply saying,
"you're not doing it right - you need to be _more_ agile - do it harder!!"

For a counterpoint: [http://www.yosefk.com/blog/extreme-programming-
explained.htm...](http://www.yosefk.com/blog/extreme-programming-
explained.html)

~~~
jdlshore
That's not what I was trying to say, but I can understand why you'd think
that. The deeper point was this: "Agile" started out as a grassroots movement
among programmers. As a grassroots movement, it got enough people excited, and
experienced enough success, that it moved into the mainstream.

Now that Agile is in the mainstream, it's attracting attention from people who
aren't willing or able to put in the effort required to really understand or
do it well. That kind of shallowness has always existed--not just for Agile--
but it used to be that the worst those people would do is publish a blowhard
essay like the "counterpoint" you linked, then go away.

Mainstream Agile isn't so lucky. Now the shallow people don't just flame and
go away. They want Agile, but they don't want to work at it. A particularly
poisonous subset sees dollar signs and starts offering highly dubious
training, certification, and consulting services. Both groups put in something
that says "Agile" on the tin but doesn't actually work.

And, sadly, there are more people interested in quick-and-easy than there are
people who are interested in slow-thoughtful-and-rigorous. They outnumber, and
outshout, the rest of us. As a result, the quick-and-easy (and non-functional)
approach to Agile is taking over, and the original Agile that I got so excited
about is going away. The interesting, motivated, exciting programmers I like
to work with are moving on to other things.

I wrote that essay three years ago. It's even easier now to see a future in
which Agile is just another bloated excuse for managers to treat their staff
badly. That makes me sad, but I'll live, and I'll keep fighting the good
fight.

~~~
gruseom
_"Agile" started out as a grassroots movement among programmers._

That's not true. "Agile" started out as a meeting of methodologists:

<http://agilemanifesto.org/>

Most people there weren't making a living as programmers and they certainly
weren't at the meeting _qua_ programmers. As far as I can tell, only one
person on that list (Ward Cunningham) made a name for himself as a hacker.

It's true that the Agile people wanted to make corporate software projects
less completely hostile to programmers, but it's also true that they were
process-oriented from the beginning, i.e. theorizing about how software should
be built and convincing others to follow their theories. These are people who
make their living writing, consulting, and training, not by writing code or by
being personally responsible for particular projects. This gap between theory
(often dressed as expertise) and practice is IMO one of the curses of the
software industry. Agile may have had some marginal benefit but it also
introduced a whole bunch of new ideology. Certainly this was evident as early
as 2003-2004 when I was spending time in that crowd.

An example of a _real_ grassroots movement among programmers is open-source
software.

~~~
parasubvert
XP, the real catalyst to agile, was born out of the Smalltalk hacker community
with Kent Beck and Ward Cunningham in particular. They're the furthest from
methodologists I could imagine.

The only professional methodologists on the agile manifesto, for that matter,
were Alistair Cockburn and maybe Jim Highsmith. And even they were all about
preaching for less paperwork & process. The rest were in the trenches software
team leads or (at worst) software consultants like Martin Fowler.

~~~
gruseom
I'm talking about people who prescribe rules for others about how to make
software. In this sense, XP is thoroughly methodological. I know something
about the Smalltalk history. It doesn't change the point: there is a gulf
between people who live by selling prescriptions about how to make software
(writing, consulting, training, and so on) and people who live by making
software. This is the fundamental problem with Agile, not dilution-by-
becoming-mainstream as the OP and others say.

Why does the gulf arise in the first place? I think it's because in the
dysfunctional corporate software economy, programmers are low-status and there
is a ceiling on how much money and status can be accrued in that role. One way
to break the ceiling is by becoming a high-end consultant, writing and
speaking and so on. If you pull this transition off, you can charge thousands
of dollars a day and be esteemed. The trouble is that now you are no longer
making software for a living. You are in the world of hype and ideology. Your
customers are people inside corporations who write cheques, a constituency
that has nothing to do with the culture or practice of software. This has
consequences: it casts you adrift, it dulls the mind, it encourages bullshit.
Then the rationalizations begin: I'm trying to make the system a little
better, etc., I can have leverage by reaching more people this way, etc. This
path may lead to billable hours but it puts one at risk of creative rot.

The fundamental mistake of Agile was trying to improve the broken world of
corporate software by selling to it rather than competing with it.

~~~
parasubvert
Ahh, I see the disconnect, based on your last sentence. I basically don't
think it's a mistake to improve corporate software from within. It's not going
away. And there are many decent programmers who will work in that environment
because of a lifestyle choice.

I also think you have an incorrect interpretation of history: the folks who
did XP were contractors on a _project_, and actually writing _code_. Yes, they
published books afterwards, but continued running _projects_ and writing
_code_ afterwards.

Finally, I think the culture and practice of software has a lot to do with
those who write cheques, since that's in the end what funds it, like any
engineering endeavour. Unless you're speaking of software-as-a-hobby.

~~~
gruseom
It's not a _mistake_ except insofar as it's impossible to any significant
degree. It's only self-deception (encouraged by consulting cheques and/or
ideological blinders) that says otherwise. At least that's been my experience
through careful observation.

I'm not speaking of software (only) as a hobby but of the startup community of
hackers building and running their own companies. Look around you here. There
are many people practicing what the word "agile" actually means, as opposed to
these process doctrines. If the Agile processes are really a better way to
build software, why don't most startups bother with them?

~~~
jdlshore
How do you know they don't? Mojang Specifications, this year's hottest new
game studio, uses Scrum. The Lean Startup movement combines customer discovery
with Agile practices.

That said, my experience is that development practices have little to do with
startup success (unless they're overly rigid or formal, in which case they get
in the way of success). They affect organizational scalability and long-term
maintenance costs, which fall in the category of "nice problems to have" for a
new startup.

I do see ideological blinders here, but not the ones you meant.

