5 Patterns for Effective Communication in Agile Teams
The way we communicate is the single most important skillset employers look for when hiring. It has a significant impact on cost, productivity, team morale, and employee retention in the workplace. A study conducted by The Economist shows that problems in communication often delay project completion, lead to low morale and missed goals, and can result in a loss of sales.
With that in mind, it becomes all the more important to identify these gaps in communication when working with agile teams that have different roles, such as project managers, developers, testers, business analysts, scrum masters, and architects. Each role has different responsibilities, and these individuals develop their own mental models and patterns of communication.
The same problems we have had with communication the past several decades exist even now. For example, have you ever been in any of the following situations:
- You find a bug, but the developer does not listen to what you have to say and ignores you?
- You are handling a remote team located outside the country and find it hard to collaborate, although you give them all the resources they need for proper communication and status updates?
- Your stakeholders ask you about the status of the project in spite of you reporting the status periodically?
If you answered YES to any of the above questions, then you are not alone. These are common, recurring problems in agile teams. The good news is we have ways to mitigate these problems beforehand so you can take corrective measures in the workplace.
Different Communication Patterns
The key to improving communication in agile teams is to recognize these five communication patterns.
Body language and tone of voice are important parts of our daily communication. In 1971, Albert Mehrabian, a researcher on non-verbal communication came up with the “7%-38%-55%” rule, which became popular worldwide and still remains relevant.
He found that words account for 7%, tone of voice accounts for 38%, and body language accounts for 55% of our daily communication. This means an astounding 93% of our daily communication is non-verbal, and it significantly affects our behavior in the workplace.
This being said, it is important to pay attention to non-verbal cues among people in teams, especially when it comes to developer and tester communication. There are knowledge gaps in the way they communicate with each other, but the problems often initially stem from bad body language and tone of voice.
For example, there are situations when developers assume the testers have the same level of technical expertise as they do while explaining changes in code during code reviews. When the tester asks a question that is quite obvious to the developer, the developer may frown, raise his eyebrows, or shake his head indicating his belief in the question being simple or invalid, causing immediate friction between them.
This leads to the tester not asking the developer future questions out of fear of being belittled or reprimanded for not having the same level of technical expertise. This is also one of the major reasons why some developers do not get along with testers.
We need to pay close attention to these non-verbal cues, as they become disruptive in the long run. Some ways to improve non-verbal communication would be to:
- give people the chance to express their opinions.
- show interest in the discussion.
- maintain proper eye contact and body posture when a person is speaking to you.
- be engaging.
- pay attention to gestures performed with your hands, face, and body.
- respect other people’s personal space.
- be mindful of your tone of voice; especially in a public setting with a lot of people.
Another important part of non-verbal communication is active listening. Being a good listener is an art. Quite often, we fail to hear people out by not giving them the opportunity to speak or by interrupting them midway in between a conversation.
For example, say there is a task to compare data between two files. We could convene a meeting and talk about different solutions to this problem. These could range from creating a utility to perform this task, or importing the data into a database and then using different SQL commands to do the necessary validation. This task could take hours or days to initially perform.
During this discussion, if one of the developers has a simpler solution to this problem, where he/she could use a data comparison utility and could perform this task in minutes, imagine the amount of time and effort this could save!
However, if this person did not get a chance to share their thoughts and was constantly interrupted, then ideas like this will never come out in the open. As a result, teams may become a lot less productive.
So, let’s make sure we listen to different conversations. As Winston Churchill purportedly once said, “Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen.”
In the current era where agile teams are diverse with people from different regions, cultures, and backgrounds, it becomes all the more important to recognize differences in intercultural communication among individuals and teams. This is especially true with verbal, as well as written, communication.
When it comes to verbal communication, different people use different phrases and words when communicating in teams. Some phrases we use in one region may be totally foreign to people from other regions.
For example, when we say “Let’s pull the plug on that project,” a person who comes from a different cultural background may not understand the meaning of this phrase, and this could be open to different interpretations.
Similarly, when working with remote teams and setting deadlines on tasks, people from certain regions may agree to them, although they know the deadline is unrealistic.
This is again due to the cultural difference where people in some regions are afraid to ask questions or push back on deadlines. During these situations, it helps to reiterate your point, request the other person to summarize their understanding of the conversation, and ask them if there are any questions. Doing this small extra step goes a long way in mitigating problems in advance.
As for written communication, it is a big part of team communication as well. Email is on the top of that list. Research shows that globally a staggering 269 billion emails are sent each day. It’s estimated that by the end of 2021, over 319 billion emails will be sent each day, and there will be 4.1 billion email users—that’s over half the entire world’s population.
This being the case, quite often people from different regions use different words and phrases when typing documents and emails. This often causes misinterpretation of what is being said.
For example, a person from a different country may use a sentence such as “I have intimated to the team to add the requirement in the story” instead of saying “I have informed the team to add the requirement to the story.”
Similarly, not mentioning time zones is a huge cause of confusion when trying to schedule meetings or set deadlines for tasks. When we mention a time, say 9 pm, it is crucial to mention whether it is 9 pm CST, PST, or EST, and it becomes all the more important when working with distributed teams in different countries.
In his book When Cultures Collide, Richard Lewis puts forth the Lewis Model, classifying people from different regions into three types: linear-active, multi-active, and reactive.
Based on this classification, people react, behave, and think differently depending on where they are from.
Recognizing these differences will help individuals better collaborate with each other and work as one single unit. In addition, some simple social skills will help developers and testers to adapt to any environment.
Setting Expectations, Goals, and Deadlines
When working on a story, the whole team needs to know what the requirements are, who will be developing and testing it, how much effort is needed to complete the story, when the story needs to be completed, and what feature it maps toward to get better visibility on why they are developing it in the first place. Without all of this information, there will be a lot of misinterpretation and gaps in expected outcomes.
Having unclear goals is also one of the common problems in agile teams, leading them to feel stressed and unmotivated. To mitigate these problems, we need to set clear expectations on the goals and outcomes of a particular task. During this entire process, it is important to motivate and develop the person to reach their peak potential. This constant engagement with the team members is crucial and can make a huge difference.
Effective Feedback Loops
Communicating timely feedback is crucial to the success of agile teams. This applies for individual and team feedback. Improving individual feedback can be achieved in the following two ways:
- Proactive feedback. This is when an individual proactively requests feedback from a trusted peer or colleague on how he/she performed a particular task. It could be as simple as you asking questions such as “Did I do this right?” or “Could I have done something better?”
- Reactive feedback. This is when a peer or colleague gives you feedback based on something you did. It could be feedback such as “It was great what you told us, but next time we only need to hear X,Y, and Z” or “This approach seems to work better, what do you think?”
To improve team feedback, we need to ensure we have retrospective meetings as part of our sprints to discuss what worked and what did not.
Problems faced by teams should be discussed openly, and we need to collectively come up with solutions to them. For each solution discussed, an individual from the team needs to be assigned to the task to follow up on those items. This helps to give the teams a feeling of empowerment and helps them work as one single unit.
Use of Safety Language
In an agile environment, teams sit together, collaborate with each other, and work on multiple tasks, usually all at once. This is the reality.
In such environments, there are situations where we are forced to commit to timelines with little time to think, where we need to stop our current task and work on other tasks which are a higher priority to the team and other stakeholders, or where we may be in meetings and assigned a task based on the discussion that we know may not be completed on time due to other priorities.
During these instances, it helps to use safety language to ensure we don’t succumb to pressure and to ensure we continue to be productive.
This is a concept where we phrase our sentences carefully when replying to people without being exact. We use phrases like these:
- “Could I do this after I complete this task?”
- “It might not work under these circumstances.”
- “You may be right.”
- “I might disagree with that.”
- “My experience has been…”
So, the next time your project manager asks you for a timeline for the completion of a particular task, pause and use safety language to prevent digging yourself into a hole. A few seconds’ worth of carefully selected words can prevent a lot of problems later.
Become an Effective Communicator
The same problems in communication that have existed for the past several decades still hold true in current agile environments. It is about time we recognize the communication patterns highlighted in this article and start taking corrective measures.
This will help teams collaborate better and work as one single unit. As a result, there will be an increase in productivity, team morale, and job satisfaction. As Tony Robbins once said, “To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others.”