Communication Bandwidth on Successful Projects

As developers, we like to believe that only raw data matters. And what is more raw than the written word? Does this mean that email is a more efficient communication mechanism than in-person meetings? Email contains just the raw words of our intent, right? The receiver can scan through looking for relevant content. Their computer can index and search our email. Why don’t we communicate everything in email? We’ve all experienced the miscommunication that can happen in email. So what are we missing?

The reality is that humans are social animals. We are attuned to many communication side channels - tone of voice; verbal pauses; facial expressions; body language. These side channels communicate additional information above and beyond the written (or spoken) word. What we are effectively doing with these side channels is increasing our communication bandwidth and when it comes to communication, more bandwidth is better. Just like increasing bandwidth in your computer network means pushing more bits of data per second through the pipe, you can do the same thing with your personal and team communications. Arranging some common forms of communication from lowest to highest bandwidth.

• One-way text (email/tweet/txt)
• Two-way text (IM)
• Voice
• Video
• Face-to-Face

As you go from low to high, the amount of information communicated per unit time increases and the likelihood of asking for clarification goes up. You’re much more likely to ask for clarification on an uncertain point when talking to someone than when you’re texting. Having to craft a reply creates a certain amount of impedance and if you’re fairly certain you know what the person is talking about, you won’t send that clarifying text or email. When talking, you’re much more likely to simply say back, “Let me see if I understand what you’re staying” and proceed to paraphrase your understanding of what they said.

Let’s look at daily stand up meetings as an example of high-bandwidth communication. The purpose of the daily stand up meetings is to keep team members apprised of progress on the project. Daily stand up meetings aren’t the only way to do this. Everyone could write daily status reports. Or the project manager could walk around asking everyone for a verbal update. Or team members could update a central progress report wiki. But most successful agile teams use daily stand up meetings. Why are daily stand up meetings more effective than the other techniques? It all has to do with communication bandwidth…

Let’s say a team member emails everyone, “I’m going to finish the enrollment feature on the website today.” Sounds great. No reason to doubt them. Now let’s say that they say exactly the same thing in a daily stand up meeting, but now you notice that they say it while avoiding eye contact with other team members and shuffling their feet? Most people can tell that the developer is quite uncertain about their ability to accomplish the task today. Same raw information, but you’re receiving additional information from the communication sideband of body language. If the developer instead said the same thing, but looks other team members in the eye and says it with confidence in their voice, other team members will feel more certain about the task being completed. (If the person has been saying the same thing for a week straight now, the team has a different issue to deal with – that of honesty and integrity in communication.)

Knowing why agile teams value daily stand up meetings also helps us compensate when face-to-face stand ups aren’t possible or feasible. Let’s say that we have a geographically dispersed team, video calls are going to have higher bandwidth than a voice call or emails. Similarly if the geographically dispersed team is centered in two different locations, it would be better to have two separate face-to-face meetings linked by video rather than everyone calling in separately via video conference. The team’s goal is to maximize efficient information exchange between team members as much as possible.

Daily stand up meetings aren’t the only way that agile teams leverage high bandwidth communications. Other examples include:

• Pair programming: two developers focused on solving a single problem
• Team rooms: immersing project members in team-related communications
• User stories: a reminder to have a conversation with a stakeholder
• Story walls or Kanban boards: surrounding the team in relevant project data

In each of these cases, successful agile teams use high bandwidth communication to facilitate understanding between team members and with other project stakeholders. Notice that story walls and Kanban boards are a form of non-verbal high bandwidth communication. Team members and stakeholders can quickly glance at the board and see the current status of their project. A well-placed board cannot help but be noticed often and frequently throughout the day. It is a constant visual reminder of what the team is doing and where it is at. It often becomes a focal point of conversation and acts as an information radiator about the project.

This isn’t to say that teams should avoid written communication, but use it when it’s appropriate. Written communication is more easily archived and searchable than verbal communication. Good written communication summarizes and condenses a lot of information into a more useful form. Written communication also decouples the availability of the sender and receiver. If you need a new server set up or need to confirm a meeting time, often a quick email is more efficient than standing outside someone’s office waiting for them to have a moment to talk to you. The lesson here is use the appropriate form of communication for the job at hand. And next time you’re having trouble understanding an email from a team member or project stakeholder, don’t hesitate to increase your communication bandwidth by picking up the phone or inviting them out for coffee…

About the Author

James Kovacs is an independent architect, developer, trainer, and jack-of-all-trades specializing in agile development using the .NET Framework. He is passionate about helping developers create flexible software using test-driven development (TDD), unit testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques.

Subscribe to the TeamPulse blog if you would like to receive similar articles in the future.