Worldwide Agile Team

Antoine Duprat
Linagora Engineering
2 min readJan 4, 2017

--

Once upon a time, two Agile teams working on the same project; one in France in Lyon and the other in Vietnam in Hanoï.

Then, we decided to work together in a single team.

Time Zones & Daily

Lyon is at French time zone, currently UTC + 1; and Hanoï is at Vietnamese time zone, currently UTC + 7.

Our first decision was to use a common hour reference: UTC
By this way, every meetings we have are in UTC and we will never suffer again from headache with time conversion.

Then we had to face a problem regarding the mandatory daily meeting.

We took face to face the two different time zones, and then decided to do a daily for the whole team at 8am UTC.
That’s the beginning of the day for the French team, and half of the day for the Vietnamese one. About the content each member tell to the other what he has done during the previous 24 hours.

Pairing

As an agile team, we love to do pair programming; but we are facing connection issues, and it’s uncomfortable to loose some time with such problems.

So we decided to do pairing only with person on the same time zone.
We will try in the future sprints to test some tools in order to get rid of that.

Then on some complexe issues, we are able to work with two pairs of pair programmers, e.g.:
Vietnamese team start pairing on an issue, then it’s the end of the working day for them. They just explain the other team about their progression, and the French team continues the pairing on this issue.
This allows us to have 4 persons on the same issue, in only one day. It’s very helpful when you can’t parallelize some tasks.

Issues Lifecycle

We hate to take a new task when one is in progress and not done.

So, we decided to take care of open pull requests first, before than working on another task.

This means, taking care of comments of the opened pull requests; and continue the job if the pull request was partial.

Our first reaction on this part is that it’s a real cool habit:
1. pull requests were easier to read, as lot of team members work on it; and the global quality of the pull requests was really great
2. every members of the team owns the code

To conclude

This was an excellent experience to work with persons from other time zones. We will continue that way, and try to enhance some points.

The next step will be to have more different time zones, then we will think again on our Agile methods.

--

--