The majority of agile teams are geographically distributed in some manner. This article explores how geographic distribution affects agile teams. To do this we address a series of questions:
- What does it mean to be geographically distributed?
- Are agile teams geographically distributed in practice?
- How does geographic distribution relate to other scaling factors?
- What are the potential benefits of geographic distribution?
- What are the risks associated with geographic distribution?
- How can we reduce these risks?
- How do we organize a geographically distributed agile team?
- How does geographic distribution affect tooling choices?
- Is geographic distribution a good idea?
- Where do we start?
- What other resources exist?
What Does it Mean to Be Geographically Distributed?
Your team is considered co-located when the developers and the primary stakeholders are all situated in the same work room. Otherwise your team is either geographically distributed or dispersed in some manner. Even when you have some team members in cubicles or in separate offices you’re slightly distributed. It may not be obvious at first, but even this level of geographic distribution – people being separated by cubicle walls and several meters apart – injects communication risk into your team. And it gets worse. Team members may be working on different floors in the same building, they may be working in different buildings within the same geographic area (perhaps your team is spread across different office buildings in the same city or some people work from home some days), they may be working in different cities in the same country, or working in different cities around the globe. In many cases it is a combination of several of the above.
Figure 1 overviews the differences between geographic distribution and geographic dispersion. A team is fully dispersed when nobody sits together. In this case they may be in different cubicles or offices within the same building, or working from separate buildings. Sometimes we have what is known as distributed sub-teams, where there are one or more co-located teams at different locations (even different ends of the same floor within a building). Many times a team is partially dispersed in that several people sit together at the same location but a few sit elsewhere (perhaps in cubicles or at home). Then of course there is the combination of distributed sub-teams where one or more of the sub-teams is partially dispersed (not shown). Throughout this article, we will use the following terms:
- Geographically distributed teams. For the sake of simplicity this include teams that are either geographic distributed or that include geographically dispersed team members.
- Co-located. Teams where the developers are in a single room, often called a “war room,” “pod,” or “tiger team room,” working beside one another.
- Near-located. All team members are within reasonable driving distance (e.g. if would be possible for everyone to come into a single location each day if required).
- Far-located. One or more people are far enough away that they would likely need to take a flight in order to meet with other team members physically.
Figure 1. Geographic distribution and dispersion.
Are Agile Teams Geographically Distributed?
Yes, the majority of agile teams are geographically distributed in some way. The 2014 Software Development at Scale Survey found that 39% of teams are (mostly) co-located, 23% of teams were near-located, and 38% of teams were far located as you can see in Figure 2. Please note that this survey only asked about development team members, not whether stakeholders were also in the room. Previous surveys have found that it is rather rare for stakeholders to also be co-located with the development team, the implication being that 39% is a very optimistic estimate for how co-located agile teams are.
Figure 2: Agile teams and geographic distribution.
As you can see in Figure 3, the 2012 Agility at Scale survey found that organizations are having success (the green bars) at all levels of geographic distribution. It also indicates that some organizations are failing (the red bars) at each level of geographic distribution. The implication of this study is that although it is possible to succeed with agile development regardless of how geographically distributed the team is, that there are not guarantees that you will in fact be successful. This is why the advice in this article should be of interest to you.
Figure 3: Agile experiences with geographic distribution.
The bottom line is that some organizations have been very successful applying agile techniques on geographically distributed teams. In fact, as you saw in Figure 2 geographically distributed agile development is far more common than mainstream agile discussions seem to let on.
How Does Geographic Distribution Relate to Other Scaling Factors?
The Software Development Context Framework (SDCF) calls out six scaling factors, see Figure 4, one of which is geographic distribution. We’ve found that there are three other scaling factors which are often co-related with geographic distribution:
- Domain complexity. A complex problem often drives the need for larger teams, which in turn drives the need for geographically distributed teams.
- Team size. It isn’t always possible to staff a large agile team from a single location as you may not have enough people with the right skills all in one place. As a result, the larger a team gets the more likely it is that it will be at least partially distributed.
- Organizational distribution. Many times one of the reasons why a team is geographically distributed is because a portion of the work is being outsourced.
Figure 4. The scaling factors of the SDCF.
What are the Potential Benefits of Geographic Distribution?
There are in fact several potential benefits to geographic distribution:
- Access to a larger pool of skilled people. Many organizations struggle to staff their IT departments solely with local people, particularly when specific skills are needed.
- Lower development costs. On the surface savings are the result of the wage differential between countries and sometimes even cities within the same country. However, these savings can be quickly lost due to the increased overhead associated with geographic distribution – you must consider total cost of ownership (TCO), not just hourly programmer costs, when calculating the cost savings. It is still possible to gain cost savings, but you must be sufficiently disciplined to earn them.
- Quicker time to market. The opportunity for quicker delivery times exist when your team is disciplined enough to take a “follow the sun” approach. The basic idea is that a globally distributed sub-team will do their work during their day time, then hand-off the work to a team that is several time zones away. This team will then do some work, then hand it off to the next team. This is very difficult to make work in practice, requiring a solid architecture, high quality code, development standards, automated regression tests, and sophisticated configuration management. We’ve seen it done successfully, often with either 2 or 3 teams in the overall cycle, although most organizations struggle to make this strategy work in practice. However, one of the challenges is access to a Product Owner (or a proxy Product Owner) as the “single source of truth” twenty-four hours a day.
What Risks Are Associated with Geographic Distribution?
As your team becomes more distributed your project risk increases for several reasons:
- Communication challenges. The most effective means of communication between two or more people is face-to-face around a shared sketching space such as a whiteboard or piece of paper. Of course, this requires you to be in the same room together. As you become more distributed you begin to rely on less effective communication strategies, as you can see in Figure 5, but which provide better persistence of the captured information. When you’re not face-to-face you are unable to observe body language which embodies a lot of valuable communication cues.
- Temporal challenges. When people are in different time zones it becomes harder to find common working times, increasing the communication challenges. To combat these challenges you will find that you need to create more documentation than you normally would, as implied by Figure 5. More on this later.
- Cultural challenges. As the team becomes more distributed the cultural challenges between sites often increases. Different cultures have different work ethics, treat intellectual property differently, have different ideas about commitment, may be less inclined to embrace self-organization, have different holidays, different approaches to things, and so on. Something as “simple” as what it means when someone says “yes” can be very challenging in practice.
Figure 5. Comparing communication strategies.
Because risk increases the more distributed your team is, the lower the average success rates of agile projects decrease as they become more geographically distributed. As you can see in Figure 6 the 2008 IT Project Success Survey found that co-located agile teams has an average success rate of 79%, that near-located teams (where members were in same geographic area) had a success rate of 73%, and that far-located agile teams had a success rate of 55%. The success rate decreases similarly for project teams following other paradigms.
Figure 6: Success rates by level of geographic distribution.
How Can We Reduce These Risks?
Although geographically distributed agile software development is clearly a risky proposition, there are several strategies you can adopt to overcome these risks:
Strategy 1: Build a Positive Team Culture
This is important for any team, but is particularly critical for geographically distributed teams due to the increased difficulty around communication and collaboration. You want to promote a culture that is based on collaboration and respect, a culture where people want to work with one another even when they are very far apart.
Strategy 2: Get the Key Team Members Together at the Beginning
One of the riskiest times during a project is the very beginning. This is the time where you build the foundation for an effective team, where you develop a common vision for the team to work towards, and where you get going in the right direction. Or this is the time where you don’t do that.
Our suggestion is that you get at least the key people involved with your effort – such as the Team Lead, Product Owner, Architecture Owner, and important stakeholders – together at the beginning to work through important aspects of how you’re going to work together. This includes initial modeling of the scope and your technical strategy, initial high level planning, and initial risk assessment. Ideally you would get all team members and key stakeholders together at the beginning, or at least the ones currently involved, so as to come to an agreed-to vision. Obviously this is more expensive than getting just the key people together, but it will enable you to be a more solid foundation for team success.
The implication is that you will need to fly some people around, increasing your initial expenses, an investment that many organizations balk at. The reality is that you will eventually end up paying for travel anyway, either because you actually flew people around or because your communication costs are higher throughout the project. In the majority of cases it is much less expensive to get people together at the beginning of a project than it is to not do so.
Strategy #3: Do a Bit More Up-Front Modeling
You will want to do a bit more up-front requirements and architectural modeling due to the increased risks associated with geographically distributed teams. Figure 7 depicts the process goal diagram for Explore Scope and Figure 8 the process goal diagram for Identify Architecture Strategy. In both cases you will find that you need to become a bit more formal with the amount of documentation that you create, capturing your models using electronic tools such as Wikis, drawing tools such as Visio, or even modeling/CASE tools such as Blueprint or Enterprise Architect. You may also find that you need to create a few extra views than you normally would compared to a co-located team due to the need to promote a more thorough understanding of your strategy at each disparate location.
Figure 7. The Explore Scope process goal (click to enlarge).
Strategy #4: Do a Bit More Up-Front Planning
Because geographically distributed development is higher risk than co-located development you will likely want to invest a bit more effort thinking through your plan. That doesn’t mean that you need to create a monolithic, 1000+ task Gantt chart, but it does mean that you should identify your major dependencies and milestone dates. Effective teams do this planning with the distributed developers actively involved (they are part of the team after all), they strive to consider all associated costs, and in particular they don’t overlook the low probability/high impact risks which often prove to be project killers. Figure 9 depicts the Develop Release Plan process goal diagram – In the case of a geographically distributed team, you’ll find that a manager/lead facilitated strategy that is predictive light in nature works well for most teams.
Figure 9. The Develop Release Plan process goal (click to enlarge).
Strategy #5: Integrate Regularly
Agile teams should integrate regularly, hopefully many times a day, so as to reduce the feedback and thereby increase their productivity. The same is true of geographically distributed teams, although this can prove to be difficult when the team has taken on a complex or large problem – the more complicated the solution, generally the harder it is to integrate. Large or geographically distributed teams often find that they need a sub-team that is specifically tasked with the overall integration and end-to-end testing of the entire solution. Other sub-teams will integrate and test their work to the best of their ability, and ideally this additional team isn’t even needed, however it sometimes proves economical to have this separate team to handle the integration and testing issues that tend to fall through the crack in a “team of teams” situation that is typical of large programs or geographically distributed teams.
In the Scaled Agile Framework (SAFe) this strategy is called an integration team. However, in DAD we typically call this an Independent Testing Team, or Independent Testing and Integration Team, due to the observation that the majority of the effort is actually focused on testing.
Strategy #6: Recognize that Communication is Critical
GDD puts many barriers to communication in place, increasing overall project risk. To overcome these risks you will first need to be aware of them and act accordingly, and second, you’ll need to write more documentation than you would likely prefer. The risks associated with long-distance communication include cultural differences, time-zone differences, and the challenges with written documentation (which is actually the least effective way to communicate information). Make it a habit to ask open-ended questions so that you can determine whether or not the other people truly understand the topic of conversation. Never ask a yes/no style of question because the simple answer of yes can mean a range of things depending on the culture. It may mean “Yes, I heard you”, “Yes, I understand what you’re saying”, or “Yes, I understand and agree with you”. When you’re dealing with people at other locations it is a good practice to ask them to summarize the conversation, in particular to identify key action items and ownership of them, to ensure that everyone agrees with what was discussed. A good approach is to have the team lead on other end to do the summary so that they own it going forward. This of course should be done in as light-weight manner as possible.
Strategy #7: Have Daily Coordination Meetings
A common practice on co-located agile teams is to have daily coordination meetings, sometimes called a stand-up meeting or Scrum meeting. Distributed teams can do this as well, the people in a given geographical location can hold local stand-up meetings and then representatives from each location can hold a shared meeting to coordinate the sub-teams. This strategy is typically called a “Scrum of Scrums” and it works well up to five or six sub-teams although needs to be replaced with a boundary spanner strategy (see below) for larger efforts.
Disparate time zones can be a challenge. Whereas local stand-up meetings are held first thing in the morning, distributed daily stand-up meetings may need to be held at unusual times so as to include people at distant locations. Similarly, coordination between sub-teams needs to occur at times which are respectful to those sub-teams, which can be difficult when the time zone difference is greater than a working day. For example, the time zone difference between Toronto and Pune is currently 10.5 hours, implying that the representative from at least one if not both locations must be on the coordination call at an uncomfortable time for them. To spread out the pain of such calls, and to work in a respectful manner, many teams will choose to rotate the times of the coordination calls.
Strategy #8: Have Ambassadors Travelling Between Far-Located Sites Regularly
Getting the team together at the beginning of the project sets the foundation for communication, but without continual investment in maintaining effective collaboration between teams you run the risk of your sub-teams deviating from the overall strategy. Ambassadors are people who regularly travel between sites, often technically senior people or senior business experts, who share information between the sub-teams. Ambassadors have short engagements away from their home site, typically a week or two in length, because of the pressures it puts on the people doing the actual traveling. As a result you’ll have several people flying between sites at any given time on a reasonable rotation schedule. An implication of this practice is that your local team rooms should accommodate ambassadors by having one or more desks available for them to use when they’re visiting.
Strategy #9: Have Boundary Spanners at Each Site
A boundary spanner is someone who is located on site who focuses on enabling communication between sub-teams throughout the day as well as within their sub-team. On Disciplined Agile Delivery (DAD) teams you’ll find that you have three flavors of boundary spanners – Team Leads coordinate project management responsibilities between sub-teams, Product Owners who are responsible for coordinate requirements management issues between sub-teams, and Architecture Owners responsible coordinating technical issues between sub-teams. These boundary spanners will work closely with their peers, having regular coordination meetings across all sub-teams as well as impromptu one-on-one meetings to deal with specific issues between individual sub-teams.
How do We Organize a Geographically Distributed Agile Team?
There are four basic strategies, compared in Table 1, for organizing large or geographically distributed sub-teams:
- Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams. Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
- Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end. This is often referred to as implementing a vertical slice of the solution. Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
- Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on. Each team focuses on their specialized function and hands off their work to other functional teams.
- Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization. Developers from other teams voluntarily work on the component to evolve it over time. When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products. For some detailed thoughts on strategy, read Reuse Through Internal Open Source.
Table 1. Comparing the team organization approaches.
|Internal open source||
How Does Geographic Distribution Affect Tooling Choices?
Geographically distributed agile teams, at least the effective ones, will also use tools which reflect the realities of agile geographically distributed development (GDD). Although index cards are a great way for co-located agile teams to capture high-level requirements such as user stories, you need an electronic strategy for a GDD team. You will need to consider tooling to support:
- Long-distance communication. You’ll want to consider investing in videoconferencing tools, teleconferencing tools, chatroom software, and even discussion forum software.
- Information sharing. You will need tools to share information between sites. This could be something as simple as a Wiki or a shared folder environment such as Dropbox. You may also want to consider artifact repositories.
- Planning and coordination. Geographically distributed teams tend to adopt software such as Jira or Microsoft TFS that enables them to manage their task boards.
- Tools to capture diagrams. A simple solution is to capture whiteboard sketches using phone camera and then sharing them via your information sharing strategy. Many teams will use simple diagramming tools, such a SmartDraw or Visio, to capture important diagrams. The advantages of these tools are that it is easy to update the diagrams at a future date. Some teams will even adopt software-based modeling tools, such as Blueprint or Enterprise Architect, to capture their work.
Is Geographic Distribution a Good Idea?
It depends, but generally no. As you saw in Figure 6, the rate of success drops quickly the further apart people are. This is due to the increased risks associated with geographic distribution as well as the increased complexity of your organizational structure, process, and tooling configurations required to address these risks. Our advice is to get good at co-located agile development first, then try near-located, and then only when you’re successful at these should you consider far-located development. In other words, learn to crawl first, then walk, then finally run.
Where Do We Start?
We just wanted to round out our discussion about agile approaches to geographically distributed development (GDD) with a few important words of advice:
- Get some experience. Worry less about enterprise-level adoption and instead get started with a small project, or better yet a series of increasingly more complex projects. There will be learning experiences as you build a relationship with the offshore service provider. This advice is applicable whether you’re working with your own offshore division or with an independent service provider.
- Have a long-term staffing strategy. It may be great in the short term to have work done in a lower cost country, but how are you going to transfer the necessary skills to the sustainment team? Outsourcing that work is also an option, but it can be a risky one as you would need to build up expertise in “your” systems if you ever decide to insource that work again.
- Be concerned about intellectual property (IP). The rules are different around the world, and you may inadvertently be financing the creation of a new international competitor if you don’t have a clear division of ownership. And yes, this may mean that some components of your systems are still built internally by your own organization.
- Show off locally before you go global. GDD makes things harder to manage, so if you’re struggling to manage local teams you’re really going to struggle managing teams at a distance. Make sure you have local success first and are good at agile development in general. Furthermore, if your agile GDD projects run into trouble, don’t end your local agile adoption just because of difficulties with distributed projects.
- Let your offshore partners lead. The offshore partner likely has more experience than you at successful distributed development, and this is particularly true when you’re dealing with an established service provider.
- Prefer north-south distribution. If you are going to seek cost advantages of distributed development, consider going north or south before east or west to minimize time zone differences.
- Book: Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery.
This book is the primary source of information about the practices and strategies promoted by DAD.
- Book: A Practical Guide to Distributed Scrum.
This book provides practical advice for geographically distributed agile development teams. It addresses large-team issues, which often go hand-in-hand with geographic distribution, as well a technical and domain complexity issues too and reflects actual experiences at scaling agile development techniques.