Agile in a long-distance relationship

Agile stands for building relationships- within the team, with the client. It even advocates working in one room, cooperating closely. But what if our beloved team member decides to move to Sri Lanka? Or the client found the perfect team for the project, just it happens to be situated three time-zones away? Should we give up? Should we just do something that doesn’t care about closeness, like the waterfall then (please don’t)?

With most relationships, the distance doesn’t help. They say that absence makes the heart grow fonder, but I guess that absence in a business setting is rarely helpful. But here’s the fact: most agile teams are distributed nowadays . 90% of the projects I was a part of were the distributed kind. So here I am, your agile relationship advisor, sharing our experiences with building agile long-distance relationships that thrived despite the physical distance. And then hopefully you’d be able to live happily ever and after. Or at least until the end of the maintenance period.

Communication

As communication forms the basis of the agile approach (and relationships), the fact that working in a distributed setting introduces multiple barriers in this area is very unfortunate. Here are the main problems we’ve encountered along the way and how we addressed them:

1. Language

Unless you’re lucky enough, the possibility is that in a distributed team/client setting, you won’t be using your mother language. Or it will be the other team members/client who will need to switch. That might come at a price of not being able to clearly formulate your thoughts and being misunderstood. The ideal solution to that would be to improve the language skills. But in the meantime the first step would be to acknowledge the problem and be empathetic. Rephrasing the most important parts of the conversation (i.e. “Just to make sure, what you are saying is….” or “So you just proposed that we should…”) is always helpful. Building a common glossary so you ensure that you talk about the same things makes it a lot easier as well.

2. Culture

By cultural differences I mean both the more noticeable as well as the subtle ones. Even among European countries you can encounter different ways of communicating. For example, in general Poles tend to talk in a more straightforward way, using less polite phrases like “would you be so kind and do this” than e.g. Germans do. Which might seem unfriendly but usually is not the case. Stay open and don’t assume ill will. Learn a few of the kind phrases that feel comfortable and natural to you and use them. If you’ve never had an interaction with someone from a given culture before, do the homework - they will appreciate it.

3. Time-zones

Time is non-negotiable, I’m afraid, and you can only work around it. While arranging meetings during the shared waking hours seems like a no-brainer, it’s good to remember to always specify what it means “ready by the end of the day” or “you’ll be able to test this tomorrow”.

Sharing is caring

In general, it’s good to make notes and share documents but in distributed teams it’s especially helpful. Having a shared Google Drive or Confluence that would gather all of the important documents is always a good idea. Write down the Definition of Done, create the aforementioned Glossary, add the notes from the meetings or the pictures from the team building events (if you fancy), whatever you want. Just share it.

Meetings

1. Standups, plannings

If your team or a client is in a remote location, most of your meetings will also need to take place remotely. In general, it’s best if everyone is connecting in the same way. If there’s a single person behind the keyboard on one side, it can be an excluding experience if on the other side there’s a shared camera and a room full of people. If you expect everyone to be engaged on the same democratic level, make sure that everyone joins on the same terms.

And do meet in person as much as it’s reasonably practicable, at least at the beginning of the project. We’re human beings after all and as we’re talking about building a relationship, never underestimate a physical presence.

2. Retrospectives

It’s easy to ignore the difficulties and misunderstandings when you’re in different locations. You won’t need to talk to each other after hanging up from the call. You won’t casually meet in the kitchen to learn that the other person, who wasn’t responding to your questions during the meeting, does not get much sleep lately because they got a puppy that’s having problems adjusting. Maybe a puppy like this (it’s Valentine’s day, you’re welcome):

Which is why I believe that Retrospectives are even more important in distributed teams. It’s best to use online tools for this purpose, either just a Google Spreadsheet or a dedicated tool like Miro.

Infrastructure

A good CI setting is valuable not only when working in a distributed project.

Same goes for an issue tracker - I made a whole post about how we use Jira at Bright but any issue tracker will do. As long as you’ll keep it up to date and as comprehensive as possible. If you cannot ask a Product Owner anything any time you like, the Acceptance Criteria are a very helpful source of truth. And an instant messaging tool - e-mails can be fussy. The fact that you can directly ask someone, almost as you would with a person sitting next to you is valuable.

In the end, it all comes down to a simple rule: communicate frequently, with honesty and empathy. Yes, in business relationships (as well). And while I won’t try to convince you to send Valentine’s day cards to all of the people you work with, the everyday acts mean more. Be kind to your team. No matter if you’re desks or miles apart.