In my previous article, I argued that using a distributed team with the Scrum Framework was a bad idea and advised against it. There is sufficient information to show that distributed Scrum teams perform poorly compared to those that are co-located.
However, everyone does it anyway! As Jeff Patton once said, “if you want to run a marathon with ankle weights, don’t complain to me about your time!”
Given that so many organizations have distributed teams, the focus of this article is to provide a set of recommendations on how to do this to minimize the impact.
I’ve seen a lot of patterns of Scrum with distributed teams and I believe there are some approaches that minimize the impact of distribution and maximize team performance.
4 Patterns for Success with Distributed Teams Using the Scrum Framework
If you cannot have a scrum software development team that is completely co-located, consider the following approaches:
#1 – All Remote High Performing Team Members
Martin Fowler describes this pattern for Agile teams in his 2015 article on remote vs. co-located team members. The approach is to get great performers who happen to be in different locations, hopefully with minimal time separation.
I have used this pattern with a few teams transitioning to Scrum and using the scrum framework. Anecdotally, I have heard other stories where this has worked with large companies like Motorola and IBM.
This approach works best when all team members are part of the same organization, rather than a mix of subcontractors and employees. It is also dependent on good collaboration tools and team member training. It is helpful if there can be occasional in-person meetings – I’d recommend at least monthly or quarterly.
#2 – All the Developers are Co-Located, the Product Owner is Remote
This pattern has also been used effectively. The Development Team, including the developers, testers and all other skills are in one location, preferably working in the same room (this has been shown to double team performance).
The Scrum Master should be in that same location. The Product Owner may be located elsewhere. I trained and coached nearly 20 teams using this pattern at various clients. It seemed to help when the development team was the same company and not a vendor, though I’ve seen it work with vendors as well.
Tips for Success:
- Request 100%
- Co-Locate in the same Room.
- Low or high-tech cameras and video conference capabilities
- Minimize Timezone separation between the Dev Team and the Product Owner. For example, for Product Owners in the US, Teams in South America have the least
- If you are frequently a buyer from vendors in this space, build this into your contracting process. Don’t let the vendor build a team that is distributed
- Use the Scrum Framework as is without changing it
#3 – Sister or Pair Teams
Sometimes with a larger team that is spread across two locations, that team can be split into two smaller teams that each can be co-located within their geography. By co-locating two smaller teams, the number of communications across the geographies can be minimized.
In a recent example from one of my financial services clients, they had a development team of 9 team members that were split between Chicago and Chennai India. The Product Owner was located in Chicago.
The Dev team was a little larger than preferred, and, all the communications between the two sites were restricted because of the 11 1/2 hour timezone separation. By splitting this into two teams, each team could operate mostly independent.
This reduced the communications channels, the handoffs between timezones, and the stress for all the communications to occur during their very short timezone overlap. It also reduced the tendency to over document everything.
Over time, this pattern led to greater capabilities for the organization. Initially, the team in Chennai lacked the knowledge to do all the development which required an investment from the Chicago team.
The architect in Chicago made an investment in the Chennai team members to grow their skills and help them understand where and when it was necessary to go to him for questions.
#4 – Minimize Timezone Distribution to Just a Few Hours
If it is not possible to co-locate everyone, at least minimize the timezone separation to 1 or 2 hours, or 3 hours maximum. The goal is to maximize the number of communications that can occur between team members while they are working, and minimize delays for decisions or questions.
Though some people believe in ‘around the clock development’, my experience has been that too much time is wasted in handoffs. Without overlapping work hours, it isn’t really a team so much as a collection of individuals.
#5 – Split the Team into two Smaller Yet Co-Located Teams
If you have a larger team, perhaps you can split it into two separate teams that are each co-located yet still deliver end to end. This may require an investment in cross-training.
Your Thoughts on Using the Scrum Framework with Distributed Teams?
I’ve presented my experience and recommendations here. Do you think it’s possible to use the scrum framework with distributed teams and maximize team performance?