How to Use the Scrum Framework with Distributed Teams
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 over 20 teams to effectively use 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% dedicated people. No fractional people assignments!
- Co-Locate all the team members in the same room.
- Use low or high-tech cameras and video conference capabilities to connect the co-located team with the Product Owner.
- Minimize timezone separation between the Dev Team and the Product Owner. For example, for Product Owners in the US, Teams in South America or Canada have the the least timezone separation, even though they are geographically separated.
- If you frequently buy from vendors in this space, build team co-location this into your contracting process. Don’t let the vendor assemble a group of individuals from different places because there is a hidden cost of their productivity.
- Avoid team specialization, onshore/offshore reps, separate locations for testing and development, or having any form of team spokesperson.
#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 of questions and answers. 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
This is similar to tip # 3. It may be possible to take a team spread across multiple locations and create smaller yet co-located teams. The common argument against this is that you don’t have all the right skill sets (due to your heavy specialization).
The answer is aggressively cross-train. The best time to cross-train was before now and the second best time is now. Like technical debt, specialization represents a form of human talent debt that creates a tax on all future development.
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?
