News

Is Google Going Agile?

A Google program manager last week announced the company was changing its software development methodologies to speed up stable releases of the Chrome Web browser.

• By David Ramel
• 07/30/2010

A Google program manager last week announced the company was changing its software development methodologies to speed up stable releases of the Chrome Web browser.

"Running under ideal conditions, we will be looking to release a new stable version about once every six weeks, roughly twice as often as we do today," said Anthony Laforge in a post on The Chromium Blog.

The three reasons for the change were listed as:

• Shorten the release cycle and still get great features in front of users when they are ready
• Make the schedule more predictable and easier to scope
• Reduce the pressure on engineering to "make" a release

Although the post hinted at Agile-like practices, the word Agile was never used. Some observers, however, indicated that Agile was in at Google.

"The basic premise behind the Agile software development methodology is to release early and often to increase incremental innovation. It's an approach that Google is now set to fully embrace with open arms for its Chrome Web browser," read an article on Datamation the day after the blog post.

A reader posted a comment on Laforge's blog asking about whether the company was indeed using Agile: "I was wondering: Apparently you guys are using an Agile approach. What are you guys applying? Scrum, TDD, something else?"

His question wasn't addressed by Laforge, but another reader's answer seemed to imply the Chrome development process wasn't really Agile. "Six weeks is still on the long side for Agile and will likely lose some of the benefits," said "Ian." He also commented, "I think a lot of these questions are from lack of exposure to agile," before posting some links so readers could bone up on their understanding of Agile.

Interestingly, a similar situation came up in October 2008 in a TechTarget interview with Darin Fisher, a software engineer who worked on developing Chrome. "Some might say certain elements seem like Agile programming, but we didn't specifically say let's use this methodology; we just said we'd do what seems right," Fisher said.

In describing how the team came up with its requirements, he said:

A lot of the process involved brainstorming meetings with the team and we talked about features. We also had an open mail list internally at Google where people said what would be cool. Then a smaller team went through and generated a living document, a beta roadmap, that said here's a set of features we know we've got to do. It included not only requirements for the browser, but a few things that would make it a compelling beta product. We tried to keep the features very focused and minimal. We're adverse to feature creep. Then we shared the list with the whole team, and people would self-select for what they wanted to work on.

About a year later, blogger Todd Hoff reported on a presentation by Glen Murphy, described as Chrome's designer and an engineer on its front-end team. He titled the post: "Google Chrome's Agile Design and Development." However, after a comprehensive account of the presentation, Hoff said, "The word 'agile' wasn't mentioned in the presentation, but they are describing a very agile way of working. Small multi-talented groups working in tight iterations implementing features based on vision and customer feedback. Working code is valued over documentation. The result is a quality product with a very comfortable and natural feel."