“Scrum can’t work with distributed teams. Physical proximity is crucial to agile success.” A statement I’ve heard in the past, in one form or another, that I think is important to address.
Teams who are co-located will have less of a challenge delivering the highest business value in the shortest amount of time – my definition of agile success. However, with today’s tight job market, it’s increasingly difficult to find the best people in a geography that matches your location. Relaxing the geographic requirement for hiring new talent can often make it easier to get the team members you need.
If you’re not sold on the idea of distributed teams, I suggest you consider testing it out with a pilot team that is at least partially distributed before writing it off. Before you try to roll it out throughout your organization, you will want to create a team that is likely to be successful, so I’d play favorites here. For example, do your best to keep most of the team in one location, and pick strong individuals who are remote.
This will help you prove out the model of how Scrum can work at your company when team members aren’t sitting right next to each other.
At Ascendle, 100% of our development teams are distributed – in many cases across seven time zones – and they routinely out-perform any other development team I’ve ever seen. And it’s thanks to Scrum.
We’ve discovered a few key factors that make this work: Time zone alignment, verbal communication, real-time written communication, and a strict adherence to Scrum guideposts.
Time Zone Alignment
Because of its focus on side-by-side teamwork, it’s imperative that there are as many hours in the day as possible for Scrum team members to work simultaneously. We’ve found that as much as a seven-hour time difference can be accommodated, but not much more.
One group shifts their work hours a little earlier and the other a little later, and they can overlap by four to six hours per day, depending upon how much they adjust. On time-intensive days, such as when sprint planning occurs, there may be more of a shift to ensure enough time to complete the process.
I strongly discourage you to have members of the same team working on opposite sides of the clock – meaning an offset of 12 hours. In our experience, we have not had great success with offshore teams that did not have at least a few hours of daily overlap. The idea of having your offshore team members work while you sleep sounds romantic, but you introduce significant challenges without real-time communication. (Alzoubi, et al., 2015)
Verbal Communication
Verbal communication is a critical success factor for Scrum teams. While there can be the occasional written standup, the power of verbal interaction increases the team’s understanding of the issues at hand and their ability to effectively collaborate. Remember individuals and interactions over processes and tools from the Agile Manifesto. If you avoid verbal communication in lieu of written updates, you’re abandoning this key principle.
Our distributed teams use GoToMeeting for their Scrum ceremonies, and everyone participates. This brings another factor into play: verbal communication skills. If you have team members who struggle with being understood by others on the team, they likely aren’t a good fit for your pilot team and may not be a good fit for any Scrum team in your organization.
This may sound harsh, but if the entire team can’t effectively communicate in one spoken language, they are set up for failure. Verbal communication is too critical to the success of agile. You cannot “make up for it” via written communication. That may have worked with waterfall, but it will not work well with Scrum. (Melnik & Maurer, 2004)
Real-Time Written Communication
Communication doesn’t stop when the daily standup is over. Scrum requires an almost continuous stream of dialogue between team members. This will often mean picking up the phone – or Skype or GoToMeeting – but much of the communication between team members tends to be quick, focused on answering brief questions or synchronizing their work.
For example, “Maria, I just committed that code you were waiting on,” or “Ben, I fixed those code review comments. Can you take a quick look to see if it’s what you were thinking?”
For a co-located team, this is easy. They just turn around in their chair and tell the person. However, if they’re distributed, they need a way to facilitate this ad-hoc communication. A team chat room is an easy way to make this happen.
Tools such as Slack make this type of communication easy. If you have a distributed team, I highly recommend creating a team chat room.
There’s one other thing to keep in mind. Keep others in the company from adding their own commentary in the Scrum team’s chat room, which can be very distracting. If you must provide access to anyone not on the Scrum team, ensure they know it’s a “view only” arrangement and have them keep their commentary to themselves.
To provide access to managers and mentors, I suggest a separate chat room. This is where team members can go to ping those outside the team for help, without adding noise to “their” team room. To the greatest extent possible, keep the Scrum team’s chat room a “safe place” just for them.
Strict Adherence to Scrum
I’ve already talked about how important it is to stick to the fundamentals, but if you slack off with a distributed team, you’ll really feel the pain.
Co-located teams can often get away with cheating a bit. Although they’ll still be hurting their ability to reach their full potential, things won’t completely fall apart.
That’s not the case with a distributed team.
Without physical proximity to fall back on, they’ll quickly spin off in different directions and progress will likely grind to a halt. It’s always important to stick to the rules, but with a distributed team the cost for failing to do so becomes much more severe.
To the greatest extent possible, have everyone on the distributed team participate in every Scrum ceremony, and conduct them all verbally.
What are your thoughts on distributed teams, and their ability to be successful with Scrum? What are some of the obstacles you’ve encountered, and overcome, with distributed teams? Please leave a comment below.
References:
Alzoubi, Y. I., Gill, A. Q. & Al-Ani, A., 2015. Distributed Agile Development Communication: An Agile Architecture Driven Framework. JSW, 10(6), pp. 681-694.
Melnik, G. & Maurer, F., 2004. Direct Verbal Communication as a Catalyst of Agile Knowledge Sharing. Agile Development Conference, 2004, pp. 21-31.
