Via Joel, I ran into this excellent article and discussion: “Good Agile, Bad Agile." It’s long and detailed, but very humorous and energic. It attacks the “official” approach to Agile Development and Extreme Programming, and then moves on to discuss how Google’s process is vastly superior to anything else.

Obviously, what works for Google may not necessarily work for other companies, other products, and other markets. What company could afford to run a beta for over two years, and not be laughed at? How many companies can pretty much create a new market, and define the rules by which it works? What companies have had the chance to build up from large amounts of purely speculative investment? And, more importantly, it is unclear how sustainable the whole Google business and development models are in the long term.

A few quotes if you still haven’t jumped to read the article itself:

– “that’s how both Extreme Programming and Scientology were born."

– “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."

– “Traditional software development can safely be called Date-Oriented Programming."

– “Google isn’t foolish enough or presumptuous enough to claim to know how long stuff should take."

– “With nothing more than a work queue (a priority queue, of course), you immediately attain most of the supposedly magical benefits of Agile Methodologies."

It’s now up to you to read the whole thing and judge for yourself. All I can say is that I tend to run game projects in a way that shifts from the plain old waterfall approach of strictly separate stages, into a spiral model where results and future steps are fed back into the process, and ending with… yeah, a reasonably prioritised queue of tasks that need to be completed. However, I take to heart the Agile mantra of “always have something that works.” Or, if not always, then at least “make sure you know when, and why, you don’t have something that works.”