How to Run Scrum with a Distributed Team

Appsembler

July 18, 2016 · 8 min read

Here at Appsembler, we’re building a distributed-first team. This gives us a number of advantages, but also introduces challenges as we’ve been rolling out our iterative development process — in particular, Scrum.

I’ve done Scrum in very small (3-person), small (15-person), and large (100-person) engineering teams. I’ve tried it in varying levels of adherence to the Scrum protocol (more on that later) and I’ve even used Scrum in a mixed-role team of engineers and content/community folks.

Where distribution breaks Scrum

Scrum is intended to be a low-overhead process, and it accomplishes a lot of that through in-person collaboration and minimal documentation. Unfortunately, these principles don’t map well to distributed teams.

In-person meetings

The Agile Manifesto’s principles state: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This one should be pretty clear. By virtue of having a distributed team, your team aren’t sitting together.

Minimal documentation and tools

The Agile community has mostly dispelled the myth that Agile / Scrum means no documentation. However, minimal documentation and tools use are still core to the philosophy. Unfortunately, unless you’ve got a high-res wide-angle webcam–and impeccable penmanship–you can’t use sticky notes on a whiteboard to plan a sprint. And team members certainly won’t be able to physically pick up sticky notes mid-sprint as they take on tasks.

Synchronous discussion

If your team is geographically distributed, regular synchronous discussion is going to be impractical or impossible. Our team is currently spread across 5 time zones with a 9-hour delta, and one of our team members is traveling across southeast Asia.

Scrum team makeup

Co-located Scrum teams

If you’re distributed in that you have several offices, you might be able to have your scrum teams co-located. In this case, you don’t have a lot of work to do, outside of coordinating review sessions and Scrum of Scrums.

Scrum teams in similar time zones

If your team is fully distributed (no large offices), you might consider building your teams in two adjacent time zones. This will make synchronous discussion within the team much easier on a day-to-day basis, reducing the need for documentation and coordinated handoffs.

Fully distributed Scrum teams

This is what we’re doing, for several reasons. First, we don’t have “central offices” and want the freedom to hire the best engineers regardless of where they live. Second, as a SaaS company, we need engineers in multiple time zones to fix issues and minimize downtime. Third, we want the ability to have people change teams at sprint boundaries, without being restricted to one team by their physical location.

So is Scrum incompatible with fully distributed scrum teams? No, not if you’re willing to adapt it.

Making Scrum work in a distributed team

Iterating on the process: Modified Scrum

If you’ve done Scrum in a larger organization, or have received any formal Scrum training, you know it prescribes a process that is meant to be followed strictly. Scrum allows for flexible, agile work, but the process itself is supposed to be fixed.

In order to make Scrum work in a distributed team, you’re going to have to start breaking some rules.

Scrum’s retrospective meeting is a great chance to talk at the end of a sprint about what worked and what didn’t. In strict Scrum, you’d identify what ran counter to how Scrum is supposed to work and identify actions to improve next sprint. In modified Scrum, I like to use the retrospective to identify ways we can adapt the process to the team’s needs. It’s iteration on the iterative process.

Use the right tools for the job

Communication should happen in four main places:

Project management. Whether you use Asana, Trello, or something more built for Scrum, use it consistently. Anyone on a team should be able to look at a task and understand exactly where it is and who’s working on it. (We use Trello.)
Group chat. Group chat with archive and search is critical for distributed teams. Choose your tool: Slack, HipChat, IRC, or a chat built into your project management software. (We use Slack.)
Documentation. Sometimes you need to collaborate via a document. Use Google Docs, wikis, or a Github repo. More below. (We use a mix of these.)
Video chat. There are times when a team needs to have a live, face-to-face chat. If you do this, record it so that those who couldn’t join can watch. (We use Hangouts and GoToMeeting.)

For the love of all that’s good, don’t use email for internal communication and definitely not for assigning tasks to people.

(I have gotten on my soapbox before about email.)

Assume asynchronous communication

This one deserves its own blog post. Using a group chat tool can make it seem like people are always on. Worse, without an explicit policy, people can start feeling like they *have* to always be on. Always-on chat is unrealistic and unsustainable.

If you’re using any of the above tools, don’t assume that the person you’re messaging will get back to you immediately. They may not get back to you until they’re on again, which could be 12 hours from now. If multiple people could answer your question, ask @channel.

This is an especially hard transition for managers, especially those of us who are accustomed to working with teams in the same office. Warning to managers: if you’re in the same time zone–or worse, the same office–as some of your teammates, do not make them your main go-to for every urgent request. They will become interrupt-driven, potentially burn out, and you’ll start wondering why everyone else “isn’t as responsive”… or why they’re not getting their other work done.

On the flip-side, you need to stay on top of replying to people. You can’t let responses slip, or else communication will stretch across multiple days. If you see a @channel mention and you’re on, don’t assume that someone else will respond — jump in there. If you’re heads-down writing code, you don’t need to be (in fact shouldn’t be) interrupt-driven by Slack or Trello notifications, but build a few time-boxed break points into your day to check on those channels.

Document, document, document

Scrum was built to be a low-documentation process. Distributed Scrum requires frequent and thorough documentation — not product requirement documents and specs, but documentation about progress. Everyone should keep their tasks up to date in the project management system, with information about what they’re doing, so that others on the team have a clear and detailed picture of what’s been done. This may feel heavyweight, but it makes handoffs easier in the case of blockers, multi-person tasks, or someone getting ill. This is especially true if you’re working on a critical issue. You might have run out of time, but someone else needs to be able to pick it up where you left off.

Your chat tool–while searchable–is not a great place to store this documentation. It’s too hard to parse, and it’s not in context. If you do hash something out in Slack (which is normal), use an integration to tie that chat back to the related Trello card. There are also emerging tools such as Tettra that try to automatically capture the knowledge your team is sharing in Slack.

Standups via Slack

Standups are intended to be synchronous, in-person meetings. With a distributed team, it gets more complicated, but there are many tools available, as Jacob Kaplan-Moss points out.

We tried daily video standups, but they ended up providing limited value: finding a common time was tricky, and since they landed at different times of everyone’s day, the normal format didn’t work. Instead, we’re using Slack for standup posts, and doing them asynchronously — each team member posts at a time when they’re able. I got tired of nagging people, so I delegated that job to a bot named Tatsu, who’s been doing a much better job than I.

Review, retrospective and planning meetings via videoconference

These are the only synchronous meetings, but they need to happen synchronously. Your team should be showing off what they’ve built and receiving live feedback. They should be breaking down user stories into tasks and doing estimations live together, so that they can learn from each other by sharing their thought processes.

Scheduling these meetings is tricky — some will be joining in the early morning hours and others in the evening. We shoot for mid-day Eastern Time, which tends to be a reasonable common time for most.

To keep the meetings from being epic, you can (and should) prep. You can prep your review by collecting the completed/incomplete/added items, the retrospective by collecting advance thoughts (we use a Google Doc), and the planning meetings by doing backlog grooming and capacity calculations in advance.