Scrum at Yahoo!

These days, there’s much written about Lean Software Development, Kanban for Software, and especially Lean Startup Principles for Software. This article revisits a time at Yahoo! about 12 years ago where Scrum was just getting its start at the once leader in search. If you’re interested, we’ve interviewed leaders in the lean startup movement.

The New York Times published an article comparing Yahoo! and Google’s products and their development times. It was an interesting read. In that article, the Ash Patel, Chief Product Officer at Yahoo!, mentioned Scrum as a method used to reduce software development time by managing team size:

Meanwhile, Yahoo says it is now trying to emulate Google’s faster method of creating products. Like most big companies, it used to develop software by first creating a comprehensive design that defined how features would be written and tested. Instead, it is now trying what is known as a scrum method, where it will plan, build and test parts of a product every 30 days.

Several days later, Pete Deemer, Chief Product Officer, Yahoo! Bangalore, made a post to the Scrum Group on Yahoo! and this is what he said:

What the Times doesn’t say is that Yahoo! is now 18 months into its adoption of Scrum, and has upwards of 500 people (and steadily growing) using Scrum in the US, Europe, and India. Scrum is being used successfully for projects ranging from new product development Yahoo! Podcasts, which won a webby 6 months after launch, was built start-to-finish in distributed Scrum between the US and India) to heavy-duty infrastructure work on Yahoo! Mail (which serves north of a hundred million users each month). Most (but not all) of the teams using Scrum at Yahoo! are doing it by the book, with active support from inside and outside coaches (both of which in my opinion are necessary for best results).

Pete Deemer Chief Product Officer, Yahoo! Bangalore / CSM

This is a testament to the Agile Method for developing software. At Amazon, we used a cowboy-scrum version which worked fine. But, I think doing things “by the book” often yields better results, provided that the method is tweaked to fit the company culture etc.

The great thing about creative and knowledge work is that it’s much easier to try new methodologies because of lack of physical inventory. The challenging part, however, is that the inventory that is present is virtual, which makes visual management difficult since there’s no physical inventory.

It’ll be curious to see what methodologies are adopted by the software development community in the upcoming years. What do you think?