Communication in projects and teams

First posted in Intelligent Hack’s blog

Joe woke up, and while he took breakfast, some of the ideas that surged from the last team retrospective returned, flicking around his head. As a Scrum Master, he was highly motivated; those long-ago blocking issues were solved now. The next planning session, only 60 minutes ahead, will allow him to present to everyone some tremendous changes both in the team and the project.

The six-member team had committed to reversing the alarming situation in which the project was. Joe’s smile persisted even after finding out by chance that this Monday, Martin —the experienced UI designer— took the day off. As the daily starts, Juliette points out that what someone reported as finished was indeed a proof of concept, and it would take only 1 or 2 more days to polish it into a production-ready solution. Amir asked why nobody answered the email about the changes requested by the client.

Breakfast was not long ago, and the whole scenario changed as, one at a time, the small or medium-sized team explained why reality diverged that much from what everyone seemed to agree the week before. Once again, the team was out of sync, tasks were moved back to the on-progress state, and Joe was… well, not in his best mood anymore.

What is there to communicate in dev teams

The client communicates the needs, which the team must interpret in a technical context (what and how to do it) and in an administrative context (when to do it and how relevant it is). As one can imagine, flaws in the translation from the client’s language to the technical requirements and then to management reports that go back to the client can delay and even make the project fail.

Developers need to communicate among themselves, so envisioning and implementing a solution becomes collaborative, allowing each member’s personal experience to maximize the team’s results.

Documentation is not only intended for external people and as a requisite. Still, it can also be seen as a one-way communication channel with the team in the future time, as members need to recall why the team did things in a certain way.

For teams to keep synced, it is crucial to share availability time and expectations. These pieces of information are essential for maintaining a healthy dynamic, even more on remote teams.

How teams are composed

Members have different personalities, past experiences, and a set of both soft and hard skills. Diversity brings all kinds of opportunities, but there are some drawbacks: what’s obvious and common sense for one may not be the same for others.

Many remote teams are composed of people from different time zones, and even if not, it is common for a member to use a slotted schedule assigning the time resource to various activities. The thing is that finding out available time to meet requires effort, and decisions are delayed waiting for the meeting to happen.

Using the right channel

Time is an essential resource, and when the wrong channel is used, the recipient of a message can float over its content and not only waste time but also fail to act timely. Communication requiring responses should state what and before when it should take place.

It is time for a cliché phrase: This meeting could have been an email. Written channels allow people to manage their time and prepare thoughtful answers. But the critical difference is not if the message is encoded in voice or characters; it is all about synchronous versus asynchronous communication.

Is it needed for everyone to focus their attention at the same time? What about all attendees waiting for one person to consider some things only to start elaborating an answer? It doesn’t matter if that happens in a physical room, video call, or chatroom. The odds are that for some periods, different people got lost in their thoughts. Traditional companies may introduce tools to keep track of what is said and decided, remote-first companies are forced to, and actually, it ends up being a great advantage.

Nevertheless, there are many situations where synchronous interactions are a better fit for solving problems. Voice conveys a deeper meaning than the mere words said; the fluctuations and pauses, among other elements, create a valuable context. Some topics even demand to Include body language to complete the communication experience.

Wrapping up

It doesn’t matter the methodology, team size, or project scope, bits of information need to be appropriately handled. That includes sharing and making it available timely, reducing ambiguity, and adding enough redundancy to avoid misunderstandings.

Developers need to understand what is expected from each task and each other, key roles need to know the status —detailed down to the specific needs of its role—, and the client needs to have a clear understanding of the product evolution.

Considering time zones, and according to what needs to be communicated or the degree of interaction, the communication may be sync or async. A team member can summarize a video call in writing afterward or kept as journal entries, so the information is easily searchable or if the results are to last and not short-lived.

As Brooks wrote in The Mythical Man-Month, “Question: How does a large software project get to be one year late? Answer: One day at a time!” misunderstanding and postponing catch-ups for the next day are two familiar sources of delays. That is why remote teams should eagerly counter vague events on the calendar and monitor time drains.

What can be done to prevent Joe from having another underperforming sprint and report receivers to trust the content fully?