Chapter 8. Will Scrum Work for Multi-Location Development?

Pete Deemer

(Spoiler alert) Yes! Scrum works great for multi-location development! However, Scrum is not the silver bullet that makes it magically work.

Scrum is a very simple set of practices that, together, produce a high degree of transparency, showing us the reality of our situation more clearly. Scrum creates transparency around what we are able to do in one to four weeks. Scrum enables us to see clearly the quality and rightness of what we produced and the quantity we were able to finish. Scrum confronts us with the effectiveness of our practices, including the patterns of dysfunction and the mistakes we are making. Most importantly of all, Scrum gives us the opportunity to use these insights to improve in the next Sprint. So, the statement, “Scrum works great for multi-location development!” means that Scrum is great at clearly showing us all the dysfunctions and inefficiencies we’re experiencing. And distributed projects tend to have a lot of those!

At its heart, software development is an activity of taking the product of human thought and logical reasoning and making it repeatable in the form of code. For a team to develop software, their ability to commune their thoughts through shared understanding, collaboration, and communication is the key driver of output. In multi-location projects, this activity is made most difficult by the myriad forms of separation faced: physical separation, time zone separation, cultural and language separation, and the difficulties that come with language and cultural barriers. The first Sprint that a multi-location team completes is likely going to be a rich circus of dysfunction—and the likely conclusion is going to be that “this just isn’t working.” That realization is a critical first step on the path to success. The next step is to enumerate everything that did not work well and formulate actions in the next Sprint to make them work better.

For example, it could be that in the first Sprint, the product Increment didn’t meet the definition of “Done.” In the Sprint Retrospective, the Scrum Team identifies the major root causes, such as lack of a clear common understanding of the Sprint goal, lack of communication within the team leading to a lack of coordination, and lack of trust among the team members. As a result, actions are taken on each of these in the second Sprint (for ideas, see the Distributed Scrum Primer), and that Sprint produces slightly better results. As often happens, in the subsequent Sprints, other sets of issues become visible, and whole new sets of improvements are identified every time. The Scrum Team gradually evolves, Sprint by Sprint, to a better and better way of working.

Will Scrum “magically” make every distributed Scrum Team effective? No. In fact, no methodology has this ability, although some make that promise. The radical innovation of Scrum is its rejection of the idea of a methodology-based path to success. Instead, Scrum is a simple framework built around inspection and adaptation that creates continuous transparency around the unique environment and characteristics of a given situation while creating the opportunity for improvement. The only question is how much bold action the team is willing and able to embrace!