True Collaboration: Remote challenges – Communication

When we attempt to make Agile work with distributed teams we come across a few interesting challenges. Agile product development methods are very people centric. They depend on high quality interactions and mindful collaboration between all invested parties. Collaboration in turn depend heavily on communication. I find it valuable to spend some time talking about this stuff with the teams, as choosing the right tool for the right message can be a challenge. And it is with communication as it is with every other aspect of team work: it’s always a good idea to talk about expectations.

A good starting point could be a brief chat about the difference between synchronous and asynchronous communication.

Synchronous communication is what happens between two or more parties at the same time.This is where everyone involved simultaneously talk, listen and think. A few examples: A meeting. A telephone conversation. A group chat.

Asynchronous communication is where a message is sent (and received) and a reply will be given at a later time. Examples: E-mail, SMS – that sort of thing.

Synchronous communication is in a sense far more demanding, as we’re expected to do a lot of stuff simultaneously. There are things we can do to relieve some of the cognitive load, and this is one of the reasons why I encourage everyone to be mindful of basic IDOARRT meeting design. It’s particularly useful to be very clear about what kind of meeting we’re having. There’s a huge difference between a meeting where we share information and where we make decisions.

The challenges associated with synchronous communication are naturally amplified as soon as we’re not in the same room together. Actually, I would go so far as to say that it can be a good idea to think twice about having remote synchronous meetings. The potential for wasting people’s time is huge!

The major difficulty associated with Asynchronous communication is that if the reply is not instantaneous, and will arrive at a later time, when exactly is that time? This is why a very brief talk regarding expectations can be helpful. If it’s perfectly normal for you to answer your e-mails once a week, and I expect an answer within eight hours, we might get rather annoyed with each other.

When we chose this form of communication we leave each other room to think, and to respond at a suitable time. This is of course very valuable. But there’s a problem: when we communicate synchronically we have the option to clarify potential misunderstandings in real time. When we communicate asynchronically – that valuable time we get where we can think, is time where we are left to our own devices to potentially think very, very wrong. So when we opt for an asynchronic communication channel it’s a very good idea to practice clear and concise writing.

In a previous post I described a Team Point of Departure. A related add-on exercise that can be valuable is to map your communication channels to the content and nature of your communication. I’ve built this module on top of the old Eisenhower Priority Matrix

This is how you do it:

1. Have the team put together a list of all the various tools and formats the team uses in order to communicate.
   Examples: E-mail, Slack, face-to-face, stand up meetings, planning meetings, Skype etc…
2. Draw the Eisenhower Matrix on a white board or paper.
3. Have the team brainstorm examples of stuff we communicate and place in each quadrant. Use Post It’s. One item per Post It. The question is purposely vague. Leave it that way and see what happens. Examples: Status reports, bug reports, questions about X, information about Y, funny GIF’s.
4. Take a step back and talk about the result. Spend some time moving stuff around if necessary, until you have a good starting point that everyone can buy into. The list doesn’t have to be exhaustive.
5. Now, return to the list of tools you created initially. Map the tools and formats you’re currently using to the content of your communication. Ask yourselves: Is what we’re doing now working well for us? Would we benefit from restricting some communication to one channel or another? Is this tool or channel meeting our needs? What would be better?
6. Once you have the tools and formats mapped – if necessary – spend some time talking about expectations with regards to response times, availability and such. You can map this both internally for the team, and externally for the people that interact with the team.

If you find reason to, don’t hesitate to clarify the Team expectations on people surrounding the team. As long as such feedback is delivered in a constructive manner, it usually works out fine.