Best Practices for Remotely Managing Agile Teams

For those tasked with managing agile software development teams remotely, new challenges arise that are not addressed from standard agile practices derived from the “Agile Manifesto.” One of the 12 principles from the manifesto is that, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This has resulted in the understanding that co-located teams are the ideal for development work in general, and agile in particular.As agile practices are now considered mainstream by many, the need for utilizing remote workers on teams has increased in practice. This can result in difficulties when implementing some of the agile principles, depending on the team configuration. What follows are experience-based prescriptions for high bandwidth communication to help keep remote agile teams at peak performance.[login]

The Issues Remote Teams Face

It is generally agreed that co-located teams using team rooms offer the best opportunity for high performance teams. Why are collocated team rooms preferred for agile teams? Studies have found that the best face to face experience for software development teams is to use a team room, according to this ScienceDaily article. Unfortunately, this ideal is not always possible for many teams. Remote team members are a fact of life for many teams. These remote members may include off shore teams, contractors in different locations, work from home employees, or different company locations. All of these scenarios are legitimate and require planning to make the agile project successful. Besides no team room, remote teams also face the issue of big visible boards. If for instance the scrum master, or agile project manager is not on site, who would maintain those boards? To maintain multiple boards with the same information, we will be duplicating effort in two or more locations. So how do we create wide communication paths to all team members?

Figure 1: An example of a configuration of two offices.Organizational issues can also impede teams with remote members. For instance, organizational issues that have to do with reporting structure can pose problems. Perhaps the project manager is running the project, but a software development manager on site has a different idea of what agile means. If the PM is remote, but the software development manager is on site, this can introduce problems that would seem easy to fix if they were collocated. If the remote team is part of the company, there may be an issue of imparting company culture. Experiences that many teams already have under their belt, understanding of corporate goals, these can all impact how a team performs in the company.Many of these issues relate to communication. And that is the essential component to using agile tactics with remote teams. The really essential concept is how does our team create wide communication channels with remote team members?

Start with the Meetings

To create high communications bandwidth, agile practices use a wide variety of different meetings. Daily stand-ups ensure that the team is in contact every day. Planning meetings assure that stakeholders have a voice in team meetings. Estimation meetings give development team members a voice in the actual product. And retrospectives give all team members a voice in improving the process. Make the meetings as accessible to your remote team members to help ensure that the verbal, visual communication is understood.

Initial Release Planning

First, it is essential for the entire team to meet face to face at the beginning of a project. This initial face to face is the best way to ensure that future remote communication is healthy and vibrant. Face to face meetings help the team to establish relationships that carry on for the duration of the project. This in turn helps the entire team to frame responses from individuals, based on how the react in real time. And misinterpretations of what is meant in emails, or IM’s can be reduced. Much research exists to back up the use of face to face meetings.Your initial face to face release planning meeting should include different events to get started. Include Visioning events, as well as standard events like estimation and sprint planning. Some agile coaching may be in order, depending on the maturity of the team. With a team that does not have a solid agile background, consider beginning the face to face using the Lego game or some other type of agile game to build understanding and teamwork. Here is an example of an agenda for an initial one week face to face meetings with the entire team:

Throughout this plan, there is assumed that there will be interaction in non business settings. This can be set up by the PM, assuming there are funds in the project to do it. Or, there should be some time where the group gets together spontaneously for lunch or after work. Again, these should be encouraged.This face to face meeting now has the team together, and there should be some good experiences shared. But once the planning is over, it is time to head back and begin the bulk of the project, using remote communication. If there are funds in the project, plan at least one more face to face toward the middle of the meeting to do a retrospective and sprint planning together. Assuming programmers are not all in one location, mix programming pairs, assuming that is one of the techniques used. If that is not possible, there are still ways to improve communication, it will never be as high bandwidth as face to face though.

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.

Retrospectives

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.

Figure 2: 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.

devx-admin

Share the Post: