Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Thursday, September 28, 2006

Google's New Motto: Don't Be Agile?

Steve Yegge of Google has an epic rant about Agile methods and why they are evil.

This article is sometimes rambling, and often grossly unfair in many ways, but let's take a closer look.

Steve talks about "good agile" vs. "bad agile", and generally lumps anything that requires consultants, training, or books as "bad agile".

Google, where he works, is apparently using "good agile" which as best I can figure means that no one is forcing anyone to do anything, there is no defined process, no deadlines, no explicit pressure, and everyone just sort of figures it out. His ultimate weapon is a priority queue.

Certainly Google operates differently than many businesses (as Steve puts it "Somewhere between a startup and grad school"), but since when did poorly defined projects, no deadlines, and chaos make a solid development process?

OK, I admit a got a chuckle out of it, even as I was thinking, "Wow, this guy really doesn't get it". But then I thought, "Millions of people who also don't get it will accept his arguments without ever reading about or trying Agile".

He goes so far as to suggest that even trying Agile is "Dangerous", and that you should throw out your XP or Scrum books immediately.

I was half expecting him to say "Burn her! She's a witch!"

What's really dangerous is letting someone else do your thinking for you and telling you what you can and can't read or try.

He warns of Agile proponents "being slippery" by taking credit for any good effects of an implementation, but explaining away bad effects as "you didn't do it right". I do see this far too often on Agile mailing lists and in other writings, but it's also sometimes accurate. I can wave my arms around and make "Ha!" noises, but that doesn't mean I'm doing karate.

And finally...the one point I agree with in the entire rant: If a process is attempted by 100 groups, and 90% of them fail, maybe it's not a good process (or well documented, or easy to follow, etc.).

But in my opinion, Agile is not about process, it's about philosophy.

Philosophy is difficult to standardize and implement. So we as humans create specific rules and practices that are easy to digest. For example (apologies to my fellow Agilists):

"Do pair-programming all of the time, except when your alone, then put
your cat on the keyboard."

"Write everything test first, especially test code."

"Use index cards, they are magical and will grow into rectangular trees if
you plant them."

"Don't let chickens talk, they make an awful noise." (from Scrum's "Chickens and Pigs" metaphor)

"Four legs good. Two legs bad." (Hmm...maybe that's not from an Agile method)

And because many people don't "get" the philosophy behind the practices, they either become unthinking zealots or fierce, er, "insurgents", leading to a project's demise.

Is it fair to blame Agile for this? Of course not. But what did fair ever have to do with anything in our world?

So how can an Agilist combat this viewpoint without looking "slippery"? Maybe everyone should do what Steve suggests, and stop worrying about standardizing process, and just work on instilling philosophy. Let good practices emerge from smart, capable people trying things, seeing what works for them, and adapting.

But then you'd be doing Scrum, and we already know that's "dangerous", right?

I do worry when I think about how few people actually read original sources and make independent decisions based on their own experiences, versus going whichever way the latest pundit blows.

So do yourself a favor: listen to me for a change and make up your own mind.

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I notice he says Pair Programming is "bad agile", and then later says says their open spaces allow pair programming "5% of the time", which apparently is "good agile".

    By Anonymous Anonymous, at 12:29 PM  

  • Google is also wildly different from most companies: requirements are coming from technical people, and they don't really have deadlines. This sidesteps a lot of the issues which Agile methods are designed to address. The philosophical underpinnings are still valid (and I bet you dollars to doughnuts they have CI and lots of unit tests), but the boxed Agile implementations just aren't going to be something they need.

    By Blogger Robert Fischer, at 9:15 AM  

  • It's just impossible to compare anything google does to the rest of the world. They aren't even a software engineering company. They are an advertising firm that puts all of it's profits into software engineering "hobby" projects. The few projects that float to the top are polished and sent out to the real world.

    By Blogger Unknown, at 6:37 AM  

Post a Comment

<< Home