Adjusting Scrum to Geographically Distributed Development

By Peter Vaihansky, Senior Vice President, DataArt The strength of Scrum, the most widely accepted Agile process, is in relying on relatively small, self-contained, cross functional, co-located teams …

An intense focus on communication can make geographically distributed teams even more productive despite the distance, writes Peter Vaihansky.

By Peter Vaihansky, Senior Vice President, DataArt

The strength of Scrum, the most widely accepted Agile process, is in relying on relatively small, self-contained, cross functional, co-located teams working very closely together, and therefore achieving extremely high productivity and quality. Scrum teams are in constant, intense communication that produces emergent tacit knowledge, which enables them to build high quality software that closely meets their customers’ needs.

On the other hand, software development is now almost inherently globalized. Many companies today have development teams, partners, vendors or clients in different countries and sometimes even on different continents, many thousands of miles and time zones apart. Even within a single country, or even a single metropolitan area, an increasing number of professionals these days are working remotely. Let’s discuss what someone wishing to harness the benefits of Scrum while taking advantage of globalization and telecommuting needs to keep in mind.

Communication: Even More Critical

Agile emphasizes constant communication between team members and customer representatives over strictly following a documented plan. Anyone who has experience building software will recognize that customers often can’t know exactly and exhaustively what they want from the system until they get it. In that context, it is clear that having the team be co-located must carry a very definite advantage. However, empirical evidence shows that distributed teams can and do achieve incredibly high productivity. Dr. Jeff Sutherland, co-inventor of Scrum, has theorized that geographically distributed teams must pay even more attention to communication, and that increased focus perhaps makes them even more productive despite the distance.

In practical terms, in situations where your team is located predominantly in two time zones, it often makes sense to have a “local” and a “global” daily Scrum. First, the part of the team further east gets together for their local standup meeting to kick off the day. When their counterparts in the Western location come in for work, the global Scrum is scheduled, using some communication platform: it can be a Google Hangout, a Skype video call, or something else. Other Scrum meetings, like the sprint planning meeting or sprint retrospectives, are more difficult to plan for a geographically distributed team because they require the participation of all team members at the same time. Also, it is important not to interpret silence as agreement: Scrum calls for active participation in the decision making by all team members, and it is ever more critical to have an experienced facilitator (Scrum Master) drive Scrum meetings and ensure that everyone gets a chance and is actively encouraged to voice their concerns, ask questions and acknowledge decisions.

Tools: Defeating the Distance

Speaking of technical tools, these are also going to be critical enablers of distributed Agile development. Broadly speaking, there are three categories of issues that tools will help address:

  • Project management and tracking
  • Information radiators
  • Ongoing communication without co-location

Even co-located teams need systems and tools to manage and track the project’s requirements, progress, budget, source code, artifacts and documents, defects and issues. The market is saturated with mature software lifecycle management offerings that cover the whole gamut and conform to multiple Agile paradigms, including Scrum, Kanban and others. From market leaders like VersionOne, Rally, JIRA and Pivotal to a plethora of lesser-known or specialized products, Scrum teams have a wide choice of tools available to them.

The same products are more than likely capable of addressing the issue of information radiators – “public spaces” where the project’s status and progress is quantified and visualized, like the Scrum board or the burndown chart. Here again, there is a very broad menu of options that give teams intuitive, easy to use, virtual “whiteboards,” so that all members of a distributed group are always on the same page.

For ongoing communication, distributed teams often use group chats in ubiquitous products like Skype or Google Hangout. All team members agree to pay attention to the group chat window throughout their day and respond accordingly – it becomes another team public space, and this approach works well enough for most teams. Sometimes a couple of team members will create a smaller group chat to discuss a particular issue – those are less permanent and will form and dissolve on demand.  When voice and chat is not enough, screen sharing comes in handy. Both Skype and Google have that functionality, but there are many other excellent free tools, like

Sign up for our Nearshore Americas newsletter:

Sometimes a co-located subset of the team may get together in the same conference room and start whiteboarding ideas. They later take snapshots of the whiteboard and share them in the group chat so eventually everyone has access to the same visuals. We even have experience of teams doing virtual whiteboarding, where one team member sketches an architectural diagram on a sheet of paper with their pencil, snaps a picture of it with their smartphone and sends it to a colleague, who later edits the image in Paint and shares it back to the group! As you can see, with today’s technologies, the options are almost limitless and make remote collaboration not only feasible, but effective.

Doing Scrum in a Global Marketplace

If your development team is spread across multiple countries, and you’re dealing with different languages and cultures, then you have another set of issues to pay attention to. While most multinational development teams will probably use English as their working language, accents may differ across the team, which could make understanding each other slightly more challenging. Therefore, it’s important to encourage your team members to ask their colleagues to repeat themselves if someone is not coming through clearly on a Scrum call, which some people may be uncomfortable doing for fear of appearing impolite. These and other cultural subtleties can have a direct impact on how well the team works together, and so they deserve separate consideration in an international setting.

In general, based on our experience, it is advisable to budget for some amount of travel when dealing with a geographically distributed team, especially if you expect the team to work together for any serious duration. Without a doubt, time spent face-to-face is a great investment. The experience of meeting your fellow team members and spending some time working together in person acts as a very effective “lubricant” for further remote communication.