Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia. Read Statement
Ceremonies in Scrum teams with team members in different timezones
In the company I work for we have the scrum team formed by people in totally different timezones. Let's say 3 team members are in Australia, some in Brazil and some in US. In this case how you guys handle the ceremonies, like Sprint Planning? Team members would have to work till late in one timezone to have everyone together? (seems not fair)... do we split the sprint planning in two?
It would be great if you can share your thoughts.
Your help is really appreciated!!
Are team members collaborating effectively in terms of their day-to-day work?
Have they found a way to manage their dislocation problem during the Sprint, when they are jointly developing an increment?
I'll start with this: I don't think there is a "one size fits all" answer for this. Every team is different and the best plan of action for this may be to ask your team what they would like to see in order to make this work. Have them form a working agreement so that everyone is on the same page going forward.
There are a lot of virtual scrum tools available for these situations. A buddy of mine was a Scrum Master for a large airline company that had developers all across the globe and they dealt with this issue by utilizing the virtual tools. If you do a google/bing search for Virtual Scrum Tools, you'll find a lot. The one he liked the most was Status Hero. This allowed the dev team members to work at their leisure but still collaborate on a single platform.
Sprint Planning and Retrospective gets a bit tougher, obviously. Using your example, 3 members in Australia, some in Brazil and some in US, let's say it's 3 in each spot for a team of 9. Let's say US team is Central Time, that puts your Brazil team 2 hours ahead, that's not too bad and easy to work around. Australia, however, is some 16 hours ahead of US (It's 10:30 AM Thursday in Texas as I write this but it's 2:30 AM on Friday in Australia); that's where the challenge lies. You could have it so Australia members would have really early mornings in order to meet the Sprint Planning and Retro but every 3rd sprint, have the timing work better for the Australia members. That way they are not always getting the short stick. I think that would be a good compromise. Conversely, if there was only 1 member that was in Australia but everyone else was in the same or close time zone; I would lean more towards the 1 person suffering with a long night or early morning rather than make 8 people suffer on account of 1.
Distance/remote teams do present some unique challenges, particularly when different time zones are involved. What I find usually happens is one or two resources tend to get "pushed out." What I mean is that while I agree with Curtis’s idea that it’s better to inconvenience one member of the team than offset the entire team, instead of changing meeting times I’ve seen them participate separate from the rituals. For example, they may answer the "three questions" via email rather than during the Daily Scrum, and work-in-progress or similar collaboration may become more reliant on digital team tools, rather than in-person participation.
This isn't great, but it is manageable. The downside is that it doesn’t really build up a cohesive team, so you may not see sprint velocity accelerate as much with time as you would with an entirely co-located team. Perhaps a non-scrum flavor of agile might be better for this?
Jason, absolutely it's a worry that the offset member feels left out. The Daily Scrum is easy to deal with because of all the virtual tools available. The problem comes for the Planning, Review, and Retro where it is much more a full team/all hands on deck ceremony.
Ultimately, were I put in this situation, I would put it to the team to decide. I mean after all, our job as Scrum Master is to support the team as much as possible. Therefore, the best people to make this decision is the team.
Thanks guys for your input... I had read your inputs but just found out I haven't thanked... you guys shared valuable thoughts :-)... thanks once again.
I am also in a similar situation as a SM with teams in multiple time zones that’s fairly new to Scrum: US, Ireland and India. We have been successful with most ceremonies however the retrospective has been the most challenging to implement. Suggestions??
In each Scrum Team, are the Development Team members all co-located? You don't mention problems with Daily Scrums, which only Development Team members need to attend.
What are you doing to make the other ceremonies work with the time differences? Why couldn't that be implemented for the retro? Have you asked your team what they would prefer?
Use this website to see just how off the time of day is comparatively to each location: www.worldtimebuddy.com
Avonia, there was a recent Scrum Alliance webinar on this very subject:
The developers are located in US and India (10.5 time difference) and our testers are located in Ireland; I am also located in the US. The daily scrums are held 8:30 am EST via Skype which seems to work for most with the team located in India calling in from home after their work day. The other ceremonies are scheduled early as possible EST however after the Sprint Review the team is just too exhausted to continue.
Thanks Timothy for the Webinar, this has definitely been a challenge for the team.
If the team are delivering inspectable work throughout the Sprint, then the review of that work may happen on an ongoing basis. This could be more efficient, as well as making an end-of-Sprint Review less onerous. In other words the review of work does not have to be deferred, along with the associated risk, to the end of the Sprint. This may enable better focus on Sprint Retrospective matters.
During the Retrospective, the team should be clear and transparent in their assessment of how well their geographical dislocation is working out for them. Co-location is valued for good reason in agile practice. Even if they have no power to do anything about it, that rationale for co-location does not go away, and teams must have the courage to expose any related issues.
Thanks Ian for you valued input!