
Seven Things I Hate About Agile - mpchlets
http://blog.assembla.com/Seven-Things-I-Hate-About-Agile/
======
DanielBMarkham
I usually vote up Agile attacks, because I love to hear developers talk about
the difference between good and bad Agile.

But it's getting a little old. It seems the world is full of cranky, half-
informed folks who get a little coffee in them and suddenly are ready to make
grand pronouncements about the entire state of things (Love the self-recursion
here)

Seriously, one last time. Agile is best practices around iterative and
incremental development. It's not a standard, it's a marketing term. Because
it's not a standard, criticizing it is like criticizing "good ice cream".
What's good ice cream? Any damn thing you'd like it to be. Perhaps the author
has a larger criticism of how stupid we all can be when implementing change.
If so, get in line. There are a lot of us.

Scrum is a standard, and it's not changing anytime soon. You can call that a
good or bad thing, but it's a very small subset of Agile, so it sounds more
like a separate topic to me than the entire world of Agile.

I hate the way we implement change in technology organizations. Part of the
problem we have, unfortunately, is that everybody feels themselves an expert
on stuff they read about in a book and maybe saw it done badly a couple of
times.

The more I think about this article, the more I feel like it's 95% marketing
and 5% fluff. Apologies to the author if they are serious, but something is a
bit off here. Not worth flagging by any means, but I'm not upvoting it.

ADD: Bit of a meta-note. Just this morning I wrote a story on some ideas about
how to handle Subject Matter Experts in Agile teams. (shameless plug:
[http://www.whattofix.com/blog/archives/2012/08/who-moved-
my-...](http://www.whattofix.com/blog/archives/2012/08/who-moved-my-sm.php) )
The use of the word "Agile" in my article was very useful: it identified the
topic as best practices around SMEs in iterative and incremental work. It is a
dry topic, and I didn't claim to have all the answers, and it was more
narrowly-targeted, so it didn't get a lot of traction. That's understandable.

But what I see happen over and over again is that wild hand-waving criticisms
get a lot of traction on place like this because they can emotionally engage a
larger audience. Practical targeted stuff? Not so much. So for the average
developer who's just out of school and never has worked on an Agile team? I'm
not sure they're receiving a very balanced look at things if all they read are
from places where things are voted up or down based on emotional impact. It's
another interesting and counter-intuitive side-effect of the voting/ranking
system.

~~~
igouy
>>What's good ice cream? Any damn thing you'd like it to be.<<

Therefore -- What's Agile? Any damn thing you'd like it to be.

~~~
drumdance
Eh, maybe. You could not offer "good ice cream" for sale and instead deliver
cookies.

~~~
zaphar
Unless you go to a molecular gastronomy restaurant where they are as likely to
serve you good ice cream in the form of a cookie or a cookie in the form of
good ice cream.

But yeah I see what you mean and in general agree with you.

------
peeters
> Pair programming is like those girls that go to the restaurant bathroom
> together. What are they doing?

Why don't you ask somebody who pairs, rather than writing an uninformed rant
against it?

> If you are customer, you pay twice as much and you get churn.

Oh I get it, you're approaching and commenting on all of Agile from your
software-as-contract-work perspective. Let me enlighten you: most software
isn't sponsored by a single customer on a per-diem basis. But while we're
here, let me say this: if you truly think you get half the productivity from a
pair, then you fundamentally misunderstand the gains of pairing.

> I recommend a more efficient alternative – review pairs. Person A and person
> B use a code review system to review each other’s code before release. You
> get the same benefit without the neck cramp and the BS.

There is more to benefit from pairing than just on-the-go reviewing. There is
also the fact that you retain your focus much easier, you spread technical
knowledge when you shuffle your pairs, etc.

But on the subject of reviews, your reviews are also much better because they
benefit from FULL context, and the suggestions and modifications are made
EARLIER (which is much less expensive than getting to the point of being ready
to commit and having to refactor everything).

Oh and about the neck cramp remark: do you really expect your devs to pair
without having mirrored monitors, two keyboards, etc?

~~~
JoeAltmaier
Pair programming reminds me of the issue of trying to pair up for video games.
Either you find somebody much better than you, or much worse. Because the
spectrum is large, the chance of a good match is nil.

In programming the spectrum is larger. When I've been asked to program with
somebody, its always been a terrific drag on my productivity. I crawl thru the
day, trying to be nice, and when they go the hell home I stay late and do my
real work.

~~~
wpietri
I like to pair with people who are as good, but I'm also happy to pair with
people who are much better or worse.

When it's somebody much worse (e.g., somebody new to my code base) then I'll
spend a lot more time driving. As they see what to do, they jump in. Sometimes
I'll force them to jump in regardless, so that they learn by doing.

That's a short-term personal productivity hit, but for me it has always been a
long-term team win. There's no faster way to get somebody up to speed. And the
sooner they learn The Right Way to do something, the less I'll have to clean
up their novice WTF-bombs later.

When it's somebody better, that's pure fun. I learn a ton, I get to see
somebody good at work, I pick up tricks, and I end up with a detailed
understanding of a colleague's strengths.

~~~
rhizome
In a pair-programming context, what does "my code base" mean?

~~~
wpietri
Good question. I could better have written that as something like "my team's
code base".

------
mindcrime
So who the hell are Assembla and why should anybody care what they have to
say? All I'm seeing here is a lot of misinformed ranting. Sure, there's a
kernel or two of truth hidden away in there, but most good rants have that. I
don't see that TFA makes any sort of interesting point or arrives at any real
conclusion that's helping anybody make a decision though.

Oh wait, I'm almost 40, so I guess I'm too busy decaying into compost to know
anything about this stuff. Never mind me..

~~~
ryanmolden
Yeah, I stopped reading at "Old People", and I am not even in that
demographic. Wholesale discounting all wisdom in an entire segment of people
with lots of experience in the very field you work in is rarely a good idea. I
mean what's up with Knuth being so old? Some young guy should finish out TAoCP
and show him how its done.

~~~
mikegirouard
Agreed.

It looks like the author was getting some heat for that point.

[http://blog.assembla.com/assemblablog/tabid/12618/bid/87899/...](http://blog.assembla.com/assemblablog/tabid/12618/bid/87899/Seven-
Things-I-Hate-About-Agile.aspx#comment179715)

If you take him for his word, I'm sure he didn't mean anything by it (he says
he's in that demographic). But I can't say that I'd let him off the hook that
easily. Off-hand comments like this almost always come back and bite hard.

~~~
protomyth
"Off-hand comments like this almost always come back and bite hard"

If he has influence over hiring / firing, the first age discrimination suit is
going to be fun. Stupid blog or e-mail comments give lawyers way too much
ammunition in hostile workplace claims.

------
jaimzob
I'm not a big fan of agile either but "over 40" == "the smell of death"?
Seriously? Not a convincing, or classy, opening line. And this was posted by
the _CEO_ of Assembla.

~~~
lemmsjid
At first I thought it was an attempt at humor, but it wasn't! It's funny how
if you take the prejudice away it actually makes the opposite point he's
trying to make, i.e.

"Do you notice how as people get more and more experience in the industry they
start to gravitate more towards agile processes?"

------
bguthrie
Pair programming was invented and evangelized by developers, and are its most
ardent defenders at every vendor I know that offers Agile services.
ThoughtWorks' sales folks hate selling pairs, for the obvious reason that most
clients don't love the idea of buying them.

~~~
plinkplonk
Even ThoughtWorks has/had developers who don't particularly like or believe in
pair programming, but go along because it comes under the company's proclaimed
orthodoxy umbrella most of the time. (ex TWer, so I know whereof I speak).

I used to champion pairing when I used to work at TW, and used to be puzzled
at why some (very talented) TW developers thought it was all hogwash, but TW
is a fine company in many ways and you eventually learn to tune out the
extremes of the company's (Roy's ;) )eccentricities and get on with the work.
You need to do this at any company, nothing specific to TW really.

In many teams, pairing is loosely practiced.In others, 100% pairing is the
norm. So it all depends, even at TW.

That said, you have a point in that TW has some very strong and vocal
proponents of 'pure' pairing. I used to be very gung ho about agile dev when I
was at TW. These days I know better.

just my tangential 2 cents, and not really contradicting anything you said,
just qualifying it a little.

~~~
shaydoc
I would say 100% pair programming would be a highly draining experience! may
result increased productivity, but at what cost!

------
ionforce
I like how the opening point is ageism. Really classy.

~~~
asinglenet
Author here - I can make an observation about old people because I myself am
49 years old. I'm not making a value judgement about older people. That would
be ageism. I'm observing that the attendees "agile" events tend to be older
than most programmers, and even most IT staff. That's just demographics. Why
is that? That affects a lot of things.

~~~
raganwald
_I can make an observation about old people because I myself am 49 years old_

That doesn't make any logical sense. All that suggests is that you have n=1
experience with people over the age of forty.

As for observing that agile events in your neck of the woods are full of older
people, there are many, many possible explanations for this and your blog post
advances one without providing evidence that it is anything other than
confirmation bias.

One thing _I_ would do before making a statement like that is attend some
other methodology events and check out the ages. If you go to a CMM
conference, how old are the people? How about a PMP Institute gathering?

You may find that older people are more interested in methodologies while
younger people are more interested in technologies. You might not, but your
essay does nothing to establish that your explanation carries more weight than
my conjecture.

And if my conjecture is correct, your point really should be that "Excessive
interest in methodologies has the smell of death." That might be true!

I am not saying you're wrong, only that your essay is not persuasive on this
one point.

~~~
asinglenet
I don't make a conjecture about the reason that agile events skew to an older
crowd because I really, really don't know why it is true. I do know that it
changes the whole perception of the effort. So, I have to be careful when I
use the word "agile". It's got a demographic implication that isn't positive,
isn't "us" for many younger people. You can argue about the wisdom of my
saying it this way, but the word has a real demographic and emotional
association. This article is a chance to express my doubts about the word
"agile". It's done. I'll be more positive from here on out.

CMM and PMP are basically anti-agile. They are useful, but useful for projects
that just shouldn't be agile. The fact that agile events attract a similar
demographic isn't a positive, in my opinion.

~~~
raganwald
_It's got a demographic implication that isn't positive, isn't "us" for many
younger people_

Compared to what, exactly? What development management practices do have an
"us" demographic for younger people? One possibility is that you will reply
and name one or more named practices with a "young" demographic, and I will
accept your point.

The other possibility is that there really isn't a development management
practice that has a "young" demographic, that young developers just aren't
into spending a lot of time thinking about practices.

If the second case is true, I really believe it undermines your point. If
young developers don't really align towards any particular named repeatable
practice, Agile is no better and no worse than anything else on account of the
age of the people interested in it enough to attend events. It isn't worth
"hating" agile for its lack of traction any more than hating PERT charts or
Theory of Constraints.

------
jhuckestein
I agree with there being lots of old people in the community of agile-
enthusiasts. My theory is that this is because most young people have never
worked for a large company with lots of top-down processes and agile is just
the default/what comes naturally.

This is somewhat similar to the issue of the Cathedral and the Bazaar in
software engineering. Most young people have never even seen a Cathedral and
just consider the Bazaar model the default.

Edit: No offense to anyone in that demographic btw. I have great respect for
everyone involved in that community, I just don't think it is very interesting
for kids that never knew anything else

------
USNetizen
Statistically speaking, the "young" startup founder is a complete stereotype.
The over-50 crowd which this article refers to as "having the stench of death"
actually starts and runs more successful startups than the under-30 crowd. So,
to be fair, those "hot" startups you love, that have a business plan worth
more than just "build it and they will come" in it, are most likely run by
someone over 40.

Also, anyone that knocks "Agile" has not had much experience in the enterprise
sector. Yes, it has overhead - but in a larger (500+ employees) company that
overhead is absolutely crucial to maintaining uniformity amongst all divisions
and ensuring all "players" in the game are on the same page.

------
S_A_P
I cant decide if this article is sarcasm or not. It makes me think about how
there is no methodology that is the savior of developers everywhere. You may
be able to find some operational efficiency choosing one methodology over
another, but at the end of the day you either have developers that can write
the code, or not.

~~~
augusto_hp
I really think this guy have had some very annoying situations on agile-teams.
At least it is what pops the most out of the blog post.

He actually contradicted himself a lot of times: \- "old people": Being a
developer for a relatively small period of time, but I really have a hard time
talking about agile with old developers. At least is what happens here at São
Paulo/Brazil. \- "stagnation": Agile is not Scrum. How about XP, TDD, etc? He
says there is not much action in agile-world by arguing that people spend
their time making lots of non-agile tools. Without a proper explanation of
what he is talking about it is almost hopeless to try on and get something out
of this point. \- "Imposing values": Contradiction again. First he complain
about having to accept values. He even say that values are not important at
all to productivity and collaboration by saying that _goals_ are important. I
may be wrong here, but _goal_ could quite easily be considered a _value_ in
the same context.

I won't even continue on this list since I am just probably pissed with the
whole thing, but I really would like to have a discussion on this to see in
what page we find ourselves.

It is really sad to just read complains without any solutions or proper
presentation of the problems. It makes everyone who really put some grasp on
agile teams or tools look like a moron by offering a mysterious solution. It
just looks like a TV show to me, not a tech or even a blog post.

~~~
smattiso
Hey I am trying to recruit good devs in Sao Paulo, but I am kind of clueless
where to start. If you get a chance I would love to chat. Cheers. My e-mail is
stephen@lightboom.com

------
protomyth
"Old People"

I find an interesting contrast between his conclusion on Agile conferences
versus my 42 year old self. He sees a lot of old people and concludes this
must not be a good thing. I see a lot of "old" people and conclude my elders
might have learned something over their careers which I might get a leg up on
by listening to what they value.

I wonder how many lessons older programmers learned in the resource
constrained 8-bit or mini-computer days could have help some of the youngster
programming these smart phones?

// for a comedic take on youth <http://www.youtube.com/watch?v=UKUZ42T9diU>

------
pacala
The thing that doesn't work for me in Agile: being treated like a baby and
spoon fed little bits of work with little room for responsibility, initiative,
creativity and a personal touch. Agile is great if you are a mediocre manager
and you want to run a place full of replaceable cogs, but not so great if you
want a place that pushes the boundaries and consistently goes the extra mile

~~~
jschuur
To a certain extent, agile tries to narrow the scope of a sprint, in order to
ship more rapidly. For people that have a grander vision of what they want to
build this may seem narrowing to constantly be reminded of the MVP. If the
product you're creating is a commercial thing, or just something that will
thrive based on its adoption in the marketplace, feature creep can be
damaging, and it's helpful to have someone keep you focused on making that
next shippable version.

That's inevitably going to piss some people off who are bubbling with ideas
and want to implement them all. As a product manager with an active
imagination, I've been in that situation, and I'm slowly recovering :)

~~~
pacala
Agile

A play in 3 sprints

Characters

A: rockstar developer

B: developer

C: intern

===== Sprint 1 ======

A: To a certain extent

B: agile tries to narrow

A: the scope of a sprint

A: in order to ship more rapidly

B: For people that have a grander vision

B: of what they want to build

===== Curtains, ship iteration 1 =====

===== Sprint 2 ======

A: this may seem narrowing

A: To be constantly reminded of the MVP.

A: If the product you're creating is a commercial thing

B: or just something that will thrive

A: based on its adoption in the marketplace

B: feature creep can be damaging

===== Curtains, ship iteration 2 =====

===== Sprint 3 ======

A: and it's helpful to have someone to keep you focused

A: on making that next shippable version

B: That's inevitably going to piss some people off

C: who are bubbling with ideas

A: and want to implement them all.

C: As a produce manager with an active imagination

A: I've been in that situation

B: and I'm slowly recovering

Chorus: :)

===== Curtains, ship iteration 3, move on to the next project =====

------
leothekim
I dislike agile and scrum not because I think they're bad ideas - in fact,
there are some good ones in there. The problem is they're so doctrinaire. A
"manifesto", scrum masters, agile consultants, etc are all there to enforce
processes that don't always make sense for any given team or organization, and
they detach you from the reality of actual productivity. Didn't assign the
right number of points to your scrum story? Didn't break things down into
tasks properly? Velocity fail? If these are your problems, then you're
focusing on the wrong things.

------
bjourne
Anyone care to explain what the author mean by: "Pair programming is like
those girls that go to the restaurant bathroom together."? It sounds like a
funny analogy but it's just pure gibberish. The point of the article seem to
be to get reactions, not tell you anything about Agile.

------
vannevar
_What do [Scrum Masters] do?_

I'm sorry, but if you don't know the answer to this question, you're not
familiar enough with agile to write intelligently about it. If you're going to
write about a technique, you should at least know the basic concepts, whether
you agree with them or not. And pretending ignorance for effect doesn't add
much to the discussion.

~~~
jrajav
Personally, I think one can learn enough about agile to apply it usefully
without ever learning what a "scrum master" does. Maybe this goes back to the
discussion of process vs. best practices.

~~~
vannevar
Maybe. But it's a pretty critical role, and if no one on the team is filling
it (or even aware that the role is needed), you're losing out on most of the
benefit of agile. To the point where it's not really what people mean when
they refer to the Agile process.

------
wpietri
"I don’t think values have anything to do with productivity or collaboration."

That is possibly the dumbest thing I have ever read. I have never seen a
tight, productive team that didn't have certain values in common. It need not
be explicit. (Indeed, being explicit about it is often a sign of problems.)
But it has to be there.

His counter-example, supply chains, are notoriously difficult to manage. The
people who are best at that, like Toyota, often work very hard to encourage
shared thinking and shared values across company boundaries. And the notion
that in-team relationships should look to the US-Russia relationship as a
model is redonkulous.

Updated to add:

That line strikes me as a classic example of "I don't notice X in action,
therefore X is {stupid|unimportant|useless}." Which I've certainly done in the
past, but as an old fogy I've taken my lumps enough to learn a little caution.

------
johnnyn
I totally agree about the scrum master role. I have never understood the need
for a scrum master when there are product managers and tech leads. Scrum
masters usually don't have technical or product experience. I think some
product managers just hire scrum masters to do their grunt work.

~~~
Goronmon
For me, scrum masters have always been regular members of the team who had the
added responsible of organizing the meta-scrum aspects of the work. They
scheduled the planning, retro, etc meetings as well as set up the task board
once work was decided upon. They made sure meetings and stand-ups were running
smoothly and stayed on point.

I could see where a person whose entire job description was "scrum master"
would seem superfluous, but I have yet to work somewhere where that was the
case.

------
jschuur
At its core agile leads to being able to ship at small intervals and be...
uhm... agile enough to adapt to market/business changes. What's not to like?

------
ndemoor
I genuinely agree. In a former life I was promoted from software developer to
lead dev/scrum master, and I can tell you the dev part of the job moved
completely to the background, making room for something more of a secretary
job: planning poker roundups, doing the scrum board task dance, doing the
numbers game on estimated and effective man-hours, etc. Overhead.

I don't say agile development is a bad thing. But some managers tend to be led
by cool buzz words and obey the manifesto way to strictly.

Agile development is different for every team and situation, not a one-stop-
shop everyone should adhere to.

------
stcredzero
_> Old people: Agile has the smell of death on it. If you go to an “agile”
event you will see few people under the age of 40 and many over 50._

This has the smell of ad-hominem on it. How about a little evaluation of the
_ideas_?

 _> Most organizations which use the word "agile" are using the word precisely
because they are NOT agile, and want to be more agile._

Again, this is basically just saying, "It can't be cool because the cool kids
aren't in on it." How about an evaluation of the ideas, not the marketing?

 _> I don’t think values have anything to do with productivity or
collaboration. The Americans and the Russians didn’t share many values, but
they teamed up into a mighty fighting force during WWII because they shared a
goal._

I abhor this attitude. You meet people who are all about "making use of you"
at "startup weekend" type events. Values aren't so necessary for productivity
in general, but shared values are necessary for productivity in areas where
quality and attention to detail are paramount.

 _> If you are a vendor selling “pairs”, you have an awesome situation where
you can charge twice as much, and you can easily churn guys on and off the
pairs, one at a time_

So you are evaluating a practice by the scummiest abuse of the practice? I
think this reveals something, but not so much about the practice.

~~~
juan_juarez
I'd say the fact that orginizations using the work 'agile' not actually being
agile goes hand in hand with old people at "agile" events. People that do it
actually do it, people that want to talk about how they should be doing it
just talk about it.

~~~
stcredzero
Those two sentences need some more exposition to connect.

~~~
PostAgilist
No they don't

------
rimantas
Interesting to see that comments of these articles are full of "no true
scotsman" arguments.

~~~
thebigshane
Since you are interested in logical fallacies, please don't forget that
committing a logical fallacy (such as "no true scotsman") does not invalidate
the conclusion (in this case: that the author really _isn't_ doing it right).

<https://en.wikipedia.org/wiki/Argument_from_fallacy>

------
dbshapco
The title is provocative (it's a numbered list, and a rant!) but the author
would have been better served with "Seven Ways to Make Agile Better", for no
other reason than taking a positive slant. Agile can be built on, its not
necessary to tear it down to the foundations first. The article wasn't helpful
or illuminating and full of strawmen -- the author is attacking their own
definitions of Agile.

Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a
reference probably only fortysomethings will get) and once was mistaken for
latetwentysomething by someone who was bad at guessing ages, good at flattery,
or some of both. But please read the following with full consideration of the
biases of age, from which youth is wonderfully immune.

Agile is essentially about shortening feedback cycles. The problem with
waterfall was that work products were reviewed when 'complete', when change
costs were high and commitments large. Decompose the work products into
smaller chunks (backlog items and tasks) and review more frequently -- Sprints
(every N weeks), standups (daily), pair programming (realtime). Every work
product in a waterfall cycle, not just code, can be decomposed into smaller
tasks -- design documents etc. can be constructed iteratively and
incrementally, in parallel or sequentially (the latter meaning you can overlay
Agile on top of waterfall) with tight and layered feedback cycles.

There are many artifacts, but dwelling on their structure and nature without
reference to their essential role leads to superficial criticisms.

When something is broken in Agile always return to the fundamental question of
how well the feedback cycle is working and how to fix it. Sprint reviews not
providing value? Are they being used for feedback or have they become demo
days? Has the standup become a daily status report?

------
brown9-2
Most of these complaints apply to any workplace or group that advertises
itself to follow a certain methodology.

Half the problem with places calling themselves "Agile" is the need to
advertise to the world the process you use to do what you do.

------
mcherm
Andy has observed that people under the age of 40 don't talk about "Agile" as
much as people over it. I have NOT made this same observation, but I have a
theory about a possible reason that Andy has observed it.

People over 40 call it "agile development". People under 40 call it
"programming". The people over 40 remember doing it differently -- we remember
the nine month efforts to write requirements documents that then must not be
deviated from even if it is necessary to save the project from failure.

------
anuraj
Agile is the corporate gobbledygook for convoluted process and making sure
people work day in and day out even though there is no long term goal. Suits
them!

~~~
kaonashi
It seems more about balancing long-term planning with the behemoth that is the
code you've already written.

------
bonesbrigade
I am biased, but it is hard to take someone who is talking about stagnation
seriously when his blog ends in aspx.

------
vital_sol
Oh yeah, I remember all those Morning Stand-Up Comedy Meetings at Salesforce.

~~~
PostAgilist
Oh I thought Salesforce.com was doing well with Scrum.. Are you saying it was
mostly a farce there or..?

PA

