
The Agile Disease - utnick
http://lukehalliwell.wordpress.com/2008/11/16/the-agile-disease/
======
DanielBMarkham
Somebody needs to take a few anger management lessons.

As somebody who makes bucks off the word "agile", I feel like I should
respond. I'm not going to take apart his piece, because I too am sick of the
manifesto and believe that the top dogs are just in this as a marketing
exercise.

Having said that, Agile was not put together by those guys. That's just what
their books say. Agile techniques have been being used for decades. They just
didn't have the cool marketing term. You don't have to drink the coolaid to be
agile -- any high-performing team is going to be agile, whether they call
themselves that or not.

Second, Agile is a philosophy, not a methodology. It doesn't tell you what to
do, it tells you what to think about what you're doing. Agile/Lean IS just
common sense, but nobody seems to have much common sense anymore. You can
apply the agile philosophy to all sorts of methodologies.

Third, Agile is not for mushy-headed enterprise guys. It probably works better
for small customer-facing shops. To say agile is a response to CMM or heavy-
handed processes is again to buy into the story the book-writers want to tell
you. Put down the crack pipe. Agile has always been around, and has been used
inside of all kinds of other methodologies.

Finally, Scrum is NOT agile. Scrum is a project management framework that you
can use for agile projects. You can use a lot of others, or you can roll your
own. The Scum guys are the religious nuts in this circus, if you ask me, and
they are the ones causing all of the backlash. The rest of the Agile movement
is just about how to best iteratively and incrementally do your job. That's a
good conversation to have.

Ironically, a key factor I'm finding in successful agile teams is the ability
to be open-minded. If you are an agile disciple or evangelist, or if you are a
anti-agilista, usually it gets in the way of team performance. It's the people
who want to have an ongoing conversation about how to keep increasing team
performance -- without getting hung up over what book it was in or not -- that
grow killer teams.

------
mechanical_fish
Let me sum up my impression of this article:

A. Agile methods are just common sense.

B. My company has no common sense, so it treats the agile methods as some sort
of religion, and thereby remains completely dysfunctional.

C. I am in hell and need something to shout at. If I shout at my coworkers I
will get fired. But there is a consultant within shouting distance.

D. My life sucks and it's all the fault of the Agile Methodologists!

If anyone ever wonders why management consultants charge all that money: This
is it. Would _you_ want to walk into this guy's company and try to give
advice? You'd have to be awfully well paid!

The author is on the path to enlightenment, but he is not yet there. He's
figured out that the capital-M Methodology is primarily designed for broken
companies. [1] He's well on his way to figuring out that he's working in a
broken company himself, which is why there are so many people employing
Methodology there. What he hasn't figured out is that you can't fix a broken
company by walking up to people and telling them "you aren't writing
documentation or using the bug tracker because you aren't a very talented
coder and you have no common sense". I have _seen this management style tried_
, and it doesn't work: it just makes everyone unhappier, and it focuses their
unhappiness on you.

If you want to tinker with a dysfunctional company instead of just running for
the hills, you need to (a) recruit allies, (b) equip your allies with powerful
Jedi mind tricks that they can use on their less-enlightened management, and
(c) find ways to maneuver problematic people out of the way of your allies --
or, if necessary, destroy them. This is why there is always a Methodology
lying around -- and why, when one dies, another is always there to take its
place. A Methodology is a rhetorical weapon, designed for just these purposes.

(a) It's not an accident that Methodologies evolve cultlike features. So does
every effort to recruit a bunch of people to a cause, whether it's a
fraternity, a political movement, a school of software development, a message
board for hackers, or, you know, an actual cult. "Join me and we will fix the
company."

(b) The Methodology eventually evolves expensive consultants in suits, and
industry-standard buzzwords and rituals whose magical powers are strong and
unquestioned. This is important. If your buzzwords aren't magic, nobody will
listen to you unless they have common sense, which is very unreliable.
Remember when Java was on the uptake, and you couldn't sell anything to a
corporation unless it somehow involved J2EE? "Don't worry, Higher Management.
We are not merely employing our own native talent and common sense. We are
using an Accepted Methodology as endorsed by Higher Powers. You don't need to
see our identification; these aren't the droids you're looking for."

(c) I have never heard of a "Scrum Manager" before, and I agree that he or she
has a very silly name, but I think I already know what this person is for.
This person is there to provide a second manager that is empowered to talk
back to the first one, who may well be clueless (at least part of the time).
The original poster actually understands this. He just doesn't accept it. He
has yet to accept that occasionally-clueless managers, let alone _permanently_
clueless managers, are a fact of life. He seems to think that you can somehow
_avoid having_ clueless managers, or fix them by appealing to their _common
sense_. [2] Give him time. Someday he will stop bemoaning the needless
existence of powerful weapons and start learning how to use them. "Mister
Manager, sir, if you don't stop insisting on screwing up our work I'm going to
have our Scrum Manager report you to the Methodology Police."

Unfortunately, like Harry Potter's magic or the Force, Methodology is just a
tool. The fact that people are using it all the time, brandishing its most
powerful aspects in broad daylight, doesn't mean that things are going well or
that the forces of good are necessarily going to win out. Quite the opposite,
really. Someone whose projects are well-managed will appear to be living a
comfortable, slightly boring life in his home in the swamp, and will rarely be
heard employing a Methodology out loud.

\---

[1] As opposed to garden-variety methodology, which is fine and -- for the
talented -- is just "common sense".

[2] Those of us without nominal managers -- startup co-founders and
independent consultants -- shouldn't feel too smug here. Clueless customers
and clueless clients can be every bit as problematic as clueless managers.

------
caustic
As someone who works in a company producing agile project management software,
I can confirm that the whole agile thing is surely a money-making machine and
very lucrative market with plenty of competitors.

The funny thing is that while our company tries to follow agile practices
internally, this does not prevent iterations from failing. The developers are
not that bright, the growing code base is not that awesome, and this is our
worst enemy.

------
biohacker42
I agree with almost everything in the article.

However if you're stuck in large organization that has been doing waterfall,
almost any change is good news.

And you bet A LOT of very respected software companies, not IT departments of
other companies, but actual pure software companies are stuck in waterfall.

So then this pseudo religious movement comes along with Scrum and stand up
meetings and story points and blah blah blah, but along with the blah also
comes test driven development, and iterative development.

Yes daily standups are a lot easier to adopt then TDD, but that's why the
pseudo religious thing is useful.

It helps you drink ALL the kool-aid.

But game design on the other hand I'm not so sure about, how long does a game
technology like a 3D engine last? Is it long enough to justify 100% test
coverage? As much as I love TDD, I am not so sure about it in game dev.

~~~
kragen
Does Scrum require TDD/BDD?

I think BDD is going to be limited where your biggest and hardest requirements
are things like, "The game should be fun to play".

~~~
ivey
Scrum doesn't have any engineering practices attached, it's purely a
management process. BDD/TTD, pairing, etc., all go nicely with Scrum, but are
not required.

~~~
kragen
That's what I thought! Thanks.

------
stcredzero
_...seven pages later, they’re saying 'I strongly recommend these practices be
strictly adhered to until you understand why and how Scrum works.' Sound
familiar?_

That doesn't mean that Scrum is just a "cookbook." A book that's "just a
cookbook" would only have recipes. A book about learning how to cook a certain
cuisine would have recipes included as examples and exercises, but would also
go into generally applicable principles.

Of course there is a spectrum. Lots of cookbooks have some instructional
material. There are even books that are 1/2 instructional, 1/2 straight
recipes.

------
Dilpil
Was the word SCRUM specifically created to sound dirty?

~~~
jjames
I am the Scrum Master!

------
jgalvez
Thank you for taking the time to write this. Srsly.

~~~
noonespecial
I'm sorry. I don't mean to be an ass. I don't mean to nitpick. I just find it
hilarious that your comment thanking him for taking the time to write
something does not take the time to write out "seriously".

Not a criticism in any way, just an appreciation of the delicious accidental
irony of the every day.

