January 2012

Volume 27 Number 01

Agile Development - Working with Agile in a Distributed Team Environment

By Sandeep Joshi | January 2012

Although Agile processes are being used increasingly in many software development environments, some enterprises still haven’t adopted Agile because of various concerns, especially about using it with distributed teams. In this article, I focus on the obstacles to using Agile in a distributed team environment and recommend how to counter them with what I call “de-Agile.”

Co-location vs. Distributed Teams

Teams co-locate because it maximizes their ability to communicate in person. Working in the same room is core to all the Agile methodologies, including scrum. As Ken Schwaber, author of The Enterprise and Scrum, said, “The best communication is face to face, with communications occurring through facial expression, body language, intonation and words. When a white board is thrown in and the teams work out design as a group, the communication bandwidth absolutely sizzles.”

Given that communication is such a significant part of the efforts involved in delivering software, why then are distributed teams so prevalent? The answer speaks to the reality of doing business today: a company’s need to have a global presence, to access global talent and to develop outsourced options.

In the 2010 State of Agile survey conducted by VersionOne (which you can download at versionone.com/state_of_agile_development_survey/10/page3.asp), more than half the survey respondents said they are currently using Agile with both co-located and distributed teams, or planning to do so in the future. Although co-locating your team is the recommended, optimal approach for implementing Agile processes, many teams are unable to do so for critical business reasons and must learn to follow Agile principles and practices in a distributed development. The information in the rest of this article will explain how to do that.

De-Agile for Distributed Teams

What I mean by de-Agile is tailoring Agile to fit your team by taking out processes that don’t make sense and tweaking those that need to be modified to suit your needs. In a distributed team environment, de-Agile is mostly about removing the sense of being distributed. You need to educate each team member about the additional communication responsibilities required when working with remote team members and emphasize the importance of being open and available. Everyone on the team needs to be committed to making Agile work in this environment, and managers -- including the top tier -- must support the tools and processes required.

If you want your team to adopt Agile practices, you might need to play the roles of facilitator and mentor at some point. The de-Agile route will inevitably have some rough spots as your team figures out both its shared and unique needs.

The following sections include information I have found especially helpful in enabling de-Agile for distributed teams.

Optimize Team Size and Team Mix

Effective distributed Agile development is about minimizing the impact of distribution. Mainstream Agile processes work well for teams of 10 to 15 people, but what if your team is much larger? Paper-based, face-to-face strategies start to fall apart as the team size grows and the team distribution begins to span multiple time zones. You can still use Agile processes for larger, distributed teams. You just have to be willing to adjust your processes to accommodate the reality of your team’s environment.

Finding the right mix of talent at every location is critical when the team is distributed. If you centralize one type of work at one location, you can lose opportunities to benefit from local talent. For example, you might know of an excellent developer you can’t hire because your development team is in another country. Lost talent adds to your company’s total recruitment costs.

Distributing your processes and tasks as well as the development work is also key. In the centralized model just described, you also risk being stuck if your company needs to scale up -- or shut down -- a location. For example, having all your developers in one country, all your projects managers in another country, and all your testers in yet another country isn’t the way to optimize the functioning of distributed teams. This type of setup often leads to one-directional information flow and can result in chaos and the blame game if things go wrong. You also risk the continuity of particular functions if you need to close down one location, say, the one where all the product managers work. Factors such as domain complexity and technical complexity can also complicate recruiting and retaining the right set of people within a distributed team.

Distribute Work Evenly

Make sure all team members understand their role and have fairly equal workloads. In a distributed team, if the workload is uneven, you may risk the overall project delivery schedule if you ignore the imbalance. Uneven workloads can also cause bottlenecks. You should take complaints about workload seriously and be ready to balance the distribution of work carefully and quickly.

Equalizing workloads is difficult, but it is possible when you do a SWAT **(**Subjective Workload Assessment Technique) analysis with each member. Doing SWAT in a distributed environment is even more challenging because team members are geographically distributed and SWAT requires one-to-one discussions. In one of my previous roles, I worked with distributed development teams in the United States and Australia. I found that most of the developers in Australia were writing readable code, with appropriate comments and unit tests, whereas the developers from the United States were struggling. When I discussed the situation with each team member one on one, I discovered that the U.S. team was doing most of the work; the Australian team had been assigned only a small portion of work, which meant they had much more time to do their work than their U.S. counterparts.

Maintaining relatively even workloads across the team is also an important part of keeping the team rolling. If someone is burning out because of an unrealistically high workload, move some tasks to another developer if possible. If someone doesn’t have enough work, find ways to keep the person engaged with the project. People at both extremes of the workload range usually lose focus and eventually become disengaged.

Also make sure that the members of remote team are never treated like “helpers” for the team members in the “main” location. If remote team members feel like hired hands rather than full team members, they may have less commitment to the project.

Set Up Pair Programming

Pair programming, where two team members sit side by side and work on the same code, is a challenge for distributed teams. When pair programming simply isn’t possible, you need to adapt the “side-by-side” part of it so that you can replicate the experience virtually, for example, by using a video-conferencing solution such as Skype or LiveMeeting.

If this solution isn’t possible, you need to replace pair programming with an equivalent practice, such as a show-and-tell hour or a daily developer scrum. In a show-and-tell hour, every team member demonstrates (using screen sharing) his or her work to the entire team and receives feedback. In a daily developer scrum, developers meet briefly to collaborate on technical issues or approaches. This practice fosters code sharing and reusability, and it usually results in greater team bonding.

Enforce and Re-enforce Agile Practices

By definition, Agile approaches rely on a set of mutually supporting practices. When one practice doesn’t make sense for one team, the practice should be either abandoned or replaced. With distributed teams, enforcing and reinforcing a practice takes time and effort. Product owners and scrum masters who push a practice even when it’s clearly not working are seen as bullish or aggressive.

In a distributed environment, best practices around tool use play a vital role in enforcing Agile practices. For example, you can enforce code check-in comments by setting up a Team Foundation Server check-in policy, or you can use a centralized bug-tracking tool and mandate status updates before the daily scrum call to track the up-to-date status. For the first few weeks after you establish procedures like this, you’ll notice that everyone follows the practices. As you get closer to release, people tend to bypass them. As a scrum master, you need to reinforce the use of these practices to make sure the project stays on track and to make them automatic for developers.

Use Online Tools for Agile Artifacts

You can take advantage of Agile process artifacts (white boards, sticky notes, and so on) by moving them from their physical environment to an online tool. There are tons of tools out there. I have used Microsoft SharePoint, Microsoft Visual Studio Team System 2008/2010 and other online tools (even Google Docs and Live groups) to keep a team project on track. Visual Studio 2010 includes project templates for Agile and scrum you can use to organize your user stories, product backlog and so on. It also includes a number of predefined reports, such as burn-down charts and overall status reports. In SharePoint 2007/2010, you can use lists to manage your tasks or bugs. You can also use a document library to manage your project documents.

The obvious benefit with SharePoint is that sharing lists and documents with users, whether inside or outside your organization is easy. If you’re in a start-up environment, Google Docs and Live groups can help you tremendously. Google Docs can be used to share documents across teams or with external clients if you don’t have a SharePoint environment set up and you’re willing to put your project documents online. I have used Live groups for instant messaging within a team as a replacement for a daily scrum if not much is going on. The team members provide updates via text messages on Live Messenger, and we cancel the conference call for that day.

Understand Time Differences

Teams whose members work in various time zones face unique communication challenges. Even though regular scrums and overlapping work hours mitigate this problem to some extent, part of the work often gets delayed because clarification is needed or something requires reworking because one person’s changes affected the work of others in a different location or changes were not propagated correctly end to end. Regular reworking like this can impact team health; morale can suffer when people are repeatedly asked to redo work. Sometimes more disciplined developer-to-developer handshakes and end-of-day status notes to the entire team are required.

When I say developer-to-developer handshakes, I mean that development teams should communicate the code check-in status and code areas they have changed during their work hours that the other side should be aware of. They should share issues such as classes or methods changed, files changed and if the build was successful post check-in. They should also mention if there were conflicts in the code and whether they have shelved the code or checked it in. This way of working calls for more discipline since it has to be a regular activity, and developers tend to bypass this e-mail communication, assuming people already know what has changed. I have seen many teams, lose days trying to figure out what changes another team has made and jeopardize the delivery timelines.

In one organization I worked in, everyone exchanged end-of-day notes that contained the code check-in status, build status and any known issues that needed to be worked on or ignored when the developers in other locales started their day.

You can help your team work with those across the world by first making everyone aware of the time zones team members are working in. You can use anything from a physical map with pushpins showing how the team is distributed, to time zone utilities such as Microsoft Time Zone, to one of the tools in Microsoft Outlook 2010, such as Time Zone Data Updater. When you enable multiple calendars in Outlook 2010, you can see the time in other time zones. In Windows 7, you can use multiple clocks for the same purpose. In e-mail messages, you should note the time zone you are in or referring to, for example, by including something like, “Would it be convenient for you to discuss this tomorrow at 7:00 a.m. EST?”

Understand Cultural Differences

Culture plays a vital role in how we behave in a given situation. During the lifecycle of a large, distributed project, team members are exposed to many different situations. Being aware of cultural differences can help them understand the deeper meanings in some of their communications.

For example, people in different cultures have different ideas about authority. In Western countries, it’s okay to say “No” even if someone with higher authority asks you to deliver something. In many Indian and Asian cultures, however, the appropriate response in the same situation would be “Yes” because an authority figure asked the question, even though the person responding knows he or she won’t be able to deliver. In most Asian cultures, coming early or late to a meeting is not necessarily a bad thing, as it is in the United States or the United Kingdom.

In one distributed project I worked on, I interacted with both U.S. and U.K. counterparts. It took me a while to figure out that the members of the U.S. team were more direct and open in terms of communicating status and updates, and they expected the same from their counterparts. U.K. team members were more conservative and political in their dealings with their counterparts, expecting others to follow a more hierarchical communication. Keep in mind that these are my personal experiences -- yours may differ. Everyone is different regardless of culture, and stereotypes can be harmful. The key here is to be aware of potential differences. Many organizations offer culture awareness training to their staff. When working in distributed teams, such training is well worth the cost.

Adapt Communication for Remote Teams

Agile teams typically rely on intensive person-to-person communication, both within the team and with the customer. Remote team members miss out on these face-time encounters, and their understanding consequently suffers. When distributed team members are working through a communication channel in which they can’t see the person (or people) they are talking with, they need to be able to convey their agreements, disagreements and mood through their voice, tone, careful listening and general communication.

Effective remote communication when the parties aren’t visible to each other is difficult, requiring soft skills as well as technical acumen. Soft skills such as being able to communicate effectively and handle conflicts and negotiations are essential to distributed teams. Some people seem to be born with these skills, while others need to be trained and to have opportunities to hone their skills. Soft skills are becoming increasingly important as global teams are becoming the norm in many companies. Many organizations offer soft skills trainings to their staff or recommend online training.

You can enhance the audio communication abilities of your distributed teams by providing the tools they need, whether instant messaging, VOIP, wikis or mobile phones. You can also make tools that allow for virtual face-to-face communication available, such as videoconferencing with Microsoft Lync 2010 and Microsoft Lync Server 2010.

More Issues to Consider

Arrange Face-to-Face Interactions: Especially for larger projects, face-to-face interactions are sometimes necessary to bring together key team members, both to attain buy-in and to facilitate team building. Make sure your budget allows for travel, and let affected team members know about the travelling requirement.

Plan Frequent Demos and Retrospectives: Product demos with a retrospective at the end increase the visibility of your project, convey its status and provide instant feedback as well as opportunities for process adjustment. Involving your customers in these demos (at the appropriate times) fosters a shared understanding of the project’s business context and allows the business stakeholders to communicate with the development teams.

Provide the Right Tools and Training: Teams often use tools in a suboptimal way -- and distributed teams are no different. First, identify the tools that are a must. Get consensus from your team or consult forums such as Stackoverflow.com to find out which tools will be useful for your team on a particular project. Second, train your team on the tools. Don’t expect team members to know everything about a new tool without using it, especially if they learned about it from online resources. Allow them time to use the tool in a production environment to validate their learning.

Reorganize Teams Only as a Last Resort: Give all team members sufficient time to prove their skills and commitment to the project. In a distributed team, communicating and keeping track of everyone’s progress is more difficult. Frequent team changes exacerbate these issues. Constantly shuffling teams or reorganizing can in many cases lead to low confidence, low morale and low productivity.

Cultivate Commitment to Quality and Delivery: Not everyone understands the importance of quality and delivery. Make sure to educate your team members about the level of quality and the delivery requirements you expect for every project. Constantly look for ways to improve quality and to reward people who demonstrate an eye for quality and are willing to take ownership of and responsibility for a project end to end.

Conclusion

With organizations going global, distributed teams are becoming the norm. With additional efforts and some modifications, Agile, or de-Agile, can work well with distributed teams. It might even prove more successful than your current software development methodology.

I’m sure we’ll see more distributed Agile teams as we continue our journey through software development. Keep your eyes and ears open, and stay Agile!

Additional Resource

To find out more about distributed Agile, read the Dean Leffingwell book Scaling Software Agility: Best Practices for Large Enterprises.

Sandeep Joshi is a Senior Solution Architect and Microsoft Certified Trainer (MCT). Sandeep has over 12 years of experience in web and software design for business, financial and insurance services. Sandeep can be contacted via email at sandeep_mvp@hotmail.com.