Distributed Scrum In Large Projects

discovered after querying Product Owners during the Sprint with additional feature details.

Code is feature complete and the team provides a demo at the end of each Sprint. If it meets the Product Owner's functional requirement, it is considered done. It is not deliverable code, however, and SirsiDynix wants to strengthen its definition of quot;donequot; to include all testing. Failure to do this allows work in progress to cross Sprint boundaries, introducing wait times and greater risk into the project.

Scrum Masters and Architects
SirsiDynix was able to achieve strong central control of teams distributed across geographies by centrally locating ScrumMasters, Product Owners, and Architects. ScrumMasters are all located in Provo, Utah or Waterloo, Canada, and meet in a Scrum of Scrums every Monday morning to coordinate work across teams. Architects are all located in Utah as well, and are directly allocated to production Scrum teams. The Architecture group also meets on Monday after the Scrum of Scrums meeting to control the direction of the project architecture through the Scrum meetings. A Product Owner resident in Utah is assigned to each Scrum team. The Chief Product Owner meets regularly with all Product Owners to assure coordination of requirements. This setup enables SirsiDynix and StarSoft to get consistent performance across all distributed teams.

Knowledge Transfer
At the start of the project, SirsiDynix brought a key senior domain expert to St. Petersburg for a week to train the Russian engineers in the object domain and the library workflow. The client also demoed parts of the product to the Russian team. After that, top product architects come from Utah to St. Petersburg for three weeks to coach the Russian team in how the product works. At several points during the project, key members of the St. Petersburg team travel to SirsiDynix offices for training.

Having people rotate between the US and St. Petersburg helps achieve two goals: to share knowledge and to create personal connections between counterparts on both sides of the Atlantic. Introducing people personally creates a friendlier atmosphere, and work related issues are resolved much faster.

Marrying XP and Scrum
StarSoft is an XP company and tries to introduce XP practices into all its projects. Pair programming is done on more complicated pieces of functionality. Refactoring is a planned activity for some of the Sprints and is not done in every iteration as in XP. As you can see from Figure 2, some radical refactoring has occurred as the project approached completion of its critical stage, without loss of functionality. Another XP practice, continuous integration, is implemented through hourly builds from the central code repository.

Figure 2: SirsiDynix and StarSoft: Lines of new Java code in thousands (2003-2006)

Key Conclusions and Takeaways
his project is still active today, and there is always room for improvement. In fact, even as you are reading this, there are new approaches being tried by the project team to further improve quality and speed (e.g., some elements of test-driven development are being applied). However, both from an independent observer's point of view and from supplier's perspective, we want to offer you the following points for consideration:

1. Based on the average number of function points generated per developer/month in a waterfall project (which is 3 for a project this size) [2], the SirsiDynix project (with 15.3 function point generated per developer/month) is almost as productive as the small Scrum project with a collocated team of four to five people (17.8 FP per dev/m). For a globally dispersed team, it is one of the most productive projects ever documented at a run rate of more than five times industry