A description of the approach used by Yahoo International in its transition to agile software development.

Author: Franco Martinig, Martinig & Associates, http://www.martinig.ch/


I had the chance to assist to the Geneva stage of the Agile Tour, an itinerary French-speaking agile conference. Alexandre Boutin made a very interesting presentation about the transition to agile by Yahoo International (the non-US operations of Yahoo). When he joined Yahoo in 2004, the development process was mainly chaotic. Developers were producing software with “mostly” heroic attitudes and had to be available 24/24 to solve production problems. His first action was to put in place a traditional development process with control points. Local quality assurance teams were also created. This improved the quality of the delivered software. Asiatic teams were also pleased by the change. On the negative side, he saw some resistance from the UK teams that were already using Scrum. Some developers had also a tendency to “hide” themselves behind the process and escape responsibilities.

In 2007, agility was introduced in the organization, but not as a mandatory solution, because Alexandre Boutin thinks that you cannot force the people to be agile. The detailed process was abandoned for a process framework described on two A4 pages. The local quality people were transformed in agile coaches. The formal validations after each process stage were replaced by risk management checklists, not considered as “todo” lists, but to make sure that the team has examined all risk before moving to the next stage. All employees followed two days of agile training. As a consequence, Scrum was adopted by all European teams and used in some pilot projects in Asia. The transition to agile coaching was not obvious for all former quality people. An important regret was the missing of metrics collected during the previous years. This absence makes it more difficult to justify the change to the management with quality or productivity improvements.

Actions were taken in 2008 to help product (business) teams to work better with agile projects. Continuous integration was put in place with metrics to evaluate development teams:
* Velocity (inside the team only)
* Number of build successful or failed (build runs every two hours)
* Number of tests (but not test coverage)
* Number of bugs discovered during the first five days after a release.

In the positive results achieved during this transition, Alexandre Boutin mentions the good acceptance of the framework process. Scrum is also a considered a good project management approach, but it needs to be combined with good practices, especially for the testing activity. He recommends also to have a strong local coaching support and to train the developers again four to five months after starting doing agile projects. Development teams are now releasing new versions every four weeks, some of them aiming for a two-week release cycle. He has seen a strong improvement in people motivation and product quality. Culture seems to be the most important challenge to implement an agile approach in Asia. Hierarchical respect made it more difficult to carry the negotiation activities around the backlog. Daily-meetings done by phone for geographically distributed teams were also not successful. Finally, more efforts have to be made to assist the business users concerned by agile projects.

A word to remind: it is easier to “do” agile than to “be” agile.