Don’t Use The Scrum Framework with Distributed Teams!

Recent studies show that 3 out of 4 Software Development Teams using the Scrum Framework 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 post should really be called, “Don’t Use Distributed Teams“. It’s not about the Scrum Framework, which is still the best way to organize work. It is about the distribution of team members and the impact that distribution has on team communications and performance. Which is often overlooked.

12 Factors Leading to High-Performing Scrum Teams

The reason we are assembling a team is to get the best solution at the lowest cost. Unfortunately, many people focus 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 and Encourage Face to Face Communication

One of the biggest factors for high-performance is the ability to sit and work together in the same space. Team co-location has been demonstrated to increase productivity by as much as 100%.

The main reason for this is that face to face communication provides for the richest, most accurate communication which reduces the overhead of documentation, prevents errors and reduces rework.

Face to face communication is also mentioned as one of the 12 Agile principles. The other benefit of co-location is osmotic communications, where all team members learn from each other just by virtue of sitting together.

2. Avoid Handoffs

Handoffs to and from a Scrum team create risks and information scatter. Experts estimate that 50% of information is lost when there is a handoff.

Handoffs occur when others outside the team prepare documents (such as a requirements document) and hand it to the team. Handoffs within the team should also be reduced or eliminated where possible.

3. Choose an Appropriate Team Size

Most Agile experts contend that an agile team should be between 5 and 9 team members (excluding the Scrum Master and Product Owner). My own experience is that teams of 5 or 6 are actually far more productive and cohesive.

Be cautious about adding people because they are available or low cost. They lead to a tendency to build bigger teams of more than 10 which turn out to be less productive and more costly.

4. Support the Team to Self-Organize

The Scrum Guide mentions self-organizing 7 times. The idea is that no one outside the team tells the team how to operate. Those closest to the work should make the decisions about how the work is done. This autonomy supports intrinsic motivation and fosters ownership of results.

5. Encourage Psychological Safety

One of the key findings of the Aristotle study of 180 teams at Google, was that high performing teams had a psychological safety. Psychological safety is what the team members feel about taking risks, making mistakes speaking up, and doing what they think is right without feeling insecure or embarrassed.

The term psychological safety was coined by Amy Edmondson, a professor at Harvard’s Business School.  She has written extensively on the topic and recorded several videos (this was one that I liked).  Amy talks a lot about the safety factor directly affecting team learning or “adjusting to its surrounding through outwardly sharing observations about their environment”.

6. Help the Team to Mature

A new team is immature, and is pretty much just a collection of individuals. Their performance will be less than optimal until and unless they mature into a high performing team. In fact, there are predictable patterns for team maturity. In my experience, this tends to take 4-6 months before teams really hit their stride.

Richard Hackman in his book The Wisdom of Teams introduced a model of maturity and performance. In both cases, team performance is low at the beginning, and team performance increases as teams “mature” or work together, bond, and trust each other.

Recognizing that new teams go through some level of thrashing, or forming/storming/norming/performing, I always recommend that organizations help teams move as quickly through these stages and get to performing. Then, and this is the key, leave those long-standing and stable teams alone.

The maturation process is faster for teams who are co-located, have maximum time overlap, speak the same language, and are from the same organization. Teams that are not co-located, have little or no time overlap, speak different languages and work for different companies are going to take longer to mature and perform at a high level.

7. Eliminate any Specialty or Sub-teams

One of the common challenges in organizations are that people have become specialized or ‘one trick ponies’. This is common for the business analyst role, but it happens with testers, architects, and python developers as well.

Specialization can be thought of as established rules for “that is not my job” and “that is my job so don’t you touch it”. It creates bottlenecks and frankly a lack of end to end ownership for the results. Though this is called out in the Scrum Guide, many organizations choose to ignore the guidance in an attempt to maximize individual efficiency. After all, if Dan is the best at PCF development, then Dan should do all that work. This should be eliminated!

One challenge is that many organizations hire vendor A from location X to do the development and vendor B from location Y to do the testing. They are seeking lowest cost, specialization, and a set of checks and balances. Do you see the problems inherent in this approach?

8. Focus on People and Interactions over Process and Tools

In high performing teams, there is a focus first on getting the right people on the team and helping them to work well together. Process and tools are important, but not nearly as important as having the right people on the bus.

9. Focus on Working Software over Comprehensive Documentation

Another Agile Value prioritizes “Working Software over Comprehensive Documentation”. The focus is on the delivery of the solution that the customer needs, not the paperwork that describes the solution.

Documentation that is produced as part of the process should be “barely sufficient”. This aligns with the agile principle of keeping things simple.

10. Encourage Shared Accountability

The Scrum Guide is very clear about the shared ownership and accountability within the Development Team. The goal is to encourage everyone to work together to accomplish the team goals and to avoid anyone thinking “I got my work done” or that the “test team wasn’t able to finish”.

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

Most organizations today underestimate the impact of having team members working on multiple teams. This decreases focus and results in inefficiencies due to context switching.

These inefficiencies result in productivity being less than half when a team member is working on 3 teams or more. When team members are on just one team, they are more productive.

They are also more likely to be committed to the goals and success of the team, and the team growth maturity and performance. There is usually a more clear sense of team spirit and esprit de corps on the team.

12. Provide Time for Cross-Training and Learning

While not explicitly mentioned in the Scrum Guide, my experience has shown that teams that cross-train each other and learn from each other tend to perform better.

When teams are new or immature, they frequently gravitate toward each person doing just one thing. This specialization causes bottlenecks and key person dependencies. Though not always obvious, the bottlenecks have a way of slowing things down and reducing overall business Agility.

Teams that cross-train and learn from each other reduce or eliminate these bottlenecks. They also become more capable to solve problems and respond to change; they become more valuable to the organization and much more Agile.

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

All things considered, distributed teams are not going to perform as well as the same people sitting together in the same room.

Since we’ve discussed the factors that contribute to high-performing teams, let’s look at the impact of distributed Scrum team members on these factors.

1. Distributed Teams Take an Automatic 50% Performance Hit

As noted above, distributed teams are already 50% less productive than co-located teams. If you are getting rock stars who are in a less costly place than you, it may be worth it. But if your team is just a group of average performers, you’ve started behind.

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

Most distributed teams lack the technology or the desire to have face to face communications, or to simulate it with web cameras or other technology.

The ability to have an impromptu discussion or ask a question of a team member is also greatly diminished or may be eliminated entirely if your teammate is sleeping when you have the question.

Discussions and information sharing tend to be concentrated in a handful of short meetings like the daily standup. Questions may go unanswered overnight; progress on work items may be stopped until a decision or answer arrives from the team.

Or, team members are forced to make assumptions in order to keep things moving. These delays make inefficiencies add up.

I know one team that was distributed between Chicago and Chennai. They created an elaborate question and answer document process that facilitated the handoff of work back and forth twice daily from one location to the other. It was an extraordinary investment just to keep work going in both places.

3. Distributed Scrum Teams Create and Rely on Documents

As in the previous example, the lack of ability to just have a simple conversation with team members has another undesirable side effect – a focus on creating documentation.

More time and effort is spent hammering out the details of what is required so that when the distributed team members are developing the solution, they have all the information they need.

This extensive requirements documentation has been proven over the years to be a failed strategy – which is why high-performing teams place a premium on conversations over documents.

The extra effort that goes into perfecting the requirements documents has a diminishing return when it comes to preventing errors.

This problem is compounded when all team members are not fluent in the language the documents are written in. And all those documents that are getting created have to be read by someone – this is another waste.

4. Distributed Scrum Teams Have Many Handoffs

Handoffs are inevitable when team members are distributed. A common approach for offshore development is to use an Onshore Representative and sometimes an offshore representative.

A typical pattern is that an onshore representative will participate in the conversation with the business partners, say in the US, and then will have phone calls with the remote team members to communicate what is needed.

This telephone game has been around forever with predictable results. Plus, it is highly inefficient to have a dedicated person whose job it is to digest and spoon feed work to other team members who do the work.

In the worst of cases, there is both an “onshore representative” and an “offshore representative”. These non-working team members are simply conduits for work; they represent an unnecessary layer of overhead in the process.

Even if they are very skilled, they are still costing the team money, and introducing information scatter of up to 50%. They also undermine self-organization, sense of autonomy, and intrinsic motivation. Avoid the use of onshore and offshore representatives at all costs.

5. Distributed Teams Are More Likely to Specialize

Another common pattern for distributed teams is to have developers and testers separate. For some this is a conscious choice – they believe that testers will be more effective if they are in a separate organization than the developers.

Separating the two skills or having separate Dev and Test vendors is a recipe for disaster. The result will be that each organization will be finger pointing and working at cross-purposes.

Your defect tracking tool will become full of defects that get assigned and then bounced back and forth between dev and test like a ping pong ball.

You’ll begin scheduling defect review meetings that are not included in the Scrum Framework and that further reduce productivity and suck the life out of the team.

Even if you don’t separate test and development, distribution of the team often fosters a sense of “each person for themselves”.

Team members will come out of the sprint planning with their known task assignments but lose the ownership and joint accountability for the success of the sprint and solution being developed.

6. Distributed Teams Rely on Tools Instead of Conversations

Though today there are various scrum tools for remote teams or distributed teams, these tools should be secondary. Remember the Agile Value, Individuals and Interactions OVER Process and tools.

Individuals and Interactions OVER Process and tools

When teams are distributed, the tools become the focus. Jira, VersionOne and TFS are all great tools, but they are not magical. In fact, they tend to reduce the amount of transparency. My friend calls them information refrigerators, rather than information radiators! Remember the first Agile Value, People and Interactions over Process and Tools?

With a co-located team, we have high degrees of transparency. Co-located teams can use a physical task board for their sprint backlog which increases engagement and provides a big picture view of the sprint goals.

They can also hang their team value, definition of done, and architecture diagrams in a highly visible place and refer to them frequently.

Distributed teams are forced to put these types of artifacts into one or more tools. Tools may make it easy to see my work, but they don’t make it easy to see our work. Rather than create transparency, tools actually hinder transparency and accountability.

7. Scrum Masters of Distributed Teams Become Task Masters

The Scrum Masters job is to remove impediments and help the team self-organize. When the team is distributed, the Scrum Masters tend to become the task master.  They are the ones that pull up the virtual task board in Jira and filter on team member names to see their work.

When the Scrum Master is not co-located, as is the case with a distributed team, it is difficult for them to support self-organization, to monitor the team vibe, or to address conflict.

The Scrum Master role of impediment remover is reduced – particularly when they are working at different times than the team members. None of my Chicago-based Scrum Master would want to be woke up in the middle of the night when their colleague from Bangalore has a problem and work has halted.

8. Distributed Teams Rarely Self-Organize

I almost never see effective self-organization with distributed teams. Where I have seen it, the team was a team of relatively high performers who happened to work in different locations but were mostly all in the same time zone.

Why is self-organization harder with distributed teams? Here are some of the most common reasons that I have seen (note that not all will apply to all distributed teams):

• Scrum Master is not actually able to engage with every team member – An effective Scrum Master will foster self-organization. It’s hard to foster self-organization when you are not able to observe team dynamics and you really don’t have visibility to what is going on with each person.
• Role delineation and Strict Hierarchy – Hierarchy can manifest itself in several ways. Sometimes it is the tech lead or architect vs. the developer. It can also be developer vs. testers, full time employee vs. contractor, onshore vs. offshore, and having managers of others on the team.
• Physical and Timezone Separation – The more physical separation, the more difficult it becomes. And worse than physical separation is timezone separation. The fewer hours of overlap, the less we will be able to have a synchronous conversation and the more likely that we will exchange emails or pass messages through others in the telephone game.
• Language Differences – I don’t speak your language fluently, I may only rarely speak in meetings.
• Culture – We have strict rules about speaking up or challenging those above us on the hierarchy.
• Buyer/Vendor – Distributed teams that are all from the same company perform differently than those that are mixed vendor and company.
• Turnover – Some vendors use your project as the means to hire and grow talent. They expect a certain amount of turnover. When you have turnover, team maturity drops and you can expect the team to go back through Tuckman’s stages of development.

9. Distributed Teams Tend to Plan Separately

Teams that are separated by timezones tend to split up their planning. Each team does their separate planning in their own location and timezone. This leads to lack of overall ownership and a plan for sprint success that everyone agrees.

10. Distributed Teams Often Have Problems with Daily Scrum

Here are some problems that frequently occur in the daily standup or daily Scrum meeting:

• They run long (30 minutes plus) because there is so much conversation to be crammed in.
• The timing doesn’t work because of the separation so we only do it 2X per week.
• Not everyone attends because of the timing.
• We don’t get the big picture view because we are trying to scroll around in Jira to see each person’s tasks.
• Technology issues cause meetings to start late

11. Come to think of it, Distributed Scrum Teams have Problems with all the events in the Scrum Framework:

• Sprint Retrospective – A frequent anti-pattern is that not everyone participates equally in the Retrospective, if they show up at all. When timezone distribution is significant, team members may be asleep during the retrospective meeting.
• Sprint Review – Not everyone participates in the Sprint Review. Some just listen in, or, they are either sleeping or on their long commute home and can’t really participate.
• Product Backlog Refinement Meetings – Not everyone participates in backlog refinement because of lack of timezone, language, lack of business understanding. Rarely do teams feel it important for say an offshore tester to participate – they can learn about the system later.

You’re Going to Do it Anyway (use the Scrum Framework with your Distributed Team)

I know that despite cautioning against using them, that many people insist on using distributed teams with the Scrum Framework.

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.