
Agile: 5 years later and you're still doing it wrong - ghc
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
======
marcusf
Yegge, as usual, is hyperbole and a half. Don't get me wrong, I like his
writing. I liked it more when I was younger, but I still enjoy it.

I have to say though, after working the last 3.5 years in an organization that
Yegge would categorize flatly in Bad Agile, first as a developer and now as a
PM, that I disagree. Plainly, his hyperbole and name calling doesn't open up
for a constructive debate but I'll give it a try.

We do iterations, retrospectives and kaizen, automated testing (yes, part of
XP), user stories and more. A few people practice TDD or pair programming.
Importantly, all of this is voluntary - after five years of experimenting with
process, tools, methodology we've found a set of things that work for us and
help us deliver software with high quality and on time. It just happens that
the tools we use fit in the Agile and XP umbrella. And if we look back five
years to the pre-agile days and start looking at delivery times, quality (in
terms of defect rates, patch releases, …) and customer satisfaction, they've
trended continuously upwards and in a big way.

I'm not sure what we're doing wrong and why, and I'd like to have that
explained to me.

~~~
Jach
I'll offer my 6am reasoning-by-analogy commentary in a slightly inflammatory
style to keep the mood. Your third paragraph, if you change all the keywords,
looks like something a converted Scientologist might say! All your friends
tell you it's stupid and give you reasons why you should be unhappy ("Look at
how much money you're giving them!") and so forth, but by golly, you look back
at your life just a few years ago and things seem so much better now! You
don't feel like you're doing anything wrong, and by objective accounts if
you're genuinely happier you probably aren't doing anything wrong in the grand
scheme of things. Why wouldn't you feel good supporting your Church with huge
sums of your income anyway?

In short, the brainwashing worked and you're under the influence of a
beneficial placebo effect. Maybe the placebo effect is what explains the 10%
"success stories" of not-screwed-up Agile Teams that Yegge hints at.

Or not. I don't know. I do know that for me any productivity hacks are
temporary at best and ineffectual by default, and I'm wary of ones that have
been actively dangerous for a good number of people; when akrasia is solved in
general humanity will rejoice...

~~~
marcusf
Ok but I believe the burden of proof is on you. I'll claim that adhering to
some principles has given us quantifiably better results, and that the time
scale is long enough that any Hawthrone Effect would've worn out by now.

Also, "productivity hack" is not a label I'd use to describe e.g. automated
testing. YMMV.

~~~
pdubroy
Actually, the burden of proof should be on you. The null hypothesis is that
adhering to agile principles has no positive affect on the outcome of software
projects. In order to show that these principles have worth, you should
disprove the null hypothesis.

~~~
marcusf
I disagree. I've laid out my arguments best as I can, pointing to how we've
measured and that we've seen improvements. In response to that, the commenter
compares the post to scientology.

The hypothesis under discussion here isn't "these principles have value", it's
"even though implementing these principles gave measurable value, they're
still snake oil comparable to scientology".

------
brd
As an enterprise developer (i.e. one of the guys working in the big, non-
technical companies) I have been one to advocate and implement parts of agile
on various projects. I will fully admit that Agile is mostly hype and that
adhering closely to any methodology is mostly, if not entirely, futile.

Steve and others are missing the point, when done right it forces conversation
and it gives programmers a voice. In big non-technical companies everything is
top-down, date-centric and programmers are just cogs. When we did agile, we
essentially had some basic sprinting (make date people happy) and a strong
feedback loop (give developers a voice after each sprint) and those two simple
steps produced some amazing work.

Dates will never go away in these kinds of companies, programmers will never
be first class citizens, and some sort of process will always be demanded.
Agile is not about how to get developers to be more efficient, it is about
getting large non-technical organizations to bend (ever so slightly) to the
will of the people actually producing the work.

~~~
InclinedPlane
This is exactly the environment that agile is designed for. It's oriented
around getting to a state of producing results in teams with low cohesion,
poor communication, and ineffectual or non-technical management. The problem
is that people see agile as a one size fits all solution and try to shoehorn
it into situations where it's not helpful. Even worse when people misapply the
core concepts and it becomes just another excuse for micro-managing.

------
singular
I think there's a lot of truth in this (though as with all opinion pieces,
esp. seriously entertaining ones like Stevey's, you have to take it with
several pinches of salt).

I have a suspicion that a lot of agile is a hack designed for managers who
have problems within their team and don't want to deal with them properly.

It's far easier to adopt a 'proven' methodology than confront the fact that
Frank in accounts has unrealistic expectations and changes their already vague
spec 30 times while expecting the estimate not to change, or that Peter is
driving down morale in the team by nitpicking every last mistake you make
while ignoring his own, or the constant denial of the impossibility of
actually consistently correctly estimating tasks which have _never been done
before by anyone_.

Dealing with those things well takes real skill, patience + awareness as well
as a willingness to accept reality and eschew politics, and that's just hard.

What I particularly dislike about agile is the unfalsifiable _dogma_ of it -
you MUST do it like this otherwise it won't work and it will be YOUR fault for
not having done it properly. If it works then of course it's all agile. That's
a big problem - everything you do in a team should be for reasons and open to
discussion otherwise you end up with cargo cult programming and cargo cult
software management.

All that said, _if_ you take agile not as a dogma but a series of methods that
people have found useful and adopt it to your needs, while not avoiding the
realities of the situation, then I can see how it can provide prompts for
improving a team.

~~~
rsanheim
The original agile manifesto was definitely not a dogma.

If someone presents it as such today, you can usually follow the money pretty
easily to figure out why.

~~~
andy_boot
God yes - While working at a large bank I once saw an Agile consultant give a
presentation to us. His words: "We find that when teams aren't succeeding with
agile it is because they had only adopted some of the agile processes instead
of all of it and that hadn't been trained properly by an expert "

I threw up a little.

~~~
kabdib
This is PRECISELY what you hear from folks who are trying to sell you
religion, or stuff like EST.

"Of course it's not working, you're not doing it right. We'd be happy to work
with you some more on that."

Followed by the "ka-Ching!" as they cash your check for the consultancy.

Agile is so often turned into a micromanager's paradise that I've just stopped
involving myself in it. Our team holds scrums, none of the engineers show up.
It's pathetic.

~~~
kragen
You'll hear the same thing about any difficult discipline. Surgery, painting,
programming, auto repair, biological experiments, chemistry, mechanical
engineering, and so on.

------
jgarmon
This isn't about agile. This isn't about methodologies. It's about one basic
principle that's true in every industry, for any and every management system:

PROCESS IS NOT A SUBSTITUTE FOR LEADERSHIP.

No set of rules can compensate for bad management and employees. Rules usually
empower bad managers and disguise bad employees. No methodology -- agile or
otherwise -- can stand up to bad execs, bad project leads and/or bad coders.

It starts with hiring. That's how Google gets away with loose rules -- they
prioritize hiring "Google-level" coders and managers. All else is details.

~~~
velshin
> PROCESS IS NOT A SUBSTITUTE FOR LEADERSHIP.

Choice quote, though you're quoting yourself. :) Your original write up
"enough with the meetings are toxic" was a nice read from 2006 too!
<http://goo.gl/U9Ysi>

~~~
jgarmon
WOW, I had NO IDEA that was still out there. I guess nothing ever dies on the
internet.

------
bambax
TL;DR _Google is awesome. Agile is bad and stupid and for stupid people, but
when Google does it it's great, because Google can do no wrong and is NOT EVIL
and did I mention awesome?_

I agree that "Methodologies" with a capital M are probably a scam, and that
Google is probably full of super-smart developers that do fantastic work when
left to their own devices — but I knew that already...

~~~
dos1
I think that's the key piece. Yes, Google can operate the way they do because
they have world class talent. Literally some of the best developers in the
world. If you find yourself in that situation, then yes, you too can do things
the way Google does.

Being a contractor and working in the bowels of Fortune 500 software divisions
has taught me that this is a pipe dream for almost every other company. The
methodologies (Agile, Waterfall, whatever) were no doubt created in order to
help teams of poor to middling developers actually accomplish something while
fighting through the corporate red tape and their own stagnation.

I've seen the kind of "Bad Agile" he talks about work at big inflexible
organizations, and I've seen the "let everyone work on what they want" style
of development go catastrophically wrong. Yegge's post seems to be more about
him congratulating himself on how awesome he is for working at Google.

~~~
snorkel
It's not just about the level of talent but about what Google can afford to
do. Google banks so much cash from search advertising that it can bankroll all
of these other internal projects that might not impact revenue at all, and
their cashflow and stock price is so high that no one is stressed about costs
or deadlines. As Mel Brooks's said, it's good to be the king. If Google was
pressured by competitors and falling stock prices you would quickly see the
whole picture revert to the traditional management-says-get-this-shit-done-now
project management.

------
duwease
As the article touches on, Agile discussions seem to often rely on the "No
True Scotsman" fallacy -- if it doesn't work, it wasn't _really_ Agile, so the
definition becomes slippery enough to evade a lot of criticism.

I think that, because of this, trying to push the umbrella term "Agile" makes
it more difficult to evaluate the sum of the ideas than if you were to
evaluate each idea on its own merit. Each person can claim some permutation of
the sum parts (and even add some more), and assign them the title of "true
Agile".

It's something I saw when I was going through SOA training for work as well.
There's those that swear that heavy contracts are required for "true" SOA, and
REST can't provide those. And there's those who swear the focus should be on
the "service oriented" aspect without all the SOAP overhead, and that core is
the "true" SOA. Personally, I try to avoid using the term "SOA" now and just
stick to the technical description of what I'm talking about.. hell, I'm
almost afraid to put it on my resume.

------
babebridou
This is how my previous company (a great bunch) implemented SCRUM. My CEO came
to me and asked me this:

"Thomas, we want to increase our revenue so we need to differenciate ourselves
from other consulting firms. We need our services to be top-notch. Our
customers don't know anything about Agility and processes such as SCRUM but I
think I can sell them that. What can you guys do to help sell this?"

To which I suggested: "we can pretend we're doing a variant of SCRUM and label
it '{{nameofcompany}}scrum'. I think a board in the middle of the openspace
with neatly arranged coloured post-its will do the trick."

He said: "Great, thanks", then proceeded to increase our average daily rate by
20%.

Once a cowboy, always a cowboy... Oh and by the way, it worked.

Agility, as in the Agile Manifesto, simply works on its own. It might not
define good practices, but at least it defines a set of good intentions and
it's a working strategy that's simple to explain to team members. Everything
around is nothing but ways to make more money, not ways to make projects work.
My philosophy would be to sign the Manifesto (because it's good) and pretend
to implement one of those methodologies (because it's cash), while you keep
doing your job well in the way that best suits you (because that's what makes
you happy).

~~~
agravier
A detail: Scrum is not an acronym but a name derived from a rugby term, it
should not be written SCRUM but just Scrum.

(Great story otherwise)

------
vacri
_Fat, bad. Cholesterol bad. Salt, bad. Everything, bad. Nowadays, though, they
differentiate between "good" cholesterol and "bad" cholesterol, as if we're
supposed to be able to distinguish them somehow._

Screw this guy and this kind of anti-intellectualism that makes it cool not to
learn about stuff. "Why should I have to know anything about biology?". I
don't care that it's only part of the intro, this kind of thing reinforces the
kind of self-important "customer-is-ALWAYS-right" righteousness that glorifies
ignorance. It makes me angry that people get away with shit like this.

------
sakopov
From my experience with Agile, I believe that most companies do it wrong. I
know my company does. But it helped us dig 2 projects out of the never-ending
abyss of scope creep and constant end-user changes when we converted to Scrum.
So when I hear "you're doing Agile wrong" it makes no sense to me. You make
what you can out of it. You mold it to fit your practices. It will most likely
never work for you out of the box and it takes time... it just does.

Honestly, I didn't even get to the end of the article and stopped soon the
author started glamorizing Googlers. I was more offended with "Google does it
right and you're wrong" and calling everyone in the world stupid than by the
author rendering the whole Agile practice useless.

------
sethg
Amen to what Steve says about a work queue. I've been in environments where,
more than once, a dialogue with my manager would go like this:

Me: "My to-do list is empty."

Manager: "Oh, umm, let's have a meeting to talk about that... [consults
calendar...] the day after tomorrow." Or even: "Yeah, I know, I'm still
looking for something for you to do."

Now, if I had cast-iron balls, or an amulet that gave me a +5 bonus on my
saving throw versus layoffs, I would respond to that with "OK, I'll just stay
home tomorrow and check email on my laptop every few hours, just in case
something comes up." But that's not how the game is played, of course.

~~~
hopeless
Since late October (end of previous release) I've been mostly doing make-work:
test scripts, some individual investigation, reading up on standards. Why?
Because upper management haven't decided what is going into the next release.
I've finally given up trying to get answers and I've made the decision myself.
Any direction is better than no direction.

And the bizarre thing is they are totally obsessed with "keeping the sales
pipeline full" but can't see that the same can apply to development. No doubt
someone will make a decision in a while and we'll be under severe pressure to
catch up on the lost months.

~~~
MartinCron
If you consider writing test scripts "make work" you're really wasting an
opportunity.

~~~
hopeless
I wasn't very clear: the test scripts were to see if I could provide a unit
test framework for the internal scripting language (not actual product tests
which are obviously a productive part of development). It's interesting to
_me_ (which is why I did it) but since it won't ever reach a customer it's
basically just to fill my time

------
DanielBMarkham
First, this is a five-year-old article. And a dupe.

Second, let's get definitions straight. Agile is best practices around
iterative and incremental development. The word is a marketing term and can
cover all sorts of different (and contradictory) concepts. Scrum is a
certified way to manage Agile projects. You write a check, there's a board, a
class, and a nice little certificate you get.

So it's really hard to jump up and down and yell too much about "Agile" -- the
term is just too slippery. (I note he includes a picture of a ScrumMaster
class) Or to put another way: ten years ago companies hired me because I was
really good at running iterative and incremental projects and could not only
do it well, but help train project managers and teams. Now the same companies
hire me for the same reasons, but the word "Agile" is attached. If you want to
slam all external consulting as being a waste of money, that's fine, but let's
be clear what you're ranting about.

Second, because it's best practices, not all of them are going to work for
you. And as you grow, you'll find out how to use some (and ignore others).
Hell, I'm still struggling with TDD. But I grok pair-programming: it's the
same kind of coding you did in college where a couple of people would sit
around figuring out a problem. It combines the code review and the code
creation into one step -- brings the review as far forward as possible, so
there's no wait. Would I do pair programming all the time? Shit no, but does
that mean I should make fun of it? Not unless I want to sound like an idiot in
ten year's time.

The biggest point to be made here is that _Agile adoption is not the same as
Agile principles_. Agile adoption sucks -- it's full of zealots, religious
wars, highly-priced seminars, and feel-good happy talk. It can be just another
way for management to micro-manage your project. The terms can mean different
things to different people. Consultants make lots of money and provide very
little value. And so on. Trust me, I know this:
[http://www.whattofix.com/blog/archives/2010/09/agile-
ruined-...](http://www.whattofix.com/blog/archives/2010/09/agile-ruined-
my.php)

But all of that is just a study in how screwed up most organizations and
movements are. Agile as a set of best practices is awesome. If I want to learn
about data modeling, I'm buying some kind of book with a title like "Agile
data modeling" because I know it's going to have an incremental and iterative
context -- I won't have to do as much mental gymnastics to fit it into what
I'm doing. (Disclaimer/shameless plug: I just published the first in a series
of e-books to try to teach people without them having to pay so much for
consulting. <http://tiny-giant-books.com/scrummaster.htm>)

Agile adoption has generated a lot of hate. That's a shame, because as Steve
points out, there's good in there too. (Although he's not hitting on a lot
here, the article is nicely done)

~~~
jsight
> First, this is a five-year-old article. And a dupe.

I believe this is why the title is "...5 years later and you're still doing it
wrong". It's probably worth discussing why things haven't really changed in
the past 5 years regarding this.

~~~
softbuilder
The title was confusing. I thought it was a new article, looking back over 5
years, not a 5 year old article.

------
megamark16
This reminded me of the keynote Andy Hunt gave at Ruby Midwest last year
entitled "Agility Undefined - Becoming Uncomfortable with Agile". Here's a
video of it, for those who missed this awesome conference:

<http://www.confreaks.com/videos/770-rubymidwest2011-keynote>

------
vonmoltke
_Back in Ye Olden Dayes, most companies approached software development as
follows:

\- hire a bunch of engineers, then hire more. \- dream up a project. \- set a
date for when they want it launched. \- put some engineers on it. \- whip them
until they're either dead or it's launched. or both. \- throw a cheap-ass
pathetic little party, maybe. This step is optional. \- then start over.

Thank goodness that doesn't happen at your company, eh now? Whew!_

Actually, that describes my company to a T. I think its more to do with
working for a manufacturer, since my company is technical, and working in
defense.

Oh, and in our case, "start over" means "find something we did in the past
that is kinda sorta like what we need to do now and force fit it to the
problem as quickly as possible".

------
Drbble
Agile techniques make good teams perform better. Scrum makes it impossible to
hide from problems for more than a month. It doesn't solve the problems for
you. Scrum makes failures faster so that errors are minor mistakes instead of
yearlong catastrophes. Scrum is not micromanaging, it explicitly empowers the
contributing team members to manage themselves and each other. No one ever
sold agile as a way to make bad teams perform well. I have seen Scrum (as
practiced by a team that read a short book and sat in a one day training and
bought in to it with an open mind) make made my team deliver better work in a
more satisfying way.

------
jebblue
Cool article but I'd just like to know why stand-ups have to be in the morning
when I'm still getting into the groove of things. Why not end of day, all day
you're waking up and building to that brief stand-up and it's either hey I
need help or hey look what I/we got done.

For that matter what if people have a good medical reason for not standing,
does that mean stand-ups are an implicit form of discrimination against older
coders?

------
mark_l_watson
I like the part about modeling work tasking on priority queues. I use org-mode
a lot and having a few org-mode (Emacs package) files like priority1 and
priority2 and manually keep the most important stuff at the top would work
well. That said, right now, in addition to project specific org-files, I keep
one special org-mode file that are my 4 or 5 top priorities and for a one-man
consulting shop that is enough process :-)

I also liked the opening SCRUM quote from wikipedia. I have experienced "over-
SCRUMing" first hand at one of my customers. Daily SCRUM meetings may seem
like a good idea, but if not tightly controlled they can take up a _lot_ of
time.

------
dave_sullivan
So Google is an engineer's dream and everyone is so nice and there are huge
incentives and all that, ok... but if that works so well, why have they failed
to come out with another product that is unquestionably as
successful/profitable as their advertising platform has been? (the core of
which they didn't invent, they stole it from Overture)

Just saying, if you take Google and you remove that particular aspect of their
business, there would be no business. So like, 90% of the engineers' efforts
account for what, like 5% of the profits? Hardly an approach worth emulating
unless your startup happens to have a golden egg laying goose like Google.

~~~
jpendry
Jobs created the Mac, and the iPhone. I just recently went back and re-watched
the original iPhone keynote, and I believe this is very much a theme of what
he was saying on stage.

Making something new, at world class quality, is incredibly difficult.

------
huherto
I've been promoting of Agile practices for many years. But, lately I have seen
several cases of non-technical people hijacking Agile. Suddenly they become
"Agile experts", they don't care/understand about continuous integration,
regression testing, technical excellence, etc. Agile was a developer flag, but
now it is being used to beat developers by the same people that never
understood the nature of software development.

------
wisty
I'm just wondering how they manage those bonuses. Wouldn't it get kind of
political? Or do they have some kind of arms-length system?

~~~
crntaylor
I can tell you how _I_ would do it, which would be to have as strong a tie as
possible between 'Project X' and 'Revenue generated by Project X'. If it's
true that most projects that get launched are launched by small teams, then
the problem isn't much more complicated than that (divide the bonus equally
between the members of the team, or in proportion to how long they worked on
the project). If the teams are larger, you need to allocate bonus pools for
the managers/tech leads to divide amongst their team - and that could get
political.

~~~
RyanMcGreal
> to have as strong a tie as possible between 'Project X' and 'Revenue
> generated by Project X'.

At Google, that would mean the only teams to get bonuses would be teams
working on Adwords.

~~~
amouat
Yeah, it's a pretty bad suggestion. Many projects don't directly generate
revenue. It ignores practically all support projects that help people to do
their job (i.e. improving the bugtracker, sales software, test software etc).

------
chmike
A parameter the author is not mentionning is the "smartness" of the ingeneers.
When you have smart ingeneers they can mange their own work themselves,
identify good idea from bad one, etc.

But I have heard rumors that what is described in this article about google
way of running things is not true anymore. Can anybody say something about
this ?

~~~
plainOldText
Not much of a biggie, but is engineers not ingeneers. :)

~~~
chmike
Sorry, my bad. I'm French and mixed-up spellings (ingenieurs in French). I
can't edit the comment. It is good to point it out so that people don't make
the same mistake.

------
Estragon

      > developers are strongly encouraged to spend 20% of their time
      > working on whatever they want, as long as it's not their main
      > project.
    

Did the 20%-whatever-you-want benefit survive the "more wood behind fewer
arrows" policy?

------
gearoidoc
Great article until he mentioned Google as a shining beacon of developer
fulfillment. I know a few developers in Google (Ireland) and they're made to
work huge hours. I'd rather have free time than free pizza.

~~~
KiwiCoder
++ for free time over pizza

------
bh42222
Sadly Agile has indeed jumped the shark.

I have always seen Agile as a way to fight the Waterfall process. Another way
to see it is to add professionalism and discipline to companies who don't have
things like unit testing, code reviews, etc.

In his long write up Steve made two points which I think are the most
important:

1\. Waterfall is known to be bad; I _hope_ we can just that as an axiom today.

I added the emphasis on 'hope'. I hope so too, but I'm afraid the end of Agile
might mean the triumphant return of Waterfall.

2\. _Google is an exceptionally disciplined company, from a software-
engineering perspective. They take things like unit testing, design documents
and code reviews more seriously than any other company I've even heard about.
They work hard to keep their house in order at all times, and there are strict
rules and guidelines in place that prevent engineers and teams from doing
things their own way. The result: the whole code base looks the same, so
switching teams and sharing code are both far easier than they are at other
places._

Google sounds like an exceptionally disciplined software-engineering company
indeed! This to me implies they do NOT need Agile.

Why would you introduce something designed to professionalize software-
engineering to a company which is super disciplined and professional? You
wouldn't! The only thing you can introduce is bullshit like 8:00 AM meetings.
No wonder Steve hates Agile so much.

But again, everything he says about it being an infomercial and aimed at
stupid people is _true_. But it is still a God send if this meme virus infects
a death march plagued Waterfall process which does not use unit testing or
even has source control.

Now why would a good developer be suck in such a place? Well maybe you live in
an area where there is not a lot of tech. industry and jobs. Maybe you live
there because all your family and friends are from there. Maybe your child has
severe asthma and you can't afford to leave the gold plated health insurance
plan from your corporate job in a non-software company that's big enough to
have a software department.

I can't quite imagine how Agile could help a company like Google. But I know
how it can be a great benefit to much less disciplined companies.

And I really do fear that the end of Agile means the return of Waterfall.
Because Waterfall intuitively makes sense to people who don't understand
software engineering. And there are a lot of them outside of silicon valley.

And Waterfall doesn't just plague obscure places with no tradition of
technology. The US north east, home to MIT, IBM and formerly DEC, Waterfall
has always been big out here too, and it's not because we're not smart.

~~~
wr1472
> Google sounds like an exceptionally disciplined software-engineering company
> indeed! This to me implies they do NOT need Agile.

This implies discipline and Agile (big 'A') are mutually exclusive. From my
experience you have to be very disciplined to do Good Agile (and I have
experience of Bad Agile too).

~~~
bh42222
_This implies discipline and Agile (big 'A') are mutually exclusive._

No, I would say big 'A' brings discipline, but if you already have tons of
discipline, it can't add any more.

------
Gman32
You are not true Agile if you know what you are talking about more than 50% of
the time.

------
readymade
5 years later and Steve Yegge still reads like a teenager.

------
battaile
"I love google and don't understand how cholesterol works."

Interesting.

------
funkah
That is the lamest takedown of pair programming I've ever seen. I don't even
do it, I don't even like doing it, but I know that the justification for it
was never "more is better", and so does Steve.

------
michaelochurch
It's really sad to read this and see what Google used to be, and to compare
that to what it has become (although it's possibly still that way if you're in
Mountain View and Staff SWE or higher.)

------
wpeterson
Disappointing Steve Yegge rant on Agile. TLDR: Agile sucks, but I've never
done it, now I did it, it's pretty good.

Google does Agile OK, but I wish Steve Yegge could see Agile @patientslikeme -
no BS, lots to love - it'd be a very different blog entry.

