<a href=”;
I’ve been watching Steve Yegge’s recent rants about Agile. I found the reaction from the Agile community from his first post very similar to how the Mac community reacts when some Windows propagandist starts bashing OS X. I didn’t really give it much more thought. Then today I read his second post follow up, which seemed to be about as reactionary as the Agilists’ comments where from his first post. He’s sticking to his thesis that Agile is a bunch of poo. Again, I didn’t come away with any insight until I read a comment to Steve’s second post from Patrick Dole, another Google engineer who wrote:

Patrick said…
I’m a tech lead on a project at Google. We very recently started using Scrum to see whether we could get better at producing more of what our customers wanted faster. I was the one who sold management on the idea; it didn’t come from above, so don’t blame them. So far this is working pretty well.

I understand that this is a personal blog, and Steve’s giving his opinion. Still, it bothers me because it gives what seems like a pretty inaccurate view of Google and what little I know about agile development (sorry, I don’t think it merits a capital ‘A’; it seems faintly ludicrous to me; maybe that’s the sort of thing that bothers him too).

As far as Google: there’s been a lot of talk here about the “Google way”, which sounds a heck of a lot like “Google methodology” to me. If there is one, I don’t know what it is, and I’ve been working here almost three years. Different groups use different approaches — some are design top-heavy, some are totally XP (though they are the minority), and some just lump new functionality in until they decide it’s done. Groups do what works for them, and nobody much seems to mind.

My point is: “Google” does not mean “doesn’t do agile.” It doesn’t mean anything remotely like that. We have an “intergrouplet” (a semi-formal organization of engineers supporting an aspect of engineering life, like documentation or the build system) devoted to agile, and upper management (who are not stupid people) supports the spread of agile ideas. So yes, we do agile at Google, big A and little a.

I spent a lot of time talking to people in that intergrouplet before we started trying Scrum. The attitude I got was, “Well, here’s what the books say, here’s what we’ve tried, and here’s what seems to work pretty well for us.” Which is what I wanted to know. I’m not interested getting a certification; I’m interested in making my group happier and more productive, and if there’s an idea that will help me do that, I’ll try it. Many of the agile ideas seem to fall in that category. We’re trying a few now, and if they work out we’ll try more later. If not, we’ll drop them. Maybe that means we’re not really doing official Scrum; but if it works, who cares?

What bothered me in these posts was the idea that anybody who used agile was either a gullible mark, or an unscrupulous consultant, or both. I’m not a consultant, and I don’t think I’m that gullible. When I first saw Steve’s post on “Good Agile, Bad Agile,” I thought, great, here’s somebody who’s opinions I respect, and I’m going to learn something. What I got seemed like pretty wild, unsubstantiated ranting about why agile is bad, without reference to any specifics, or any discussion of particular agile ideas he didn’t like. The one specific I do remember him disliking was pair programming, but the argument seemed to be, “Pair programming sounds stupid to me; therefore, it is stupid.” I’d be very happy to hear why it’s not a good idea, or anecdotal evidence about how it failed, but that’s not the kind of thing that’s going to convince me of anything other than his strong personal dislike of pair programming, the same way that some people don’t like science fiction or folk rock.

(I really wish, by the way, that Steve had described what experience he had with agile development; he said he’d tried it, but not what actually happened. Did he have to do daily standup meetings? Did his group do pair programming? Did they have regular meetings with the customers? Why didn’t it work? That’s a post I very badly want to read.)

I was depressed and frustrated by these posts, because they’re getting a lot of play, and the lesson people I talk to seem to be getting isn’t, “It’s okay to say no to Agile,” but “Agile is stupid, so don’t waste your time learning about it, and if you use any agile methods, you’re stupid.” I bet that Steve is a very good engineer, and I’m ready to be convinced, but I need more than that to do it.

It occurs to me that maybe the point wasn’t that agile development ideas are stupid, but that people have a tendency to turn ideas into religions, and while some agile ideas might be (and, I think, are) healthy for software engineering, the Church of Agile Development isn’t. That’s an idea I completely agree with.

My team has just started using Scrum at work, and despite what Steve claims that almost no one uses it at a companies like, it’s actually spreading like wildfire through that company. Not because it’s hip. Not because fancy consultants came in to run workshops. Not because Jeff Bezos said so. But because engineers want it. Why? Because they’re happiest when they’re building. And if something can help them build more and faster, they’ll give it the old college try.

Scrum may be the flavor of the day dev process. But it’s catching on so fast because it’s so damn simple and straightforward. You have a big list of projects that you keep in a big list called a “backlog.” Every month, you grab a subset of the backlog called a “Sprint backlog” and try to deliver shippable software in that time period. That’s all it is. You break your work out into small pieces so that you work incrementally which makes it easier to measure progress and change course when you need to.

Why I liked Patrick’s response so much, is his experience seemed very similar to what I’ve seen happen with a lot of teams internally at Amazon. They talk to some others that have tried Scrum and give it a try for their team. If it works, great. If not, great. Maybe they’ll try something else. All Patrick was looking from Steve was some sort of evidence about while Agile is so bad or over hyped. Given Patrick’s excellent response, Steve couldn’t resist answering him as follows:

Steve Yegge said…
Patrick: The well over 95% of teams at Google — and everywhere else, mind you — that do not use Agile needed a voice as well, precisely because of the Church problem you bring up in your last paragraph.

I would encourage you to be sensitive to the fact that it’s hard to back out of Scrum if it’s not working significantly better than not using it. (And you won’t really be able to tell; it’ll just be a “feeling”.)

You should run weekly double-blind polls with your team, peers, and management. If anyone goes limp, taps out, says stop, even if they’re faking it, the fight should be over, and you should put the process back on the shelf.

Talk about a non response. Patrick asked for examples of why Agile is not all it’s hyped to be and Steve came back with zero specifics. It makes me wonder whether Steve has actually tried Scrum himself? Now before you think I’m a Steve basher, far to the contrary. I’ve been in several meetings with Steve and he’s first class. I’m just stumped by his objective with this series of rants. Why belittle something that works well for others but fight for, as he claims, 95% of folks don’t use Agile methodologies? Weird.


4 Comments on “Agile”

  1. Greg Linden says:

    Thanks for pointing out that comment by Patrick, Andrej. Very interesting.
    On the scrum process at Amazon, what you said — “a big list of projects … every month, you grab a subset … deliver shippable software in that time period … break your work out into small pieces so that you work incrementally which makes it easier to measure progress and change course when you need to” — sounds a lot like what we were doing together back in 1999.
    Is that right? Are there differences or additions I am missing? I have skimmed a few summaries of Agile, but I am not familiar with the details. Can you tell me what is different about Agile (especially the scrum piece) from what we used to do?

  2. Andrej Gregov says:

    My high level description of Scrum does have a lot of similarities to how we built software back in ’99. What differs is really mostly procedural. For example, Scrum sprints are usually 30 days. 1999 projects were up to three months. In Scrum, you strive for delivering “potentially shippable software” by the end of every sprint. 1999 projects didn’t ship software until we finished implementing all requirements. If it took longer than three months, then we kept working. Scrum has the notion of a “sprint burn down.” It’s basically a plot of hours on the Y axis against time on the X axis. On a daily basis, you can see you progress on whether you’re going to finish all the scheduled tasks for the sprint. Oh, and the team meets _every_ day. Kind of like 1999 war team meetings right before a project launch to sync up and triage. We never miss a daily scrum. Even people working from home need to call in to the team “scrum” to report on their progress and get new assignments if necessary.
    Those are a few examples of differences from what we used to do back in 1999. Differences, as I said before, are really just procedural.
    If you’re interested in learning more, I’d encourage you to check out a Google Tech Talk from one of Scrum’s founders. Here.

  3. Greg Linden says:

    Thanks, Andrej. The daily meetings sound like an important difference. Projects tended to be short back in 1999 — 2-6 weeks was the norm I recall — but the more exploratory ones often targeted a prototype instead a potentially shippable project, so that might also be a difference. Thanks for elaborating.
    I did see that Google engEdu tech talk a few weeks back. I had a less positive reaction to it. To me, it felt more like someone preaching the faith than someone providing useful information. I particularly disliked his failure to acknowledge the success of and offer comparisons to other approaches.
    Thanks again, Andrej.

  4. Andrej Gregov says:

    Yeah, Scrum folks can often come across as religious and even demanding that you must stick to the model as described. I don’t care about any of that. There’s some interesting concepts in the Scum method. We still have a long way to go before we really determine it works. But for now, it’s been a positive experience.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s