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."
Really interesting article, thanks for the link.
Seems to me that Google’s approach is built upon trust, talent, and world-class "pride-driven" programmers; which is something that not all software development companies can afford (plus, the huge financial backup).
Still, it makes for a great read, if only for the insider info on Google’s inner workings ^^.
Cheers, Spartan.
It truly raises interesting points, but I think that both Agile methologies and Google’s work queue are based on the same principles. Both try to defer decisions until they can be made in an informed manner and, most importantly, both take the emphasis away from drafting and following a detailed plan.
The main difference seems to be in the periodical nature of Scrum sprints, that forces the team to deliver something every two weeks, and announce what you are doing every day. I believe this is not a problem, and can work as well as the Google method, as long as the presentations and the information is for your teammates, and not your manager.
If you are forced to "justify that we haven’t fired you yet" every day, in your daily scrum meeting, chances are you are not going to start the day in the best of moods. If, however, you are telling your coworkers how you finished a beautiful piece of code and it worked, or complaining loudly that the build kept exploding every time you sync’ed, then it’s a different story.
If you run an Agile project respecting the principle of focusing on people, not processes, and can keep nosy managers from expecting reports from everybody instead of letting information flow, then I see the same emergent motivation, and maybe even more, as you are constantly aware of the progress being made in the project.