Scrum for global teams: What doesn't work?

The challenge of syncing across continents

There is one very important thing about the TestGorilla team: it is super global. We don't use the “global” term to indicate that our team is not all in the same country, but to indicate that it is very likely that you work daily with multiple people, each of them probably in a different time zone. 

In our regular daily meetings, we have people connected from Peru, Barbados, Brazil, Argentina, Portugal, Nigeria, South Africa, Romania, Ukraine, Pakistan, India, and the Philippines. And sometimes one or two are working from somewhere else, getting a taste of the digital nomad life. This amazing distribution, spread over 12+ time zones, impacts how traditional Scrum ceremonies function and fit into our workflow.

I acknowledge that TestGorilla is not the only company to embrace global work like this. But this is a new concept that was not as common before the pandemic. Before that, teams were usually based on the same timezone, or at least the same country, or perhaps the same city, or even the same office. And it was based on this team configuration that Scrum was created and became popular (1990-2010). 

Applying Scrum efficiency in a highly distributed team is challenging. It requires creativity to ‘bend’ some of the standard recommendations to adapt this new team configuration and boost efficiency, thereby reducing waste. As an Engineering Manager, I've experimented with many changes to our Scrum ceremonies. Here are two significant changes we have introduced with the best of intentions, but that did not perform as well as we hoped for:

Asynchronous groomings

What is the most important thing about the grooming session? If your answer is “assign story points”, then you are doing it wrong. By focusing only on that, you are missing its full potential. If you allow them to, these sessions can add much more value. And do you know what prevents them from offering more value, apart from an impersonal designation of story points? Making them asynchronous. 

The value of the grooming session lies in generating conversations between the engineers. Working together, we can define how we want to break down tickets into smaller deliverables, suggest changes to the product team, and uncover a variety of other little insights that wouldn’t occur if we were holding these meetings asynchronously.

Asynchronous daily meetings

I have tried this approach many times in my career, and yet I kept coming back to the idea. I thought this time I have a different perspective, I’m going to use Confluence comments to create an active conversation between team members. I asked our engineers to post their daily updates in these shared documents and shaved about 30 minutes off our calendar in the process, but we lost a lot in terms of team interaction. 

The conversations I was hoping to ignite in the Confluence comments just weren’t happening, and the team frequently forgot to post their updates there as well. 

Note, this was the latest in a long line of experiments in asynch updates. In the past, I have also tried using Slack in different ways for this purpose, from setting up a dedicated channel to starting update threads to just encouraging posts in the channel at the start of their workday. None of them worked. It just wasn’t worth it to gain 30 minutes while losing the project discussions, the small talk at the beginning of the call, or even losing the roar (yes, we scream together at the end of our daily meeting - should I create a post about building team identity?).

Have your team mastered async dailies or groomings? If so, I’d love to hear how you’ve made it work and swap tips. Keep an eye out for part two of this post, where I’ll share four Scrum tweaks I’ve tried with my team and the ones that really paid off.

Until then, find me on LinkedIn.