Don’t Use The Scrum Framework with Your Distributed Team!

Recent studies show that 3 out of 4 Scrum Software Development Teams are distributed, meaning that at least some of the team members are not in the same location.

Co-location is one of 12 factors that can contribute to or detract from high-performing teams. This article explores the 12 factors that contribute to high performance when using the Scrum Framework and then explores how having a distributed team impacts productivity.

This short article (which is a summary of the longer article here) should properly be called, "Don’t Use Distributed Teams". It’s not about the Scrum Framework, which remains one of the best ways for teams to organize and get work done. It is about the distribution of team members and the impact that distribution has on team performance. Which is frequently overlooked or thought to be trivial.

I've summarized the 12 factors leading to high-performing teams below. You can read the details about each of these factors, as well as the 11 reasons distributed Scrum Teams don't Perform Well by reading the full blog post here.

12 Factors Leading to High-Performing Scrum Teams

The typical driver for creating a Scrum team is to get the best solution at the lowest cost. Unfortunately, many people focus on only on cost and ignore team performance factors when designing their Scrum Teams.

Since 2008, I’ve had the opportunity to train and coach over 100 Scrum teams to use the Scrum framework. I’ve also taken a number of training courses and pursued various Agile and Scrum certifications. Through that experience and training, I’ve come to see the following as key factors to creating high performing teams.

1. Co-Locate the Team

2. Avoid Handoffs

3. Appropriate Team Size

4. The Team should Self-Organize

5. Encourage Psychological Safety

6. Help the Team to Mature

7. Eliminate any Specialty or Sub-teams

8. Focus on People and Interactions

9. Focus on Working Software over Comprehensive Documentation

10. Encourage Shared Accountability

11. Get People Who are Full Time Assigned to One Team

12. Provide Time for Cross-Training and Learning

11 Reasons Why Distributed Scrum Teams Don’t Perform as Well

1. Distributed Teams Take an Automatic 50% Performance Hit

2. Distributed Teams Have Few or No Face to Face Communications

3. Distributed Teams Create More Documents

4. Distributed Teams Have More Handoffs

5. Distributed Teams Are More Likely to Specialize

6. Distributed Teams Rely on Tools Instead of Conversations

7. Scrum Masters of Distributed Teams Become Task Masters

8. Distributed Teams Rarely Self-Organize

9. Distributed Teams Tend to Plan Separately

10. Distributed Teams Often Have Problems with the Daily Scrum

11. Come to think of it, Distributed Teams have Problems with all the Scrum Events

You’re Going to Do it Anyway

I know that despite cautioning against using it, many people are going to use the Scrum Framework with their distributed teams. They don’t see it as short-sighted and ignoring overall costs in favor of hourly labor cost. They insist it is the most cost-effective way of getting things done.

In my follow-on article, How to Use the Scrum Framework with Distributed Teams, I outline some patterns for success if you must use a Distributed Team and the Scrum Framework.