“Can we use Scrum with ‘remote’ staff?”

A Common Question People Ask

I keep hearing from Scrum trainers that Scrum is not for remote teams. Is there any truth to that?

The quick answer: there’s no truth to that. Organizations with remote staff frequently report that implementing Scrum has resulted in measurable benefits.

The Official Position

Let me start by saying it is the official position of Scrum.org (and by extension, Ken Schwaber and the entire community of Professional Scrum Trainers) that Scrum does not require co-location. By that, I mean we acknowledge that the Roles, Events, Artifacts, Rules, and Values of Scrum can be employed regardless of a group’s topology. Whether a group of people are co-located, or separated by walls, time zones, or entire oceans, the parts of Scrum can be implemented. And, among those who do so, a vast number of people report that Scrum has helped them achieve measurable benefits irrespective of whether they were co-located, dislocated, distributed, or remote-only.

The Unofficial Position

First, (and I know this will sound like a contradiction) I’ll add that every (almost every) Scrum trainer and coach that I’ve spoken with on this topic will:

• advise that a team will be more likely to achieve the results of Scrum if they co-locate;
• and will recommend, if a remote or dislocated team is struggling to coordinate their work, they ought to co-locate at least for a few Sprints.
• Yet, many of those same people have authored books or blog articles on the topic of “Remote Teams”. This isn’t an act of hypocrisy; rather, they authentically want to share techniques proven to help people cope with their dislocation.

Second, among people I meet who have worked in co-located teams, almost every one of them (99.9999%) will enthusiastically recount the advantages of co-location and will swear by its efficacy. So, while most people acknowledge the Scrum framework is equally applicable for co-located teams, and dislocated, distributed, or remote-only groups, that does not mean it is equally effective for all modes.

I’d love to see more data about this, but the research to-date tends to focus on the comparison of non-Scrum versus Scrum. I'll explain: most experience reports can be summarized like this:

Among survey respondents who work with…

• remote-only personnel, those who have implemented Scrum report measurable benefits.
• dislocated personnel, those who have implemented Scrum report measurable benefits.
• co-located personnel, those who have implemented Scrum report measurable benefits.
• distributed teams, those who have implemented Scrum report measurable benefits.

You see, the change being measured is the implementation of Scrum. In summary: we suffered tons of dysfunction (regardless of our geography), and Scrum helped us improve. I don’t find that hard to believe; it’s a common story. But the data I’d like to see would be:

Among survey respondents who employ Scrum with co-located teams…

• then changed their topology to dislocated
• then changed their topology to distributed
• then changed their topology to remote-only

…their results are*??????*

The dearth of evidence on this question is frustrating. (Or telling!) Every so often, a blog article will appear praising the comforts of remote work. Most of those articles have a common story arc: I work in a software Startup; we were all co-located and it was awesome; as we grew, we moved into a larger office building and somebody decided that “open concept” was a good idea; then I couldn’t concentrate for more than 28 seconds at a time; so now I’ve decided to work from home and I love it!

Certainly, those stories are evidence of the damage caused by open floorplans! But it’s difficult to treat them as evidence toward the efficacy of remote working.

So, my unofficial official position is I believe the Scrum community requires more evidence before it can take an empirical stance on the question whether co-location is always a superior mode.

In the meantime, I’m with Jeff…

I’ve had conversation with Dr. Jeff Sutherland on this topic. I recall a brief interchange between Jeff and a lady in one of his Scrum Master classes:

“Our team is distributed across multiple countries…I’d love to co-locate but what advice do you have for us?” She asked.

Jeff answered: “What’s been your experience with co-location?”

Without hesitation, she responded: “Well it’s far easier to communicate. It’s faster. Fewer misunderstandings. I’ve loved it.”

Jeff said, “Well, then…do that!”

His response may sound flippant at first, but his response illustrates the essence of Scrum. That is, if a Scrum team takes seriously that they are self-organizing; and if that Scrum team believes (either by consensus or by empirical study) that co-location (or remote-only, or dislocated, or distributed) is optimal; then be it resolve that’s how they ought to arrange themselves.

What More Can We Glean from The Scrum Guide™ or the Agile Manifesto?

The Scrum Guide™

The Scrum Guide™, in describing the Scrum team speaks of team size; it discourages job titles in the team; it reminds that the Development Team is self-organizing, and so on. But it says nothing of team topology. The nearest thing to say on the topic of team topology is a seemingly unrelated statement about sub-teams:

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis.

That rule is present in the design of Scrum because, empirically, we know that division of labour based on specialized skill introduces delay and risk due to hand-offs, sequential/defined processes, and brittle communication between component groups.

And while that statement is not about team topology, I suggest if a team experiences delay and risk due to hand-offs, sequential/defined processes, and brittle communication between geographically disperse groups, then co-location is a strategy worth considering!

The Manifesto for Agile Software Development

The authors of Scrum, though not in The Scrum Guide™ itself, both describe Scrum as an Agile framework — and both Ken and Jeff were among the co-authors of agilemanifesto.org.

Among the 12 principles of the manifesto, they wrote:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I’d argue that is quite unambiguous. If the “most” efficient and effective method is face-to-face, then all other methods are…less Agile.

If a Scrum team wishes to be “Agile”, they ought to co-locate. But if a Scrum team finds they can be as effective, or more, in a dislocated, distributed, or remote-only shape, then they ought to do that instead. (And we can debate whether they’re “Agile” perhaps in another article.)

This article was inspired by a related question I asked during this webcast earlier today, co-produced by Eric and Lindsay of Scrum.org. One of the attendees asked me whether Scrum can be used with “remote” teams. I addressed the question within the webcast, but it’s a question I hear frequently so I hope this article serves to clarify the answer.