I worked on a scrum team once that had most of its members co-located in two offices in Israel, with one guy, Peter, in an office in California, a 10 hour time difference. Obviously, with this kind of gap it was nearly impossible to communicate with him in real time, and a daily scrum would have been highly impractical. And so instead of using scrum, we found ourselves using “scrum plus.” Or more precisely, “scrum plus Peter.”

I’d love to tell you how we found ways to include Peter in our scrum events and how we all made an effort to make him a part of the team and whatnot. But the honest truth is that we didn’t. We ran our team without him, and occasionally delegated tasks to him via email. We got away with it because Peter was (and still is) a good developer and generally a good guy, and because he was accustomed to working basically alone before scrum, so nothing much changed for him.

Now, I am in no way advocating treating your remote team members like we did. I’m a huge advocate of using scrum in remote settings, doing everything you can to maintain and expand intra-team communications when working remotely. But sometimes synchronic communications is just not possible: imagine if our team had been distributed more evenly, with a third of the team in California, a third in Israel, and say another third in India. How could we possibly run a daily scrum like that?

Semi – synchronous Scrum

Semi-synchronous scrum happens when not all team members are generally available to talk to one another. This is different from a distributed scrum team in which people are remote physically but are still in roughly the same time zone and can communicate in real time. In semi – synchronous scrum, real-time communications are possible but they require special effort that is not always taken.Here’s a few things to keep in mind with semi-synchronous scrum.

Trust and Communication

Trust is a key component of any scrum team. Trust leads to openness and courage, and it fosters transparency, which is crucial for inspection and adaptation. We trust our team members to put in their best efforts and have the best interests of the team in heart. We also trust that our team members have our personal interests at heart: teams can only engage in productive conflict if team members don’t take it as a personal attack when their ideas are challenged. Likewise with communication, which is crucial to just about every facet of teamwork.

These factors become an order of magnitude more important when talking about a remote team: When communications are reduced to only the verbal, or maybe even only the written form, a lot of the trust-building body language is lost. When you can’t look someone in the eye, it’s much harder to build trust. Moreover, when distributed teams are located around the world, issues of language and cultural norms come into play as well.

This blog post is far too short to be able to discuss all the ways in which remoteness effects trust and communications. But suffice to say that they are crucial and that you, as a team, must deliberately and constantly work on improving them. (If you’d like to have a deeper conversation on how to do this, you’re always welcome to message me)

Share the pain fairly

Teams that are distributed across the world are the extreme and fairly rare example of a distributed team. More often than not, your team would be mostly in the same general timezone (plus or minus an hour or two) with one or more “problem children” in completely different zones. Even when there is a wider spread, there is a tendency to see the “home timezone” as the one where the company offices are located, where the CEO sits, or simply the timezone of the scrum master who is usually the one setting these meetings.

When this sort of situation exists, your team must make special effort to share the timezone pain among the team members. It is tempting to say that if most members are in timezone X then meetings should always be in X time, and people in timezone Y can stay late or wake up early. But this sends the message that they are second-class team members, fostering resentment. Occasionally asking eight people to wake up early to talk to the two guys in the other timezone will make them feel much more like part of the team.

Meet socially

You may not be able to work with each other on a daily basis, but you can (and should!) meet occasionally, and not just for work. My teammate Peter, whom I mentioned above, used to come to the “main office” for a week once a year. When he did, he typically worked in a little office to the side of our main development area and mostly kept working on his own. The main purpose for his visit was social. He would get to eat lunch with us at the cafeteria, and after work, we would go out for drinks or dinner. This helped him, and us, feel like we’re on the same team.

Even if you can’t meet in person (and in times of the pandemic, many can’t) it’s still important to invest in social interactions online. Try using a service like donut to connect with people in your organization you might not know as well. Or schedule a BBYO, virtual “team lunch” on zoom. At the extreme ends, one person’s morning coffee can be another’s evening tea. Seeing the faces behind the emails will go a long way to foster trust and communications in the team.

Asynchronous Scrum

Under Asynchronous scrum, real-time communications is very hard to do. people are all over the globe and it’s always 3 a.m. somewhere. Before anyone starts complaining I’ll state the obvious: Scrum is all about communication, collaboration, and synchronizing with your team. Strictly speaking, you simply cannot do scrum without synchronous communications. Having acknowledged this, let’s look at some of the things we can learn from Scrum to allow our remote team to function agily. Needless to say, all of the issues and suggestions from the ‘semi-synchronous scrum’ section also apply here.

Create a record

One of the upsides of having a team scattered all over the world is that there’s usually always someone working. In essence, while individual team members “go home,” the team itself keeps working. When that happens, it is important for members who’ve just logged on to catch up quickly. Having an ongoing discussion board or message channel (like slack), can go a long way towards keeping everybody in the loop. Be careful to keep it down to actual information – do your discussions in other channels. But if a team member can log into slack in the morning, read about a dozen messages, and know what her teammates were doing while she was asleep, she can be all caught up in about a minute. She can then check her email or other channels for things that require more detailed attention.

In some ways, this can also replace the daily standup. In fact, asking each member of the team to post a version of the three questions before they log off might be a good idea. If everyone posts “What did I do today?” “What am I planning to do tomorrow?” and “What impediments do I see / what do I need from others on the team in the meantime?” before they log off, their team members will be all synched up once they log on.

Mini-nexus

Nexus is a framework for scaling scrum across multiple (3 to 9) scrum teams. In some cases, where the team is spread out among two or three main locations, you might be able to create a “mini-nexus” of people who can synchronize with each other in real time and bring this information back to their particular locations. In the example I gave above, of a team spread between India, Israel, and California, you could have separate daily meeting in India and California, with people from the Israel office attending both and functioning as an additional (though by no means exclusive) conduit between the two subteams.

I am not a huge proponent of this method. While it can have the advantage of making things like planning meetings and sprint reviews easier, it has the potential of raising issues of fairness and communications which may outweigh the benefits. This could be useful, however, if your organization is working with a framework such as Nexus or SAFe, but not everyone can make it to the Nexus Sprint Planning or the PI planning, so having a couple of members representing the team may be appropriate.

Bite the bullet

Synchronous communication is so vital for agility that sometimes you just have to bite the bullet and stay up until midnight to talk to your team. It sucks, and when you do it the organization must recognize that it will make you less productive the following day, but sometimes you gotta do what you gotta do.

IF YOU DO, make sure it’s worth it. Make sure that if someone is staying up late for your meeting, you use that time effectively. Have an agenda and all relevant material ready and distributed well beforehand. Keep the discussion on-topic and concise. Ask people who are not staying up late to show up (or connect remotely) early, so that you don’t waste time. And remember to share the pain equally, even if it means that in the next meeting six team members have to wake up at 4 am to accommodate one person.

Kanban to the rescue

One of the major problems that semi-sync and async teams have is that Scrum has a lot of meetings. This is deliberate, of course, and is designed to keep the team members engaged with each other and collaborating. But in the context of remote teams that have only a couple hours’ worth of overlap time, spending a lot of it on meetings may feel like a waste.

This is where Kanban, with its focus on limiting Work-In-Progress (WIP) rather than time, can be a better fit for some teams. This is not to say that Kanban does not have meetings, or that it does not require synchronization; it certainly has and does. But the flow-focused approach means that you may be able to transfer a lot of the planning activity to email and other means. You still need goals, and you absolutely still need refined, ready PBIs that you can pull. But because you are only pulling new work when current work is ‘finished,’ you can focus your planning on one or two PBIs at a time, as opposed to the ten or twenty you might look at during a scrum sprint planning meeting.

This is not to say that Kanban is a silver bullet (nothing ever is), and moving to kanban comes with its own trade-offs. You may find, for example, that PBIs that are currently being worked on are ‘blocked’ until someone on the other side of the world wakes up, but that you can’t take any new work because the WIP limit has been reached. Or that transferring some of the planning to email can cause your inbox to explode. Like everything else in agile work, you must experiment with what works best for you and your team.

Final thought

In our world today, remote work is growing at an unprecedented rate. It was a trend that was rapidly expanding before the pandemic, and simply exploded during it. Even once everything “goes back to normal” we can expect that many people will not go back to the office, and many companies are already making plans to make part or full-time remote work a long-term strategy. In this time of uncertainty and shifting priorities, agility is more important than ever, and practicing agility in a remote setting is a challenge that many organizations must face, some for the first time.

I hope that this list helps point out some of the ways in which teams that are not just remote, but distributed, can still achieve an agile workflow. This is by no means an exhaustive list, and every organization will find itself dealing with unique challenges when it comes to remote agility. If you would like to have a deeper conversation about how your organization can practice agile methods in a remote setting, please feel free to email me at boaz@makecodebetter.com or on linkedin.