How to Use the Scrum Framework with Distributed Teams

Don't Use Scrum Framework with Distributed Team

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?

Related Posts

By Anthony Mersino

Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.


    1. Dan, thanks for your comment. The outcome for #3 and #5 is indeed the same. Perhaps in my next rewrite I’ll clean that up.

      Thanks, Anthony

  1. Agree 100%, but my teams will have 3 months work in different location, how to pass through those three months? ( Several team members gradually move to DT office rather than suburb office).

    1. If you have to work in a distributed fashion, here are some things that others have tried to mitigate the separation. First, try to have everyone together face-to-face for the first few days or weeks so that they begin to build relationships. Second, when working distributed, see if you can organize the sprint boundary meetings on the same day so that the team can meet back together (face-to-face) for those key team meetings. Finally, do what you can to encourage shared work and ownership of the team outcomes rather than having team members divide up the tasks. Good luck!

  2. So I realize this is a rather old post, but I’m wondering what your take is on what we have to do nowadays. With COVID, we’re all working from home. No real issues with time zones, etc., we just aren’t allowed to be at the office. We are *not* a software team; more of a hardware team (with some embedded software). We meet by Zoom, but having a lot of trouble getting agreement on scope for the sprint, how to manage the sprint board, etc…..

    1. Hi Allen, I haven’t looked at this since COVID but it is clear that most people are working remotely today. Not having the timezone issues is helpful for you and perhaps if your teams were already using Scrum and meeting a face to face, working remotely will be much simpler and effective for you.

      Did you have trouble managing the scope of the sprint and the backlog before working from home? Sometimes the problems are bigger when there is separation.

      Thanks for your comments.

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.