
The Corruption of Agile - ternaryoperator
http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698
======
logn
I'm amused at how the whole Agile community is nothing but a hive mind. For 10
years they're all obsessed with how good Agile is. Then starting two weeks
ago, they all think it's terrible.

Agile works fine. Software engineering methodologies don't kill projects,
managers kill projects.

~~~
mantrax
It's interesting how the community explanation is that some set of perfect
ideals was "corrupted" by consultants. That actually happened fairly early in
the process.

It's the very consultants that are now blamed for corrupting Agile that made
Agile popular. Agile wouldn't be a thing without the feedback loop of the
industry it spawned.

Everyone believed, and one day they stopped believing. It's as if perfect
"Agile" was nothing but a figment of people's collective imagination.

I've always had a skeptical eye about all this. Some useful things, nothing
new, just a fresh coat of fancy buzzwords used to re-invent common sense.

------
greenyoda
It's interesting how Kay's "error-free internet" quote was truncated in this
article. Here's a bit more of the quote:

 _" The Internet was done so well that most people think of it as a natural
resource like the Pacific Ocean, rather than something that was man-made. When
was the last time a technology with a scale like that was so error-free? The
Web, in comparison, is a joke. The Web was done by amateurs."_[1]

[1] [http://www.drdobbs.com/architecture-and-design/interview-
wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442)

~~~
colemorrison
Wow, that's hilarious. Adding in that extra line makes a huge difference.

------
discreteevent
Maybe we should just use Iterative and Incremental Development. Quietly being
practised since the 1950s. Definitely not new or shiny enough to be
commandeered by the hype merchants.

[http://c2.com/cgi/wiki/wiki?HistoryOfIterative](http://c2.com/cgi/wiki/wiki?HistoryOfIterative)

~~~
brianbarker
Iterative development is the only part of agile that's right. Everything else
in agile is just fluff built around this.

------
brianbarker
I really thought Agile was cool. Then I endured pointless meetings,
meaningless planning estimation and observed how people make a career around
preaching Agile. I quickly observed the real goal of agile is not to produce
software, but rather to get people to use agile. Agile is about selling the
cult membership, not actually doing anything interesting.

Not surprised Agile was developed in Utah, the home of the best MLM schemes.

~~~
sadfnjksdf
Ok. First off, there is no "Agile". There was XP. There was Scrum. There was
Kanban. etc. No Agile. Agile originally meant "more dynamic than Waterfall"
and had a connotation of being able to handle change. If you've never worked
on a large Waterfall project, which many of you haven't, you just don't
understand how bad it was.

And unlike others have said in this thread it has not been around for 10
years. It has been around for almost 20.

Why "Agile is what it is" is because no one could stomach the proper way to do
these individual methodologies, so they just dropped process altogher and
called it Agile. Then on the other side you've had loons for several years now
selling certifications.

Don't diss on Agile. There is no Agile. There are remarkable methodologies
called XP, Scrum, Kanban, Lean, etc. and great people and histories behind
them. Read and learn about them.

~~~
brianbarker
Right, Scrum. That's the one I hate the most.

~~~
kps
Scrum is micromanagement collectivized.

~~~
sadfnjksdf
Doing things in a list which allows reorder, choosing which items in that list
will get done per time period, and communicating that in short time periods.
That is a methodology of management which embraces change, not
micromanagement. Scrum doesn't micromanage, managers do. If you are being
micromanaged, quantify the overhead of meetings and planning vs. the amount of
time being derailed or working on things that wouldn't have been prioritized.
You may get more done without management, but is what you are getting done
what needs to be done? That is what Scrum is about.

I think XP's original stories and tasks on note cards in planning meetings
were a better way to shorten tasks than Scrum leaving that open though- time
estimation can be a problem in Scrum without proper planning.

------
mildtrepidation
So much of the rhetoric surrounding 'Agile' is, as stated in the article,
'Waterfall'-bashing. But I don't subscribe to the idea that the actual
original intentions behind it are somehow infallible or even necessarily
helpful the way the article and so many proponents do.

I've been involved in half a dozen projects that adopted varying sorts of that
process, from small teams to massive juggernauts, and never once have I seen
it not result in people tripping over each other or railing against the
process.

Were those the result of poor implementation? To _varying degrees,_
absolutely. But these and similar experiences from many people I know, coupled
with the alarming degree of "if it's going poorly they're doing it wrong" from
proponents, leave me with the firm conviction that this isn't just a
constantly-abused practice. It's a set of tenets that apparently worked in
principle for someone at some point but simply are not suited for the projects
and environments I've encountered or discussed with colleagues.

People will dismiss that, which is fine (anecdotes are anecdotes, even in
quantity), but I'd call such a range of practical failure pretty damning for
something that's supposed to be so enabling.

------
thibauts
If Agile is the ability to respond to change then it's obviously a matter of
good _craft_ because software has never been made pliable with a magic
methodology wand.

Of course you'll never hear a consultant talk about that, because there is no
shortcut to good craft. So they'll usually resolve to violate the root
principle of Agile upfront and focus on tools and processes rather than on
individuals and interactions.

~~~
collyw
"If Agile is the ability to respond to change then it's obviously a matter of
good craft because software has never been made pliable with a magic
methodology wand".

To me this would suggest a good design in the first place, rather than a load
of automated tests. Maybe waterfall is more agile than agile...

~~~
dragonwriter
A major motivation of agile is the ability to respond to change in
requirements occurring during the time between project initiation and 1.0
release.

This kind of change is, experience has shown, a major source of the
"requirements problem" which was noted as far back as the 1970s.

Waterfall methods (except, perhaps, the small unit of work iterated waterfall
approach that is sometimes seen as a way of being agile and often criticized
by practitioners of, particularly, Scrum as not-agile) aren't equipped to deal
with this kind of change.

But Agile isn't a set of methods, it's an approach to selecting methods. So,
it's possible -- though perhaps unlikely -- that for certain teams in certain
circumstances Waterfall is more Agile than, say, Scrum or XP.

------
MAGZine
I think it's important to realize that this isn't saying that agile is bad,
which is definitely the tone I get from some of these comments.

There is a difference between agile (i.e. the root of agility) and Capital-A
Agile. Keeping in mind the key tenants of agile (little a) software
development, it states `Individuals and interactions over Processes and
tools`. This is the key difference between agile and Agile and the author is
writing about. Yes, TDD is generally viewed as favourable, but itself is just
a process and a set a tools (or methodology, whatever name you want to attach
to it).

All agile is about is making working software and responding to change in the
development process (and making changes quick/often). Has "agile" been
corrupted? Yes (into the marketed "Agile".) Is little-a agile it a bad thing?
No. I don't think anyone is saying that.

~~~
zedshaw
I'm sorry but every time I hear someone go "[a]gile is SOOOO diferent from
[A]gile" I also hear that same person pushing the same agendas and doing
following the same practices based on zero evidence for their efficacy.

This whole "little-a vs big-A" is just another way for people to keep pushing
the same thing they've been pushing to make money rather than admitting it's
time to move on and admit Agile didn't work. Same as the "Scrum-but vs. Scrum"
people and the evolving manifestos the Agile guys produce:

[http://agilemanifesto.org/](http://agilemanifesto.org/)
[http://jchyip.blogspot.com/2010/06/kent-becks-evolution-
of-a...](http://jchyip.blogspot.com/2010/06/kent-becks-evolution-of-agile-
manifesto.html)
[http://manifesto.softwarecraftsmanship.org/](http://manifesto.softwarecraftsmanship.org/)

Just people trying to keep their agile consultancies afloat after screwing
people over for years.

Signed,

Zed of [http://programming-motherfucker.com/](http://programming-
motherfucker.com/)

~~~
dreamfactory2
FWIW this article and the Dave Thomas one are actually making that distinction
and promoting the manifesto. Agile delivery (by which I mean the 4 line
manifesto and not Scrum etc) has always worked brilliantly for me and the
teams I've worked with.

------
davidrudder
The "error-free Internet"? Really?

The truth is that most engineers are aware of what Agile is. It's a series of
principles used to run a software development project. Agile isn't a set of
tools or a movement or a methodology. It's only people who are selling tools
or books or a viewpoint that talk like this.

From the trenches, I have never worked in Agile. I've worked with "agile" and
I've worked in teams organized using agile principles. But, the orthodoxy has
come from consultants, who were quickly shown the door.

~~~
ternaryoperator
"error-free Internet" is a fair description. Given suitable hardware and a
connection, you can reliably send email, access Web servers, run Web services,
regardless of distance. The errors, if they occur, tend not to be a the
software level.

~~~
bcoates
That's fault tolerance.

~~~
ternaryoperator
which would be wholly unrelated to software ;-)

------
andrewcooke
i don't know if this helps anyone, but it's vaguely related to the article. if
you're read taleb's "antifragile" then you can think of agile development as
"antifragile development". and if you do that, and understand the difference
between antifragile and merely robust, you can see what "parts" of agile make
most sense.

from the article (my emphasis):

> Agile was a personal practice. Implicit is a personal way of orienting
> oneself towards a development process that accepts, even _welcomes, change_.

------
dreamfactory2
Talking of ignorance of the history of development practises, I can never
believe it when I see people promoting 'waterfall' as if it were somehow a
legitimate practise and hadn't been coined as a pejorative term to describe
what was wrong with software development. The fundamentals of agile have been
around for a long time and the manifesto was an attempt to formalise what had
worked well.

And as for these old systems for airlines etc (which took many thousands of
man days to produce), I wouldn't be shouting about them as great shining
examples. Anybody who has had to integrate with these systems will be aware
that they tend to be junk under the hood and they tend to fall apart if you
throw internet levels of traffic at them.

From this article, I have to wonder when the writer last coded if ever. (I do
however agree with the point that the 'agile' industry is a mess and that
scrum in particular is often nearer waterfall than agile.)

------
bcoates
Are there serious descriptions of these good-old-days software methodologies
that the kids these days with their agile and their hippety-hop are
corrupting? The story I've always been told is that 'Waterfall' is a
pejorative invented by software methodology pitchmen to describe the ad-hoc
process you get when you ask an MBA to build a software shop.

As someone who's had a little bit of exposure to 20th century code, I'm not
terribly impressed with it. It's neat that they managed to get anything at all
done on such primitive hardware, but incredible feats of performance hackery
isn't the same thing as software quality as we know it.

Someone explain to me the lost methodology of these programmer-Titans who made
this "truly excellent, reliable code"?

p.s. Since when was the Internet a software product?

~~~
dragonwriter
> Are there serious descriptions of these good-old-days software methodologies
> that the kids these days with their agile and their hippety-hop are
> corrupting?

Yes; the references in the Wikipedia article on the Waterfall model [1] are
good place to look.

[1]
[http://en.wikipedia.org/wiki/Waterfall_model](http://en.wikipedia.org/wiki/Waterfall_model)

~~~
VintageCool
Per the Wikipedia article, the term "waterfall" has always been pejorative. It
was first described in 1970 as "this is a software development model which
doesn't work". Everyone that has ever sold a commercial software development
methodology has sold it as "not waterfall".

~~~
dragonwriter
> Per the Wikipedia article, the term "waterfall" has always been pejorative.

That overstates what the Wikipedia article claims, which itself misrepresents
the sources the article cites (e.g., the article it cites as the first use of
"waterfall" does not use it in negative sense; it uses it descriptively --
while it does discuss the existence of a quality-of-requirements problem in
software development (investigation of whether that perceived problem was real
is the point of the paper), it doesn't place the blame for it on the waterfall
model.

Anyhow, my point upthread was that the sources cited in the article themselves
are good if you want to understand the model of the time. (From those, it also
looks like another good source would be MIL-STD 490 and/or MIL-STD 483, but I
haven't had any luck finding them, the closest I've been able to find is MIL-
STD 490A, which replaced 490 in 1985.)

------
timrosenblatt
There are so few things in life that are hard-and-fast rules. Agile is a bunch
of guidelines that should be adapted, and the core Agile Principles say this
themselves.

It's like a religion. Some folks like guidelines, some folks like rules. :)

~~~
kps

      > It's like a religion.
    

A bit. But the Church only makes you confess once a _week_.

------
harrystone
>You do not need a consultant to show you how to do that.

Is it any wonder that consultants have turned it into something that they need
to show you how to do?

------
zenbowman
Love that Alan Kay quote. I've used it in almost every presentation I've
given. History is a wonderful thing because it teaches us humility, as it
makes us realize the giants on whose shoulders we stand, and together with
that it teaches us what not to do.

------
ThinkBeat
Now its "Lean".

~~~
ebiester
The two overlap, but aren't the same thing.

~~~
dragonwriter
Lean is more concrete (there is a high-level metamethodology that you can be
doing or not doing), while Agile is more abstract principles (although it
often gets confused with specific low-level methodologies).

I'd argue that Lean as a metamethodoloy is probably the best concrete approach
to realizing Agile principles (even though it didn't grow out of those
principles, exactly, though it comes from a conceptually closely related
place), including the avoidance of getting locked into a methodology, since
Lean includes continuous review and improvement of process.

~~~
ThinkBeat
When an idea for running a project that is based on making it as easy as
possible to use and waste as little time as possible.

Having to use a term like: "metamethodology" is crazy.

Check out [http://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/) for a reality
check about Agile from one of its inventors. I quote:

"However, since the Snowbird meeting, I haven’t participated in any Agile
events,1 I haven’t affiliated with the Agile Alliance, and I haven’t done any
“agile” consultancy. I didn’t attend the 10th anniversary celebrations.

Why? Because I didn’t think that any of these things were in the spirit of the
manifesto we produced. Having conferences about agility is not too far removed
from having conferences about ballet dancing, and forming an industry group
around the four values always struck me as creating a trade union for people
who breathe.

And, unfortunately, I think time has proven me right. The word “agile” has
been subverted to the point where it is effectively meaningless, and what
passes for an agile community seems to be largely an arena for consultants and
vendors to hawk services and products.

So I think it is time to retire the word “Agile.”

