(2006-10-02) Yegge Agile Google

Steve Yegge on Good-and-Bad Agile Software Development, and Project Management/Product Management at Google. Well, people pretty quickly demonstrated that XP was a load of crap. Take Pair Programming, for instance. It's one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let's face it: nobody does it... One of the (many) problems with Bad Agile is that they condescendingly lump all non-Agile development practices together into two buckets: WaterFall and Cowboy. Waterfall is known to be bad; I hope we can just take that as an axiom today. But what about so-called Cowboy programming, which the Agileers define as "each member of the team does what he or she thinks is best"? Is it true that this is the only other development process? And is Cowboy Programming actually bad? They say it as if it's obviously bad, but they're not super clear on how or why, other than to assert that it's, you know, "chaos".

First, and arguably most importantly, Google drives behavior through incentives... The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude... The basic idea behind Project Management is that you drive a project to completion. It's an overt process, a shepherding: by dint of leadership, and organization, and sheer force of will, you cause something to happen that wouldn't otherwise have happened on its own... We do have project managers and product managers and people managers and tech leads and so on. But the amount of energy they need to add to the system is far less than what's typically needed in our industry. It's more of an occasional nudge than a full-fledged continuous push... Incidentally, Google is a polite company, so there's no yelling, nor wailing and gnashing of teeth, nor escalation and finger-pointing, nor any of the artifacts produced at companies where senior management yells a lot... All your needs are taken care of so that you can focus, and as I've described, there are lots of incentives for focusing on things that Google likes. So launches become an Emergent property of the system... This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on... Google isn't the only place where projects are run this way. Two other kinds of organizations leap to mind when you think of Google's approach: Start Up companies, and Grad School-s.

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about.

Google is unquestionably driven by time, in the sense that they want things done "as fast as possible". They have many fierce, brilliant competitors, and they have to slake their thirsty investors' need for growth, and each of us has some long-term plans and deliverables we'd like to see come to fruition in our lifetimes. The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take (No Estimates). So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google. (Planning)

Then all you need is a Work Queue (Development Queue). That's it. You want hand-wavy math? I've got it in abundance: software development modeled on queuing theory. Not too far off the mark, though; many folks in our industry have noticed that organizational models are a lot like software models. With nothing more than a work queue (a priority queue, of course), you immediately attain most of the supposedly magical benefits of Agile Methodologies. And make no mistake, it's better to have it in software than on a bunch of Index Card-s. If you're not convinced, then I will steal your index cards.

Related: interesting Fortune Mag article on management at Google, with some focus on Shona Brown, the senior vice president for business operations who wrote Competing On The Edge: Strategy as Structured Chaos back in 1998 (Edge Of Chaos?). Brown runs a SWAT team of 25 strategic consultants who are loaned out internally on ten or so projects at a time - restructuring a regional sales force here, guesstimating a market size there. The company's goal, says Brown, is to determine precisely the amount of management it needs - and then use a little bit less.