RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Best Practices for Remotely Managing Agile Teams

A project manager can help mitigate the risks inherent in a project with remote workers by using tools effectively.

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.


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:
    Monday - 9:00 - 11:00 Agile Game
    Monday - 11:15 - 12:00 Overview of Poject Vision
    Monday - 1:00 - 2:00 Create remote communication plan
    Monday - 2:15 - 4:00 Create User Stories
    Monday - 5:00 - ? Teambuilding Agile discussion at Pub/Rest.
    Tuesday - 9:00 - 12:00 More Create User Stories
    Tuesday - 1:00 - 3:00 Intro to estimation standards.
    Tuesday 3:15 - 5:15 Initial estimation meeting
    Wednesday - 9:00 - 11:00 Break do "real work"
    Wednesday 11:15 - 3:00 Estimation meeting (Include lunch).
    Wednesday 3:15 - 5:15 More estimation
    Thursday 9:00 - 12:00 Initial Release Planning meeting
    Thursday 1:00 - 5:00 Dev team breaks stories into tasks (with estimation of time if that is part of your planning)
    Friday 9:00 - 12:00 Begin Development in team room.
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.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date