Managing Distributed Agile Teams
Managing Distributed Agile Teams
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Business is increasingly becoming conducted by distributed teams. Whether offices are separated across countries, or people are taking advantage of changing business practices and working from home; without the right tools and techniques, distributed Agile teams can be less efficient and even downright unproductive.
Let's start with the 6th principle of the Agile Manifesto:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I still agree with this principle, but the world had moved on since 2001 and there are ways to improve distributed information sharing and reduce miscommunication. I also need to add that these approaches are valid across multiple industries and business functions, including non-software Agile teams.
Introduction to Distributed Teams
In a distributed Agile project, team members may not often see each other face to face, but must work collaboratively toward a single outcome. The reasons for distributing your Agile team will be different for each organisation. They might include the availability of resources in different locations, closeness to certain clusters, proximity to customers or cost advantages. I should note that this is different from outsourcing as all teams members work within the organisational structure, instead of one organisation subcontracting the work to another.
Communication is the key to any successful project, but is especially important for distributed teams. It is important to setup and enforce a communications procedure early in the development cycle. Meetings, such as the Daily Stand-up, should continue to be run (at a time common to all parties), helping to maintain cohesion between developers.
- Early in each project, you should invest in face-to-face meetings to build the initial sense of "team" that will continue throughout the project. This will also help to put faces to names for future non-video communication.
- Use a variety of technologies to encourage communication (see below).
- When possible, record and retain communication that leads to a decision. Written communication (email or chat) is generally better at this than voice or video. A simple method for this is to record all decisions within the product backlog (a list of all requested feature or activities for a product).
- Invest in good video conferencing hardware for each major development centre. Ensure that all individual team members have basic video conferencing functionality available on their local computer, laptop or tablet.
- When business hours across multiple time zones do not align, daily stand-up meetings should be communicated electronically.
Some examples of communication technologies include:
Mailing Lists / Wikis / Intranets / Social Network
Mailing lists, wikis, and intranets allow team members to communicate publicly with an entire group. Each project should have multiple lists or pages such as:
- Feature mailing list: this should contain all team members, managers and appropriate stakeholders. This should only be used occasionally and only to discuss the direction of the project.
- Team member mailing list: this should contain only the team members and team leaders. Use this list to discuss technical issues and help each other.
- Off-topic list: this should contain team members and team leaders. Use this list to send out helpful, interesting and non-work related information. Also use this to retain a community and friendly atmosphere at work. This could also be included within a social network.
The public nature of this approach means that new team members will be able to become familiar with previous issues before turning to their colleagues.
Instant Messaging / Social Networking
Video and voice communication can be interruptive if unplanned during work. Instant messaging (IM) can solve this by setting availability, so that discussion can occur only when both parties are prepared.
- Each team member should have all other team members on their network.
- Team members should specify their status on the network so that others know when they are available.
- IM allows files to be transferred between each team members quickly and easily.
- IM communications can be logged and saved for later reference.
Finally as an alternative to face-to-face meetings, video conferences can be very effective for communication. If you have central facilities geographically located, dedicated video conferencing equipment should be acquired. This can be permanently set up in meeting rooms and send images at high quality between locations. Otherwise, individual team members should be given basic web-cameras and video conference software for their PC or other device.
- PowerPoint or technical presentations can be displayed at the same time as the video display. This is very useful for in-house training or software demonstrations.
- This option does have a high bandwidth cost, but is an effective replacement for face-to-face meetings.
- Equipment can range in cost and the type of equipment should depend on the project and team members.
- If there are more than two parties, the organisation will require a MCU or bridge to link everyone’s audio together. Phone bridges can often join the low quality web cameras with the dedicated systems, as well as voice only connections such as VOIP or telephone.
Hiring appropriate staff
Put a strong emphasis on self-motivated people when selecting or recruiting staff for a distributed team. Team members that are unable to cope with minimal management, will bring down the output and quality of the rest of the team. If you must use less independent team members, bring them in-house and only use your best team members for remote development.
As an Agile manager you need to ensure that everyone feels a level of responsibility for the achievement of the overall project goal, where noone can succeed without everyone else being successful. This will foster a sense of teamwork and staff loyalty. To this end, specifically design your organisational structure to support distributed development, and include appropriate incentive systems.
Distributed teams need a different style of workload management than a traditional development project. It is very important for an Agile team that there is a greater emphasis on communication, modular development, and macro-management.
- Break down the development into well-defined modular components.
- Use small independent teams for each module.
- Put each required feature into an issue tracking system (in as fine granularity as possible), and use this system to track progress.
- Each team member should be given adequate resources to perform their job.
- Documentation is everything, but only write the minimum viable documentation; enough to communicate a message. Documentation should be simple to understand and convey a message clearly.
- A workload management system should be maintained to regulate the list of requests, issues, tasks, and defects. A workload management system often also contains a knowledge base containing information regarding each issue and how it was resolved. This can help in the development or resolution of similar products or defects.
Each team must report progress on a regular basis. Without ongoing feedback an Agile manager cannot successfully assess the progress of the project. Some reporting can be automated through unit testing of committed software and the closure of tasks in the project management / issue tracking system.
The Daily Stand-up, if used correctly and involving appropriate stakeholders, can replace the need for most other status reporting.
The last technology I want to discuss that assists in the management of distributed teams is version control.
Version Control or Revision Control is the management of multiple revisions of the same product. Versions of electronic products, such as software or documents, can be stored within the version control system; each version includes appropriate metadata such as who made the changes and when. Versions of physical products are recorded separately. The version control system should be available to all team members. The benefit of version control, especially for non-software teams, cannot be underestimated. Some benefits are:
- Allows for multiple versions of the same product to be deployed in different sites.
- Allows for the team members to be working simultaneously on the same product without overwriting one another.
- Also allows for development of two versions of the product concurrently.
- Centralised storage of all electronic products.
- Increased ease for multiple team members to stay synchronised.
Opinions expressed by DZone contributors are their own.