October 1, 2006
I’m Agile, You’re Agile…mmm’kay?
If you haven’t read it already, Googler Steve Yegge rants about Agile development and paints a rosy picture of life at Google. Go ahead, read it. (My second favorite rant of the year, but more informative than my favorite.)
Commenters have already critiqued his post. To summarize:
- Google’s products are rarely profitable; Google is acting much as a VC firm, except their bets are almost all in-house
- Google hires from the rightmost end of the Bell curve, which, while great and representing the kind of people most of us would want to work with, isn’t universally applicable (by definition)
- Google has yet to weather a downturn; it is young and its methods are unproven; they’ll likely modify their practices during lean times, as all companies who survived the late 90’s did
With that out of the way, Steve makes some great points and has helped me pinpoint some of my own frustrations. I think, ultimately, what Google has found works for them addresses the same frustrations.
I have no real experience with Agile. You might say my team is currently in a pre-Agile mode: everybody loves Agile methods, in principle…but we have no real idea how an Agile shop actually functions. Which is sometimes funny. And it means I’m certainly in no position to either criticize or prosyletize.
The things that attract me are: more closely working with my colleagues, more cooperation between product and engineering, shorter cycles, greater decentralization.
It’s almost like joining a new religion because “I like meeting new people and feeling like I belong.” Hmm.
The number one problem that I see–in my own team, as with most Agile teams I’ve heard described–is that development becomes so incredibly date-driven that developers are reduced to implementors, rather than nurturers.
I don’t think it’s a coincidence that the Agile/XP/etc. shops I’ve read about tend to be contractors.
In an Agile (or even “pre-Agile” which is a term I made up for this blog post) shop, you’re not going to get promoted for going all-out and getting up at 3am to fix some niggly little thing that has been bugging you all week. There’s no big bonuses for producing a nifty new cutting-edge feature over a weekend. No hefty raises for realizing your product, as specified, will be behind your competitors the day it launches, and taking it on yourself to raise the bar.
You’re more likely to be labeled a “cowboy.” Not that there is any other way to get those monetary incentives, either: abiding the status quo and shipping things on time might, in some teams, mean a free dinner for the whole team.
In the (paraphrased, maybe unjustly) words of one guy I debated recently: “my responsibility ends when the unit tests pass.”
And that just feels wrong. The best programmers I know or read or who have influenced me in one way or another are nurturers. The best start-ups have been grown from the primal urges of programmers–even mediocre programmers, when interested enough, produce great products because they step outside the status quo.
There’s a blog entry I’ve been thinking about writing for a week, which, in a different context, I think touches on what bothers me about Agile. But, at the same time, it’s also Agile’s greatest strength.
Agile seems to be about bringing a certain level of epistemological certainty to the development process through processes. Specifically, decentralized processes.
It’s a lot like politics. Political systems aren’t about actually doing the right thing in all cases. There’s no “Is Morally Superior In All Cases” checkbox on any government’s constitution. It’s about putting processes into place that bring a level of certainty to the everyday functioning of the society. Stability, transparency, some degree of control and leveraging of social knowledge.
Agile is the Democracy (i.e., Republicanism) of the software development world, in opposition to the bureaucratic Theocracies and Communist Dictatorships of many historic shops.
Sounds great, right? It is. But it–just like democracy–can be taken much too far.
Imagine if you had to get approval from your neighbors before renting an adult movie. Hey, that’s democracy, right? Nobody’s forcing you to do or not to do anything–you’re “cooperating” with your neighbors.
Or, more aptly, imagine if you had to get all your neighbors to agree before starting your own business and running it from your home. How do you get their agreement? By convincing a majority of them that it’s going to be good for them, that it serves their interests.
There goes Flickr. There goes del.icio.us. There goes Webshots. There goes Google. (Well, maybe Google survives, unless there were a lot of vindictive people with competing ideas at Stanford at the time.)
At least in a dictatorship, if the dictator likes you, you can do whatever the hell you (or he) likes. Just like in many poorly run companies, you can ingratiate yourself to the VP and get away with a new idea.
That’s the first thing. It feels like contracting. And contracting doesn’t exactly breed dedication–or cutting-edge products that others end up imitating.
In other words: quantity over quality.
The second thing that bothers me is in the nature of teams. I don’t believe that “developers are solitary beasts,” as I saw someone (I don’t recall who) blog recently. Nor do I buy into the “all developers should have offices” utopian vision.
Still, developers have different needs on different days. Days when they get into their zone by putting on some headphones and tuning out of all around them, and days when what they really need to is talk to a good friend (colleague) to hash out some ideas. They will “click” with some of their teammates, while they feel others argue for the sake of arguing.
Then there is the biological argument. Different activities engage different parts of your brain, and switching between two different activities (e.g., coming back from an hour-long meeting to try to implement a new feature before going home for the day) entails a real, nontrivial overhead. Sometimes that overhead is insurmountable, and produces negative productivity.
A lot of teams that try to be “Agile” seem to go overboard with meetings and forced synchronous interaction at odd times. This isn’t unique to “Agile” shops, by any means, but in those places I think you’re supposed to love it. (Insert inappropriate, underhanded not-too-subtle comment about “personal auditing” if you don’t love it. Obviously it’s not that bad.)
Now, I love pair programming, but with the right people, at the right time. I love it when a co-worker is passionate and dedicated enough to actually discuss flaws in a design, even, nay, especially, when it’s a product they’re not even working on–but not when I’m in The Zone. That’s why email is so great. Asynchrononous communication rocks.
This got too long and rambling.
My personal takeaway is that Googlers, and probably others, are motivated by the same factors that motivates the Agile movement, but are adapting the principles to a web shop. Where, by “web shop,” I mean the following:
- can continually improve upon a shipped product, and monitor the success of even minor improvements in near real-time;
- can add features and even whole new products relatively easily, and “wait and see” what the uptake will be, rather than requiring buy-in ahead of time;
- is used often by the company’s own employees outside the context of their employment;
- requires a healthy number of quality internal tools to gain visibility into the site, so development of such tools also qualifies as features unto themselves–moreso than just simplifying a build process
I think that’s what I mean. Maybe I’ll improve on that definition in the future. I’m sure there’s also something to be said about meeting needs before anybody knows their needs aren’t being met. But that’s an age-old “pie in the sky” business mantra anyway.
Maybe I’m just whacked.
If you’ve read this all the way through, I’d like to hear from you. Either comment on my blog or send me an email (see my about page).