

Erik Meijer: AGILE must be destroyed, once and for all - redknight666
http://www.theregister.co.uk/2015/01/08/erik_meijer_agile_is_a_cancer_we_have_to_eliminate_from_the_industry/?mt=1420720905092

======
ctb_mg
A few interesting points I would note:

As the article states, Agile has been abused so much, most things claiming
that they are "Agile" or related to Agile are actually not fully in spirit
with the Agile Manifesto.

Scrum is great to allow teams of mediocre engineers to improve over time, and
eventually perform way beyond what they would under traditional command and
control management. Scrum fosters a lot of communication which is one way you
can develop immature software engineers.

Scrum teams that have Rockstar coders, who want to just code and get things
done, have a significant human issue. The Rockstars have to spend time talking
to less knowledgeable engineers, to facilitate knowledge spread and get the
other team members up to speed. To software engineers who just want to Write
Great Software, meetings for syncing up with your team are something that gets
in your way. A great ScrumMaster would manage the Rockstar coders in such a
way that they produce code but also understand the need for knowledge
transfer.

------
shepardrtc
Pretty sure he's mad at Scrum and not Agile. The article describes the
difference.

Of course, he's living in a fantasy world where there is no politics in
business and no slow-moving management. My company used to be wholly Waterfall
and now they're slowing moving toward Agile/Scrum. To say that its actually
improved things is an understatement. Is it the best method possible?
Certainly not. But good luck convincing upper management (of a non-startup)
that some non-quantifiable method will bring greater productivity and faster
turn-around times. Agile/Scrum is a solid "thing" that you can present to
upper management and show them case studies on. They can get behind it and not
worry about looking foolish for following some developer's pie-in-the-sky
utopic vision (hey, let's get everyone on Linux workstations while we're at
it!).

That being said, Agile/Scrum is not the final destination, its simply a step
in the right direction.

------
someengineer
The point the article is making is that all the problems the anti-agile crowd
complains about are less related to agile and more to a dogmatic adoption of
specific tools. I think the point the author misses is the irony of the whole
thing. The anti-agile people get annoyed at something like religious demands
for 100% unit test coverage, so they instead adopt their own extreme, narrowly
focused rules like refusing all TDD. This is how flame wars work.

I've seen agile methods be most effective at companies where software
developers are a minority. Scrums and sprints can be very useful when you've
got many outside interests hammering at you for various feature requests and
bug fixes. Done right, it keeps the software group's priorities aligned with
the company's.

------
poseid
agree - TDD and stand-up meetings push software development rather into
politics than science.

~~~
ctb_mg
Test driven development to my knowledge is only mandated in one major Agile
Framework, and that's eXtreme Programming. Individual Agile implementations
may use TDD, but it is not mandated directly by the Agile Manifesto.

XP has a very low adoption rate (1% [1]) ; my guess is because it does things
like mandate engineering approaches (TDD, pair programming, etc).

So to state that TDD causes Agile implementations to be more political than
scientific, and therefore all Agile should be eliminated, is not 100% accurate
(ignoring the assumption that TDD is more political than scientific)

[1] VersionOne's 8th annual state of agile survey.
[http://stateofagile.versionone.com/](http://stateofagile.versionone.com/)

~~~
ramy_d
Wow, I'm surprised to read the adoption rate of XP. It seemed for a time
everyone was all about that.

------
geebee
Here's what I always believed was the original manifesto

[http://agilemanifesto.org](http://agilemanifesto.org)

While I don't see any specific mention of stand up meetings or scrum masters,
I can see how these things emerged from the initial concept. The idea, as I
always understood it, was that the massive up-front design of the waterfall
method would be replaced with a highly collaborative and iterative process
that turns developers into members of a team rather than far away people who
receive a spec flung over a wall. I found the approach very promising when I
first read about it.

Unfortunately, at this point I have to agree that the term "agile" almost
always refers to processes and tools, though they are inspired by the original
manifesto. Problem is, those processes and tools are often applied in a way
that longer accomplishes the original goal - and in many ways amounts to a
"bait and switch" on developers who thought the process would be collaborative
(and are the only ones who didn't realize one of the tools and processes of an
agile project is "CYA").

Daily standups, for example, did seem like a good idea to me at the start, and
handled right, they still could be. If you're going to do iterations and
respond to change, and place less (or no) emphasis on a massive spec, it's a
good idea to stay in constant communication.

But to me, "agile" turned out to be a mass scale bait and switch. Daily stand
ups lost their value as a quick check in with everyone to see what issues have
arisen. Deadlines still loom, daily stand ups involve project management
software shown on a large overhead projector, and developers asked for status
reports based on estimates made on fuzzy tasks with limited information
(because the developer thought they were being "agile"). Daily stand ups often
morph into a daily application of pressure about why deadlines aren't being
met. There's a contract (the project plan), just one that wasn't properly
negotiated.

To me, the clearest sign of the corruption of the agile manifesto is how
"Customer collaboration over contract negotiation" happens. Many of us aren't
specifically dealing with external clients and formal legally binding
contracts, but if there is project management software with tasks,
assignments, deadlines, and estimates, all with names (perhaps your name)
attached, trust me, there is a "contract". You are a party to this contract.
Litigation is replaced with status meetings with your manager and perhaps a
disgruntled stakeholder who may very well hold a copy of the project plan
(ie., contract). It's unpleasant, you don't want to be in this spot. If a
contract is inevitable (again, presence of project management software with
tasks, names, and deadlines = contract), you'd better negotiate it.

I still think that for many projects, the ideas behind "agile" really would to
lead to better software. But a lot of supposedly "agile" projects are just
waterfall projects involving a daily status report. If that's the case,
honestly, I'd rather just do a waterfall project and be open to it. If someone
is going to hold my feet to the fire about exactly what was done and when, I'm
going to want them to specify exactly what needs to be done, and if things are
unclear or I need more time to research, I'm going to want that _in the
contract_.

