During the Sprint
Now your standard communication plan should be in place. The pain points are in the lack of quickly communicating issues, and quick understanding that can come from showing issues immediately to stakeholders or other programmers. Any tools used should eliminate as much of this pain as possible.
Since most companies have internal instant messaging (IM) in place, this may be one of the best and worst ways for teams to keep in touch. The reason IM is one of the best is the immediacy you get from being able to see presence (for many IM clients) of people to contact, and comparatively quick response.
Keep in mind the cultural issues with IM. Usually technical people are ok with using this. However sometimes the stakeholders are not fond of IM, or it is not a tool they are used to using. If this is the case for some of the team members, then find a different method of communication. Our communication plan may say that for quick communication, use instant messaging. If the stakeholder does not respond quickly, then use email or phone. Be flexible with your remote communications.
The bad side of using IM is that it breaks the flow of work when there is a complicated IM. While we try to keep context switching at a minimum on agile teams, using IM, is one quick way to make someone switch context. If a developer in Indianapolis has just started a new story, and the QA person in San Diego has a "quick" question for that developer on their last story, the developer will be doing context switching. A good rule of thumb for not having this issue is to have a rule where the IM'er asks the one they are IMing if this is a good time. If not, then get a good time to talk, in the next hour, so there is not a lot of wasted time on both ends.
Another useful tool for those remote communications involves video feeds. Web cams can be used for the team to constantly see one or two remote members. If most of the team is in a team room, feed the video to a screen where all can see the one or two remote members, with audio on. At any time team members can view what the remote members are doing and try to communicate with them if needed.
During daily stand-up meetings use some type of web software to display the team to the remote team members, and vice versa. Tools like Windows Live meeting have 360 degree views that allow all of the team to be seen by all. This helps reinforce the relationships made in earlier face to face meetings.
In the stand-ups, a video feed also helps the team make sure the other team is standing up. For new teams there is a tendency to think that the actual standing up part of daily stand-ups is not necessary. Experience has shown that this is necessary, so using video during the daily stand-up and reminders from the PM can help keep remote teams in synch.
Using tools such as web cams and IM can help in all meetings. The retrospective should be attended by all, and held with video if at all possible. Sharing desktop tools like WebEx or Live meeting are helpful as well. Begin your retrospective as you might normally do with a collocated team. Make sure that all team members participate by asking questions about what went well and what didn't go well.
Make sure to show the retrospective result on a wiki or SharePoint website, or other collaborative tool. Communicate results to everyone consistently, and have follow-up on any action items. Consistent follow ups are critical for remote teams, to help build trust.
The Right Kind of Chart
Most agile teams have a board somewhere in their team room that shows the current status of the sprint or release. For instance, if the team is using Kanban to run the project, a board showing the different queues is in a highly visible area that the team can see. This allows stakeholders, as well as others in the company to see what is going on. This high degree of transparency on a project is desirable, but can it be duplicated for the remote team?
Unfortunately, the high bandwidth of the big visible chart cannot be duplicated for everyone on the team when some are working remotely. Assuming there is a team room, the big chart should be visible electronically for the remote members who cannot see everything in the team room. This may involve a dedicated agile software tool, or just updating Excel spreadsheets.
Craft the reports in a way that they make sense for the remote person, as the physical board makes sense in the team room. So for a Kanban board, have a report that shows queues, and totals in that queue. Make sure that WIP limits are displayed also. For a Scrum sprint, show the total stories in the sprint, and the status of each story. The report may not look exactly like the board, which is OK. Cumulative Flow Diagrams can be excellent tools here.
Example of a Cumulative Flow Diagram.
The updates need to be made to reports on a regular basis, such as daily (recommended). The remote participants need to see updates happening consistently so they can rely on the information there. If those updates are missed, the team lifeblood of oxygen (information) starts being restricted for some. So the burndown charts, velocity reports, and other tools used to report information must be visible to remote participants. And reminders of the updates should be sent via email or IM.
Every time reports are updated, send emails out alerting the team the update has occurred. In the email, update the team with analysis of the numbers, so there is understanding of what is currently understood. Daily standups can be used to help clear up any misunderstanding of these.
Another option is to take pictures of the big chart in the team room to make it available for the remote participant. When using this technique, the admonition is to make sure that updates happen frequently, so the remote participant is as up to date as possible with this.
Remote Communication Constraints
Unfortunately, whenever there are remote team members, the communication bandwidth will be lower than being face to face. Using electronic reports does not ensure that the remote participant is viewing the report. Use meetings to help reinforce the need to view these reports.
Instant Messaging does not give the same communication effect as turning around in the team room and seeing if that person is available. But it can be used effectively to get better communication for the team.
For all these remote methods, it is not the ideal circumstances. But a good project manager can help mitigate the risks imposed on a project with remote workers by using these tools effectively.