For most of the last five years, I have had the pleasure and privilege of working as a software tester on two different...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
highly successful agile teams whose members all work remotely. The team members are distributed around the US, and in a couple of cases, around the world. There are a number of advantages to such an arrangement. For one thing, it is possible to hire the most talented and skilled people available, since geography is not a factor in the decision of whom to hire. Distributed teams do not have to settle for whomever is available locally. For another thing, everyone is comfortable all the time, and this is important to our happiness.
But there are critical differences between a remote agile team and a co-located agile team that must be addressed if the team is to succeed. These differences fall into two main categories: communication and workflow. A remote team necessarily has much reduced communication bandwidth compared to a co-located team, and thus must communicate among themselves with great efficiency. And having a well-designed workflow is critical. A co-located team can change their development process in an instant. Doing that on a remote team is much more difficult. Using the appropriate ALM tools for a fully distributed team is critical for success.
I think we will see more and more of the most talented people in the industry shift to this way of working as the cost of being co-located increases.
The most important difference in communication between remote agile teams and co-located agile teams is that most of the communication on a remote team is written and not verbal. It is critical that everyone on a remote team has excellent writing skills and be able to express themselves clearly and unambiguously in writing. For a co-located team, that which is unclear can be worked out right in the room. For a distributed team, that activity becomes very expensive.
Given good writing skills, a distributed team needs many communication channels. And these channels need to be as public as possible, so that everyone is aware of what the other team members are doing at every moment. Here are some examples of the most important communication channels for remote teams, arranged in their preferred order of use from most public to least public:
A dedicated multi-channel real-time chat application that provides information on presence is critical. Internet Relay Chat (IRC) is a mature and inexpensive way to achieve this. Any number of IRC servers are available for free, as are applications (generally called "bots" or "chatbots") to improve the experience of IRC users. IRC is where remote team members "sign in" for work. It is where we work out our day-to-day issues, report ongoing status, ask questions. Everyone can see the channels they want to see. For instance, there might be channels named "#dev", "#qa", and "#ops." Where I work today, we have a channel called "#party" that is just for socializing. I join and leave #party depending on how much concentration my current work requires.
The wiki is where the team keeps all of its institutional and historical knowledge. It is the single point of reference for documentation on the system itself and on the team's process. An intraweb with documents is not an acceptable substitute for a full-featured wiki, nor is a document-management system like Sharepoint.
A voice over IP system is important for daily standups and for conversations that are too complex for IRC. For small teams, Skype may be adequate. My team is using GoToMeeting right now, which also provides the ability for "presenters" to share their desktop. This is where we review our burndown charts, for instance.
Instant messaging is important for one-to-one chats. The actual client is immaterial. I tend to use GTalk because it is convenient, but IRC also provides this ability.
Email is not the place for documentation, nor is it the place to hold a conversation. Email is for broadband announcements, overall status updates on systems, questions for the whole company, and other bits of general information. Conversations on the work itself should take place in other channels.
On a co-located agile team, stories, tasks, obstacles, bugs, problems, etc. are generally tracked as physical index cards on a board. Obviously, this is not possible for a remote team. Remote teams need tools to do this, and those tools must be very flexible.
One of the hallmarks of a successful agile team is that the team is constantly adjusting their own software development process. Any workflow tool a remote agile team uses must be able to accommodate those constant adjustments. I have used two such tools with good success.
On one team we used a commercial wiki to track stories and tasks. This wiki was very well designed and provided an enormous number of API calls that allowed us to tweak the behavior of the system at a moment's notice. Each large story and task was described on a wiki page containing links to smaller stories on other wiki pages. We managed the status of each story and task by tagging each wiki page in particular ways. Using the tags, we could extract overall status information for burndown charts and other such reporting.
On that team we had a separate defect tracking system, but that system also had a highly hackable API, and our wiki and our defect tracking system talked to each other in a way that made managing defects a seamless experience.
On my current team we manage everything in a highly-customized system of ALM tools that integrate tightly. Stories, tasks, obstacles, problems, defects, status, everything has equal status and is managed in the same common dashboard available to everyone on the team.
This is a critical point: every bit of information the team has is always available to everyone on the team. To put this information in silos and say for example "this information is only available to developers" or "this information is only available to QA" is a recipe for failure. If people on the team lack information about the overall work of the whole team, those people will make bad decisions about their own work and the work of others.
The future of remote agile development
I think we will see more remote agile teams in the near future. Working this way can be rewarding, efficient, and even environmentally responsible. I think we will see more and more of the most talented people in the industry shift to this way of working as the cost of being co-located increases.
But I do perceive a higher risk of failure for remote teams. For one thing, only very skilled and talented people can negotiate the reduced bandwidth and succeed at such work. For another thing, excellent communication and a well-considered, manageable agile workflow is critical. This article is for those teams.