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 1 depicts the process goal diagram for Explore Scope and Figure 2 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 2. The Identify Architecture Strategy process goal.
Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.
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 3 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.
Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.
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.