Distributed Agile teams are here to stay – like it or not. According to CollabNet/VersionOne’s 12th State of Agile survey, 79% of respondents had at least some distributed teams practicing Agile. I myself was taught early on that Agile teams had to be co-located and should sit in the same area in order to facilitate high-bandwidth osmotic communication. And while that is still a very effective way of working, in today’s workplace we see more and more distributed Agile teams.
For the sake of this post, I will focus on team members distributed geographically across the country or globe, less on people in adjacent buildings or on different floors. I will cover:
- Why distributed teams are becoming more and more popular
- Challenges of distributed teams
- 11 tips to make them more successful
So let’s dive in!
Why Distributed Teams
So why would one disrupt the ideal collocated team and have the members spread out geographically? There are many potential reasons:
- The area where the company is located does not have a sufficient pool of available employees with the requisite skills.
- A company’s facilities are too small and expansion is not a viable option.
- Distributed teams are cheaper: Salaries or hourly rates are significantly lower outside the US or even other areas of the country and the company doesn’t need to supply facilities space for remote employees.
- The workspace within an office is too noisy or distracting and team members feel they’re more productive when working from home.
- Commuting is becoming more and more challenging and takes time and mental capacity away from team members. In certain areas a stressful daily commute of 1+ hr each way is not uncommon leaving people already exhausted by the time they reach the office.
- Some organizations think “working around the clock” is desirable and has advantages, e.g. dealing with support issues more quickly.
Not surprisingly, there are also number of challenges with distributed teams:
- Time zone differences may result in reduced or (worst case) only minimal overlap between working hours of members of the same team. This greatly hinders communication and collaboration.
- Talking about collaboration: Things like spontaneous conversations, working and white-boarding sessions become difficult.
- Daily stand-up meetings tend to turn into “catch-up meetings” since they’re one of the few times all team members are present and online, so there’s lots to talk about.
- Physical information radiators are not feasible.
- If developers and testers are in significantly different time zones, the natural back and forth is severely hampered and what could be short iterations taking just hours could turn into 24 hr cycle times as people are trading bugs and fixes back and forth.
- Due to the inherent overhead and friction, distributed teams tend to exhibit lower productivity compared to colocated teams of the same size.
Tips to Help Distributed Teams Succeed
Despite the disadvantages, the new economy with virtual workers (#digitalnomads) and its enabling technologies and omnipresent Internet connectivity demands that we learn how to make distributed teams successful.
Here are 11 things that I found make them work better:
1. Don’t get too aggressive with time zones
Try to stick with a maximum time difference of 3 hours. Less is more! The team members will greatly benefit from more collaboration and communication opportunities.
2. Everyone on the team needs good and stable Internet bandwidth
This should go without saying, but issues are unfortunately not uncommon. Without good connectivity, team members will simply not be able to communicate or even code and test effectively. You need to be able to stream at least voice reliably — if not video as well.
3. Insist on good English language skills
People need to be able to speak with each other effectively. Since non-voice communication and other tools require writing, clear written English is equally important.
4. Invest in tools
Given that all intra-team communication has to happen via tools, make sure you have good voice and video conferencing, chat, white boarding, wiki, and ALM tools available. Examples: Zoom, GoToMeeting, Slack, Confluence, VersionOne, CA Agile Central, Jira, Trello, RealtimeBoard, etc. Note that phones these days are less necessary than you’d think. For many of these, the free versions will not suffice, so be ready to pay for premium versions.
Try to either be a remote or a colocated team. You can’t really be both. If you have half the team sitting together and the other half spread across the globe, it’s hard to be successful. Worst case ,the team fractures or the “remotees” feel disconnected and out of the loop.
6. Consider a “local” Product Owner
That said, it might be beneficial to have the PO “live” in the office or at the company HQ. The PO job will likely require frequent interface with employees outside the team as well as stakeholders. Being in the office in person may therefore be advantageous.
7. Don’t skimp on the Scrum Master
Yeah, you do need a SM to help coach the team, coordinate things and find optimal ways of working together. One might even argue that being SM for a distributed team requires even more skills and experience than for a colocated team.
8. Create working agreements for the team
The SM can help by having the team come up with their working agreements to answer questions such as: What are you agreed-upon working hours? What are our commitments around being responsive and accountable to one another and the team? How do we deal with (international) holidays?
9. Focus on on-boarding
With a distributed team, you have to be very deliberate about how to hire and later onboard and train new members. How do you make sure people get up to speed and have a chance to soak in and absorb company culture and knowledge? Consider a buddy system.
10. You need to actually spend time together in the same place, yes really
It is highly recommended to give distributed teams the chance to actually form and bond by working together physically in the same place for at least a week or two. Let’s call this “seeding the team”. I know this can be expensive, but it’s invaluable when it comes to letting team members gel, bond and form relationships. This investment will pay dividends later. You’ll want to repeat the “together time” at least once or twice a year. (Even when everyone is back home again afterwards, make time to connect informally and nurture those relationships.)
11. Be religious about continuous improvement
Given the inherent challenges with a distributed team, it is critical to be diligent about retrospectives and continuous improvement, not just with regard to regular Agile and team “stuff”, but to figure out what works for everyone to bridge the geographical and time zone gaps.
Let’s be honest: A distributed team may never fully reach the level of performance of a high-performing, mature, colocated team, but they may get reasonably close. Following my recommendations will hopefully allow you to see tangible improvements in making your distributed teams successful. Like with everything else, this is a journey, so don’t forget to try things, inspect and adapt.
(For additional insights into the topic of distributed teams, please check out Mark Kilby’s insightful presentation from the Agile 2018 conference.)
What is your experience? What have you seen work well in practice?
Related to the topic of distributed Agile teams, here’s how a recent experiment resulted in significantly improved team performance: Virtual Co-Location.
Covid-19 has forced us to make changes in all areas of life and many companies now find themselves having to build and sustain a remote culture. It will be interesting to see in how far – when the virus finally subsides – these changes will be permanent. My suspicion is that we will never fully return to what used to be the old normal as many companies have already announced that they don’t expect their workers to return to the office.
Very useful article. Thank you. When I click on the link to the presentation at the bottom of the article I get a page of xml!
Hmmm, looks like the link expired. Please try this: https://www.agilealliance.org/resources/sessions/agile-distributed-teams-oxymoron-or-option/