How I experienced Scrum across 5 different time zones

How I experienced Scrum across 5 different time zones

Everything started after my adventure in Barcelona, I joined Dominion Marine Media now Boats Group  in 2013, I started working with the whole team from Palma de Mallorca, my main contact point was in UK where I moved afterwards, I’m not going to share here the whole story, I will focus on how we were working with 5 different time zones, the truth is that there are certain things I don’t remember too well, basically how exactly where the boards we were using and things like that, but I don’t think it’s too imporant.

So, how was the team distributed? as I said we had different locations with different amount of people in each location, we were more than 25 in total and locations were:

  • Palma de Mallorca, Spain (20:00)
  • Fareham, UK (19:00)
  • Norfolk, Virginia, USA (14:00)
  • Seattle, Washington, USA (11:00)
  • Vancouver, Canada (11:00)
  • San José, Costa Rica (13:00)

At the moment while I’m writing this post is 20:00 in Spain, I added the time of the other different locations so you can see the difference of hours.

How was my day?

I remember I was arriving at the office at something like 9 am, of course, there was no one from the other offices working, sometimes I could chat with a colleague from Vancouver as the time difference is huge, basically I was about to start the day and they were about to finish the day.

In Fareham, we were 5 team members of the Scrum team, we were 4 developers(James, Aaron, Hugh and myself) and one QA(Hannan)there were more people but I only counted the people that were part of the Scrum team(Dids, I still remember you!).

We were doing 1 week sprints.


Our Stand-up was at 10 am, we were going to a meeting room and quickly we were going through the Stand-Up.

Here is when there is the first surprise, it wasn’t something that happened every day but sometimes our colleagues from Norfolk were joining our Stand-Up, I remember Candy joining, or JP, it was really nice to see people joining the Stand-Up from other locations, it was always a nice surprise, I remember that when it happened was like an extra shot of good mood in the morning.

We also were doing the same, sometimes we also were joining other location Stand-Ups, it was imporant because some team members were sharing tasks, I will explain this later.


The retrospective was something that we were doing all together, all locations together, of course, was not an easy meeting, lot of people and without a moderator would have been something hard to manage.

First of all, we were using Jira o track our retros, when you work with people in different locations it is just not possible to do retrospectives as we all would like to, using the walls, colored pens, post-its, flipcharts, etc, it’s just logistically not possible. There are ways to run distributed retros with online tools, actually, at the moment I’m using retrium, but there was no retrium at the moment.

We all were expecting each other to some homework, during the week we were raising topics we wanted to discuss, I was free to write a task during the week that would appear in our retrospective board, and then, Jira has a voting system that we were using to come up with the most voted topics.

Those topics at the end were the ones we were discussing first, and for actions points and everything else we were using all features that Jira offers, like comments, labels, or whatever you like to use.

To sum up, during the week we were creating topics for the retro as tasks, that would appear in our retrospective board, and then we had the chance to vote the ones we liked more.

Sprint Planning

This one was spectacular, really, after some years now thinking about it, I’m really impressed of how we were able to handle this ceremony, we were also doing the sprint planning all together at the same time, rmember 5 time zones.

Context is:

  • The company had as the moment basically 3 different websites, and at the same time we were building the same websites but from scratch, the typical situation of legacy code and a team building the new websites with new technologies and cool stuff.

The board we were using for the planning was looking something like this

there were basically 4 buckets.

  • Legacy: contained all tasks related to the legacy portals, the ones online at the moment, maintenance stuff, small features, bug fixing, and similar things, not really big things going on.
  • New Portal 1, 2, 3: For each new portal the features needed, maybe some bugs, etc.

This Sprint planning was long, like the retro, this ceremony was long and it was needed because of the amount of people and amount of work we had to plan, we all accepted it because we knew that the rest of the week would be just working, actually I remember that my focus was quite good during the week.

I remember the PO explaining us the “why” of the tasks, the reasoning behind them, the goal was that everyone could understand why we were about to pick up a tasks, yes pick up the task, no one was telling us you do this one and you that, we were using a volunteer system. If you felt like doing a task then you just needed to say “hey! I would like to work on this task” and done, the task was assigned to you, also, you could show interest, I mean, if two people were interested in the same task that was not a problem, was a perfect situation to pair.

We had a reserved number of people to work in each bucket, we always had to reserve some people for legacy portals and other people for the new potals, but the good thing was that in every sprint the people were changing. I remember that for certain bug fixes or maintenance tasks, to be working on the legacy was not that pleasant, we did not have Vagrant machines for all environments and sometimes you were spending more time trying to set up the environment than fixing the bug, this was quite frustrating sometimes.

This is something we had to accept and we were helping each other when this was needed.

We were going through the buckets and when the team felt that we had enough to do then we stopped, you see felt in bold, and it is right, there was no velocity or similiar things, we were expressing ourselves trying to be honest as possible with the expectations we were giving to the PO or stakeholders.

Having enough to do does not mean everyone has one task to do, in every sprint, there were people who did not have anything assigned, and this was magic, why? because we had something in favor, the time zones! and at the same time a big challenge.

So, I put you in the situation, it’s 4 pm and I’m about to start a task, there is a colleague in Vancouver who showed interest in pair with me with the task, and in Vancouver was 8 or 9 am.

First of all:

  • Let’s meet, let’s have a chat and see what we need to do, let’s use this hour I have before going home to catch up.
  • Why did we need to catch up? because the following day I will continue the task.

Yes, you have read well, we were taking profit of the time zones to have the tasks almost 24h in progress, when I was going home he was starting the task, and when my colleague in Vancouver was going home I was arriving at the office so I would continue.

Of course this was not that easy, this implied high commitment on being explicit with comments in the tasks, with the status, with the last update, there was the risk of blocking each other during like 6 or 7 hours, which was not something we wanted, but that’s life and sometimes it happened.

Sprint Review

We were also meeting all together, for us in the UK, all the meetings were starting always at 3 pm, 4 pm, all the developers were present in the sprint review, the PO’s, stakeholders, and actually whoever that wanted to participate.

How it was working was like this, if in my case I would have finished a feature o fixed a bug, I was the one who had to prepare the demo, the PO explained everyone what was the task and then, myself, who developed the task or fixed the bug I was so proud to share in front of everyone how I achieved the goal, that was really really nice.

Dominion Marine Media and Marius De Beer were a life changer

Yes, the company that gave me the chance to join, Tyler, James, Aaron, Dids, Candy, JP, Guillermo, Martin, Paul, Seanna, Oscar, Ignacio, Carlos, Vicky, Drake, Gareth, Heath and many many others, impressive professionals, you all made me grow a lot and I learned a lot from you, and luckily, thanks yo Candy we are still in contact even if I don’t talk too much in our Slack group! Thank you Candy for inviting me.

Hannan, Marius! who could I forget you.

Hannan because she was always very supportive personal and professional, a person who knows how to listen, and knows how to make you feel better.

And Marius who shared with me a lot of knowledge, taught me a lot of new concepts, listened and guided me when I started in this “Agile” world I’m in now, thank you a lot for your wisdom, I will never forget and I hope to you meet you again at some point in my life.

This post made me remember many good things, I enjoyed a lot, and if you want to know more about the experience, just let me know.


Join the discussion

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Marcos Pacheco


Instagram has returned empty data. Please authorize your Instagram account in the plugin settings .

Please note

This is a widgetized sidebar area and you can place any widget here, as you would with the classic WordPress sidebar.