Well, those are all good points. Really. However, all of those are remediable. Nowadays you cannot say that distributed teams don’t work. You need to make it work! That is the reality of the world.

But enough of whys, let’s get to how. How can we remediate all those problems? Or even avoid them? How can we be agile without ever seeing each other?

Communicate, talk, say, share!

The first thing that you need to think about when working with distributed teams is communication. And since it is already difficult to improve it in a colocated team, you may imagine that the difficulty adjusting it in a distributed team is even higher, right? Not necessarily, actually. Those are different environments, with different challenges. And this difference is the key.

If you try to adapt what you do in a colocated team to use it in a distributed one, you’ll likely fail. Things like talking to someone at their desk is not the same as a private message on a channel, for example. In the first example, other people can hear you and enter the conversation if needed. A private message is like going to a sound-proof room with your colleague and talking about something. Therefore, keep an open mind and try new things. Below I list four things that you could change to improve your communication.

No more poking

Zach Holman calls that “remote first”. The idea is that you need to prioritize the use of asynchronous communication tools when in a distributed team. That means that those poking-and-talking meetings will be converted into written discussions, or video conferences, using your preferred communication tool.

“Oh, but we already use Slack!”

It is not about using it; it is prioritizing its use. And that is extremely difficult. Let’s say that you have five people on site and two offshore. Those onsite need to communicate every minimally important thing through the communication tool, with the preference for open channels and not private chats. Otherwise, you’ll develop an information silo, will decrease trust between people from different locations, etc.

Online meetings? Really?

Ceremonies and meetings are usually a dreadful experience when online, and there’s not much we can do about that… After all, the internet connection fails, you need to repeat everything ten times, the audio quality is never perfect, and it is just annoying to not interact with people.

However, there are some things that you can do to improve that experience. You need to have the right tools, and a clear goal for the meeting, you’ll find more on that in this blog post.

Besides that, each person should preferably be in their own machine, even if you have some people together in the same building. In my experience, people that are together in a room tend to share information while the microphone is muted. However, that information could be useful to the offshore team.

But one thing that I want to demystify is the necessity of meetings.

Please, only have meetings if you need them! And that is something to consider even in a colocated team. Most people start working with Scrum, Kanban or whatever methodology that comes with their set of necessary ceremonies. You need to think, and re-think, all the meetings objectives and check if they are necessary for your context. And if they are, check if all invited people are required. Don’t waste people’s time with unnecessary meetings.

But I’m in LA and she is in China!

If you have distributed teams in just one time zone, you are a lucky one. However, people usually have distributed teams across the entire world, going from 1 to sometimes 12 hours of difference. And each team needs to adapt their process to make sure that everyone receives the same information and participates in decisions over the future of the project.

The important point here is to stay as a team and try to have at least part of the day (or of the week if the time zones are too different), like an hour, that everyone is online. With that synchronized time you can put everyone on the same page.

Fly!

You’ll need to meet in person eventually. Not frequently though. Once a month, or even once a year, might be good enough. The idea of this encounter is to humanize people since we will often only interact with faces and texts on screen. That improves trust among everyone and brings the team back together. Think of it as a reset for group relationship. Bringing everyone together will relieve stress and improve interactions.

Different places, different cultures

Culture is a crucial point to consider when having distributed teams. We often expect people to behave as similarly as we would in the same circumstances, and it can break our expectations, hence, causing stress. I’ll detail two points that I often face in distributed teams that could help you.

Can I invite everyone to Carnival?

Whether you are hiring someone that will work remotely or are entering a team that has people from other countries, you need first to understand the countries’ differences. I’d suggest a comprehensive analysis of the country’s culture, how people usually behave when facing difficulties, how they say things (if directly or indirectly), what are their working times and related subjects. With all that information, you can manage your expectations and change your actions accordingly.

Hola, how você esta?

That is a very tough subject to address. What if you are working with team members that don’t speak the same language? Well, we’ve been there, and the answer is pretty simple: you need to communicate somehow, and it doesn’t matter how. Sometimes we opt for a common language, Esperanto most of the time (just kidding), and sometimes we try to learn the other person’s language if it is possible, like Spanish. But it doesn’t matter if you speak English, Latin or whatever. What is important is that, at the end of the day, you understood each other.

Just give them this bunch of tasks!

Especially when you have part of a team distributed in another region, it is common to have them as a “black-box team.” It is important to avoid scenarios in which you select demands for that team, instead of having the stories being pulled by whoever is free at the time. It is better not to have this kind of differentiation.

Ok, but what tools should I use?!

Before surrendering yourself to products that claim to be the silver-bullet for distributed teams, think about your process and how you can improve it. Then, if you need a tool, you’ll know what to search for.

However, if you want to know some of the tools you may need, we have an already extensive guide in this blog post. To make it easier for you, I’ll just mention some of the tools we use.

• A video conference tool, like Hangouts with a microphone handler like Shoosh
• An asynchronous conversation tool, like Slack
• A place to put findings and documents, like Google Drive and/or Basecamp
• A wiki like Confluence may also be useful
• For your Kanban board, you may use something simpler like Trello or something with more options (but less customizable), like Jira.

Conclusion

The takeaway from this post is to improve communication and have empathy to understand the other. It is all about the process, not the tools you use.

I presented a huge number of things to do in a distributed team. Ergo, if you are seeking perfection you would need all of them, but to be better than yesterday, you just need to implement one at a time.

Do you agree with our approach? Leave your thoughts below!

The post How to work with distributed teams first appeared on Plataformatec Blog.

What most serializers do with Date and DateTime values is to use the ISO8601 standard. For example:

# Date format
2011-07-14

# DateTime format
2011-07-14T19:43:37+0100

However, you should be aware that information is lost when you use the Date format. That happens because a Date value might differ between different timezones. Let me give you an example:

• a request was issued at 2011-07-14 T01:00:00Z (UTC) from Brazil (UTC-0300) to a service in UTC
• if the time the request was created is exposed as a Date, it would return the value as 2011-07-14
• but from the client’s perspective in Brazil, the correct date is 2011-07-13, since at the moment of that request was issued, the local time in Brazil was 2011-07-13 T22:00:00-0300

If this information is used only inside your app, within the same timezone, you would have no problems. But, if you need to make this information available through a public API, one of your API’s consumers might recover an incorrect value.

So, from this experience, any date value that will be shared and consumed by different clients should be represented as date time with explicit timezone or using the Unix time format. That way, it is up to the client to treat the data properly.

Here is an example of an API that returns a subscription period in the right way:

{
  period_start_date: 1409175049, # Unix time
  period_end_date: 2014-09-27T18:30:49-0300 # ISO8601
}

# Time.at(1409175049)
# DateTime.parse(“2014-09-27T18:30:49-0300”)

The options above have the advantage that both are unambiguous and sortable. You may choose between one or another based on the fact that the timezone option is easier for human comprehension. But remember that Timezones are a presentation-layer problem, so if you just need to pass data around, Unix time is preferable.

Have you ever had this serialization problem or any other that caused information to be lost? If you have questions or any experience to share, please, leave a comment below.

The post How to serialize Date and DateTime to JSON without losing information first appeared on Plataformatec Blog.