Steve Yegge has a provocative blog about Agile methodologies. It’s vintage Steve: fun to read, cutting, opinionated; and, in many ways, largely right, I think. A couple of quick reactions:
The one component of “agile programming” that’s very much part of Google’s culture is unit testing, and that’s always seemed to me to be the most valuable part of agile/XP. When I was at the Googleplex in August, they even had exhortations about unit testing posted in the mens’ rooms. That’s certainly a deep part of the Google culture.
One of the follow-ups pointed out that the nature of Google’s business means that there isn’t the sort of time pressure you have when a customer is screaming for a new feature that he wants last month. That’s certainly true, BUT: At the same time, I’m seeing more and more companies have businesses that are built along Google’s model. Certainly every interesting start-up that I know of. (That begs the question of the uninteresting start-ups.) The perpetual beta does as much to eliminate the pressure for “FCS” as it does to encourage creativity. The perpetual beta, first formulated as “release early, release often,” is one reason behind the success of many open source projects over the years.
In defense of Agile methods, Google’s development methodology works largely because Google only hires very smart people. Don’t ask me how they found that many smart people, even in Silicon Valley. I’ve lived there, and I know that the density of smart people isn’t that much greater than it is anywhere else in the world. Anyway, one of my observations about business in the non-Google world is that a huge amount of it is getting people who really aren’t very bright surrounded by a process that somehow enables these people to turn the cranks and come out with something good at the other end. (I say that with all due respect to my readers, who I assume are the “bright” people at the top of this food chain.) Security audits, code reviews, waterfall, and even Agile: it’s really all the same game. And the “good” that you get from the end of the process is for a fairly tolerant value of “good”. More like “it doesn’t suck too bad”. But that’s the way most companies work. It’s a fair question: how broadly applicable is a methodology that assumes that you can hire people as smart as Google’s staff? Most companies can’t.
Yes, I know that Google engineers don’t walk on water. The deeper question is: with the sort of incentives that Steve describes at Google, could the average performer be motivated to do good work without the process? Or is the existence of the process itself important?
Steve's column compares apples to oranges. If you don't care about when the project is done, if you're willing to spend an unending amount of time on implementation, then yes, agile methods are unnecessary. Go right ahead and just code.
For the rest of us who are answerable to customers that want deliverables either by a specific point in time, or at the very least want to be able to plan other things related to the project, such as training or advertising, we'll need to use agile methods.
Mike, to use agile methodologies, such as Scrum and XP, you don't need to be smart as much as you need to be disciplined. Few developers are disciplined. In fact, many developers are proud of being lazy. I have seen undisciplined developers bring a development effort, agile or not, to its knees time and time again. Give me a team of average yet disciplined developers, and I can train them to be agilists, who are capable of producing meaningful results in line with customer needs.
Using Agile at Google would be like wearing SCUBA gear on land. Doesn't mean SCUBA gear is useless, just means the problems SCUBA gear is designed to address don't exist in that environment.
Every methodology has its reason to exist, but most of them are tools for someone to make money. I can only figure out one good thing from XP that is test driven, but not anything else. XP, RUP and SCRUM's iterative approach have been proven to be a good process, even from my personal experience. There is neither silver bullet development methodology, nor one-size-fit process. IBM pushing RUP to client, just because IBM want to sell more rational products to client; buying those tool has nothing to with RUP actually if you did not get the idea behind RUP.