Channels ▼


Effectively Managing Distributed Agile Teams

Facilitating Communication

Another significant question is "How does the team communicate in a distributed environment?" Communication starts with the manager or ScrumMaster setting forth the vision of the company, team and project. If you don't know why you're doing something, it is hard to do it right. Also, don't assume just because you are deeply aware of the vision that everyone else is, particularly the offshore team. Sometime the offshore team feels left out of the loop, so bringing them into the fold is critical to a successful project.

Agile greatly relies upon the close proximity of the team and the Product Owner, where communicating is as simple as turning around and asking if your teammate has a minute. In a distributed environment it is difficult to overcome the delay in communication; email responses are often delayed and misunderstandings may require immediate rectification. One can potentially lose a whole day due to a misunderstanding and that is not the Agile way. In a distributed environment you must diligently establish the lines of communication. Furthermore, it is important to set guidelines on how and when to use them ; see Figure 3. For example, email might be appropriate for a non-time sensitive question on a front-end interface; however, updates to your estimated remaining hours in an Iteration might be best put in a SharePoint site or Xplanner. A time-sensitive or a confusing issue might be best discussed immediately following the Stand-Up. By establishing lines of communication with specific guidelines, you are reducing the occurrence of the classic excuse, "I was waiting for a response back."

Figure 3: Lines of Communication

As suggested above, a great time to have further joint discussions is immediately following the Stand-Up. Since we are dealing with time zone differences, allot at most 30-45 minutes following the bi-weekly Stand-Up to have a general team discussion. This is a time when the team can hear each other's voice, experience each other's persona and quickly resolve open issues. I have seen some of the most significant conversations arise from these post Stand-Ups discussions. Remember that this is not the ScrumMaster's time, but rather the developer's time. The ScrumMaster should stay silent unless a critical point needs to be addressed.

Staying on the same page is especially challenging with a distributed team. A great way to overcome this issue is to have peer code inspections and formal reviews involving the entire team. Before checking in any code, the developer should have another team member inspect their work (encourage cross-site inspections). Also, group code review should occur every other Iteration where someone is chosen to present (i.e., brown-bag lunch/dinner) the goal, solution and delivery. These inspections and reviews are wonderful quality controls, learning exercises and in the case of the brown-bag lunches, presentation practice.

Critical to staying on the same page is getting to know one another. As in any relationship, the personal side is where bonds and kinship form. Create a cohesive team (not a vapor team) by spending the time to learn about each other's interest and culture. As Martin Fowler points out, face-to-face meetings are the best vehicle for communication where gossip and information tidbits can be related; have the team work co-located for a short while or send periodic Ambassadors to the each other's site (Fowler, 2006). Video conferencing during demos is an incredible way to put the name to the face.

Again, another major obstacle to communication is the time zone difference. If possible within your organization, attempt to select an offshore team that has more overlapping hours with the onshore team such as Latin America or Eastern Europe for a U.S. based onshore team. Working with an offshore team in a time zone with more overlapping hours can make a world of difference to improving the communication gap and output velocity. Also, be sure to select an offshore team that is reasonably fluent in the same language as the onshore team, thus keeping language miscommunication to a minimum (Krym, 2009).

Finally, a word on the role of documentation in communication. In the traditional Waterfall/SDLC methodology documentation is a primary deliverable. Agile, of course, differs greatly on the role of documentation. A principle of the Agile Manifesto is delivering working software over comprehensive documentation; reduce complexity to focus on value. However, in a distributed Agile environment, we actually reduce complexity by strategically increasing the amount of required documentation, to a degree. By creating appropriate documentation, the team can better communicate designs, work-flows, issues, etc. A new design the onshore team came up with might most easily be communicated to the offshore team via a sequence, component or class diagram (stored on SharePoint or a shared drive). A word of caution is to not treat the documentation as Waterfall documentation that needs continuous updates. Agile documentation should be created and updated as long as it is directly useful; once the usefulness is outlived, abandon the document (Fowler, 2006).

Keeping the Team Productive

A happy team is a productive team. The essence of creating a happy and productive team is to treat every member equally, respectfully and professionally. Building on Conway's Law, if you treat the onshore and offshore members differently (i.e., expect less from the offshore team) you'll have those expectations met. Expect top quality from people and they usually will attempt to meet those expectations (Carnegie, 1937). Begin by removing preconceptions on what can be done onshore versus offshore, motivating the individual members (and by extension the whole team) by giving them autonomy, and removing roadblocks and bottlenecks that prevent the team from reaching their goals.

Preconceptions: Remove the preconception that offshore can't do the complex coding. Teams self-organize around goals. If the goals have been properly communicated, the team will efficiently break down the responsibilities and tasks. Furthermore, remove the preconception that the offshore resources are fungible. The team as a cohesive unit is an asset and should be treated as such. Treating offshore team members as fungible and replacing them frequently means you are in continual team rebuild mode; a stagnation on the velocity.

Motivation: "Autonomy is a great motivator, allowing people to be both more productive and able to grow into greater responsibility." (Fowler, 2006) People want to feel that they are a part of something and at the same time have the freedom to make their own decisions. Start by treating everyone equally, respecting differing opinions and promoting an autonomous work environment. Also, create career growth and learning opportunities for all the team members (e.g., rotate the presenter of the Demos to provide learning opportunities).

Roadblocks and Bottlenecks: Retrospectives are extremely important for improving the velocity by vetting out productivity and communication issues. It is an opportunity for the team to air what has been done right and what can be done better. If an offshore team member makes a comment about a difficulty they face (i.e., network connectivity issues or feeling that onshore is making decisions without them), treat the issue seriously and follow-up. If necessary, perform root cause analysis to uncover the underlying problem.

As cautioned above, but certainly worth repeating, prevent team burn-out. A distributed Agile team can easily fall into the trap of working longer or odd hours. Short jolts of sacrifice can actually create team solidarity, but it is a slippery slope that can be destructive to the team. Remember, it is the ScrumMaster's responsibility to maintain a healthily productive team.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.