Distributed vs colocated agile teams: Pros and cons
Colocation is useful. Colocation is handy. But is colocation necessary when it comes to agile teams? No. Not only is it possible to effectively manage distributed agile teams but there are many benefits.
Is colocation necessary for strong, productive agile teams?
Colocation is overrated and represents a knee-jerk reaction to fixing the communication and comprehension problems that can occur when working with agile team members in different parts of the world. The business reality is that having all employees in a single location is next to impossible to build or maintain. The system builds inflexibility, and the next thing you know, certain people are allowed to work from home while others are required to come in daily.
For example, it may be critical to keep one software engineer happy. So, that engineer works the schedule they want. Another potential problem is that in a tight market, a business may end up keeping people who aren't doing their jobs just because they're "good enough." Both scenarios are for the sake of maintaining a colocated team, even when half of them work from home. This creates an unfair environment that leads to employee dissatisfaction.
In the same way, being inflexible reduces the hiring pool. I know from experience that it's possible to work with a different office or with remote employees easily, whether or not we ever meet. I can also tell you that software engineers prefer using instant messaging tools or email to actual conversation the majority of the time. Most development staff need time and space to concentrate, and many don't care to be interrupted directly because it disrupts their ability to create and produce. It doesn't matter what field you're working in—being constantly interrupted is both annoying and counterproductive.
Colocation is useful for meetings that require close listening, such as design discussions. Whiteboarding designs is highly effective in person but can be managed with online tools as well. Colocation is handy when new employees are training and need some amount of hand-holding or encouragement. Otherwise, if the development staff is knowledgeable, experienced, and mature, it's simply not necessary for success. Communication styles differ, and they can be managed effectively by learning to communicate in various ways. Employees can connect from anywhere there is a secure Internet connection, so the potential talent pool is far deeper than when employment is restricted to a particular location.
Learn to communicate
Communication variability is essential. If you're going to have employees based in different offices or areas, you must invest in communication equipment that fits the job, including software for laptops and communication networks. Don't rely on freeware resources until you test them out first. Consider using them as backup options, should the specified tool fail. For example, if you purchase GoToMeeting for teleconferencing communication and it has a problem, keep Skype handy and use it instead. Perhaps, instead of email opt for using a tool like Slack. What's important is to have a licensed, organized system that employees know how to use. Consistent tool use helps reduce confusion on which tool to use, where, and how.
Also, keep security implications in mind when selecting a tool because employees will likely be discussing or displaying proprietary information. It's essential that the selected tool contains sufficient security, and that the security used is properly configured.
Provide phones and headphones that work with the network system and can be heard as clearly as possible. Plan on equipping conference rooms in the main offices with communication equipment like SMART boards and monitors. Additionally, the business needs to have a strong, reliable Internet provider.
Build in flexibility and increase coverage
Two advantages of distributed development teams are flexibility and coverage. For example, if a business exists in the Pacific time zone, and a second and third office exist in the Central time zone and in Australia, then the company can have resources working and available around the clock. Say the testing team has a dozen more tests to complete in the San Francisco office. Those testers can push the unfinished tests to testers in the Central time zone office. They'll be in the office three additional hours, and then if necessary, those tests can be completed when the workday starts in the Australian office.
Development stories managed using a Kanban or agile scrum board can be worked across time zones. If an engineer A doesn't finish, then engineer B can take a story and complete it because their workday isn't yet over. Work tasks can flow, and if they can't flow across engineers, there's still progress being made more frequently. If sharing story work is too awkward, then stories can be assigned in such a way that more stories can be worked on simultaneously.
Distributed teams are independent workers by nature. Your employees may be available to work overnight or on a more varied schedule. Employees may be able to switch or take on tasks that work best for their area and talents.
Increase hiring potential and appeal
High-quality, experienced software engineers are difficult to find and retain, so limiting the talent pool to one geographic area is exceptionally restrictive. Distributed engineers can work from anywhere there's a secured Internet connection, so the business can hire developers from around the globe or across the US, avoiding the need to handle employee moves or to pay higher prices in certain areas. The ability to manage and hire distributed teams is a much desired skill. The wave of the future is flexible working conditions—distributed teams that work across boundaries.