Team in different timezones

From the "Mastering Professional Scrum" book: 

Distributed Teams

Similar to outsourcing, distributing team members can reduce the cohesion and effectiveness of a team. People working in different time zones will have less time to collaborate depending on how much their workdays overlap. People working at different sites will find that they may be less effective in their collaboration as compared to people who work side-by-side. They will find it more difficult to work together as a team. It is not impossible to make distributed teams work, but it is certainly much harder.

Team members from different cultures also sometimes struggle to communicate. Some cultures are more open to expressing differences of opinion, whereas other cultures are more deferential in the face of differing social status. These and other factors make transparency more challenging. Trust and time working together usually help team members reach greater levels of mutual understanding that makes transparency and collaboration more effective, but this shared mindset is harder to achieve when team members are remote. In any case, you will have to work more diligently to overcome the barriers created by distributed teams by taking the following steps:

For other techniques, see https://techbeacon.com/app-dev-testing/distributed-agile-teams-8-hacksmake-them-work.

• Help the team to self-organize, rather than try to solve problems for them.
• Invest in the team’s growth with on-site collaboration sessions (at least once a year; quarterly is more desirable). Include activities focused on getting to know each other, establishing clear working agreements, aligning around product vision and understanding customers, and accomplishing shared goals together.
• Invest in communication and collaboration tools (e.g., video communication, interactive whiteboards).

From the "Essential Scrum" book: 

Sometimes low attendance happens because it is inconvenient for remote participants to join by phone or video conferencing. If remote participants find attending the retrospective inconvenient because of when it is scheduled, consider changing or rotating the time so that no single location is always inconvenienced. If it is inconvenient because it is just hard to participate remotely, reconsider the current telecom infrastructure and how the exercises are being conducted to better incorporate remote participants.

First let me describe the team. Our company is based in The Netherlands. Here we have 1 Senior Developer, a Functional Designer, a PO, a SM (me) and some tester (mainly for UAT). In Mexico we have a Senior Developer, 2 Medior Developers and a dedicated tester (I&T). We are still all working from home, so pretty much all the events are online.

What forces lead to this team structure in the first place? It sounds more like something that has been imposed by others rather than the outcome of any self-organization.

A Scrum Master ought to be good at wondering about the things they see. You are not there just to dig folk out of a hole. If the company has indeed "started working with Scrum", how is self-organization being promoted and are the right foundations for this being laid?

Hi,

Thanks for the quick respons, this is helpful. 

What forces lead to this team structure in the first place? It sounds more like something that has been imposed by others rather than the outcome of any self-organization

This is a valid question. To be honest, the team is constructed in the exact same way as it was before we started Scrum. We just assigned a PO and SM and that was it. We are recruiting an extra developer now. This looks like a good reason to let the team reorganize itself. 

• Help the team to self-organize, rather than try to solve problems for them.
• Invest in the team’s growth with on-site collaboration sessions (at least once a year; quarterly is more desirable). Include activities focused on getting to know each other, establishing clear working agreements, aligning around product vision and understanding customers, and accomplishing shared goals together.
• Invest in communication and collaboration tools (e.g., video communication, interactive whiteboards).

Good points. I tend to be a problem solver, instead of letting the team fix it themselves. I can fix that myself. The 2nd point is harder. In Holland it looks like we can go back to the office soon, but in Mexico this is not the case. I am already experimenting with the 3th, but so far the respons was "meh". But I will continue experimenting.

the team is constructed in the exact same way as it was before we started Scrum

Different time zones is definitely a challenge to start with Scrum at first place. To me, the geographical cultural gaps will be faded away after some sprints as any new team will go through 'storming' phase when formed, but i am surprised why this is an issue if the team members are same as before. 

re ordering Scrum events to cope up with timing is not good solution as they are in that order for reason. To build the team collaboration, You can try some team events or just have some short team games before retro something like that.

If the planning is taking time. See what activities can be 'Ready' before the planning like refinement, priority and sizing can be completed before planning. 

You can think of doing a Scrum basic training to team if you think the team is not clear with the rules before playing the game !.