I recently met Alistair Cockburn, a prominent agile methodologist, at a luncheon discussion session. I'd heard Alistair speak at an agile conference a few years ago, and I told him I often use his examples to help raise quality in teams. A favorite Alistair example of mine is people sharing a marker at a white board while discussing the project. Thanks to the cameras in my last three smartphones, I have hundreds of white board photos from these type of meetings.

A small group of people discuss, draw, confirm, share viewpoints and solidify their understanding of tasks, teams and technologies. This helps reduce misunderstandings, oversights, bias, incorrect assumptions, and raises the overall quality in the project deliverables. Alistair mentioned an article he'd had reviewed by Tom De Marco, a prominent project management and risk guru, who had commented “Communication is not like perfume.” He was arguing that communication is consistent across a team based on the relevant documentation. Studies since the mid 1990s have indicated the opposite: large teams developing software have communication breakdowns and create more bugs than small teams then spend considerable time fixing them. Linda Hayes wrote a Stickyminds article on this back in 2005.

Alistair said he had thought about De Marco’s statement and realized it differed from his view. Tom was focused on the message in the communication, but Alistair was also looking at the mechanism. Alistair expressed this as “Communication is like perfume; stronger when close.” The closer you are, the more likely you are to pick up additional information related to the message, and you may be able to clarify any misunderstandings or differences in interpretation.

Close communication can provide major clues and cues to things you need to discuss; things that are invisible in email or instant messaging. The extra information gleaned from face-to-face communication may be explicit—like colloquial French, which incorporates hand gestures with specific meanings, or more subtle—such as the way a message is delivered: body language, speech tone or speed, or another person’s reactions. An example of these subtleties is poker tells, subconscious signals that poker players may have that indicate the strength of their hands.

Members of software development teams may have concerns or uncertainty that they aren’t comfortable expressing, whether from personal, cultural, or organizational habit. This uncertainty may result in misunderstandings, communication breakdown, or oversight that could lead to buggy design, code, or testing. By closely observing how a message is delivered or how a message is reacted to, we can leverage it as a cue to further discussion using open questions.

Alistair gave me an example where he was talking to a developer who had been raised in a “loss-of-face” culture where it was considered rude to admit your own fallibility, though it is always an important factor as most people get intimidated or embarrassed. While discussing a tricky aspect of the design, the developer flinched visibly. By taking his cue and focusing on the topic the developer reacted to, Alistair asked probing questions causing the developer to open up to discussing various options, eventually deciding on a preferred one.

If this discussion had been via email or instant messaging, this subtlety may have been missed. In phone conversations, voice cues are observable and may be useful indicators of one’s real feelings on a topic. When you detect a reaction, you can follow up immediately or at another convenient opportunity. This could be as a hallway conversation, followup meeting or phone call, providing a way through leading questions to discuss the topic. Responding to an unintended reaction will not only allow the other person to follow up either with you or a relevant expert but it also can provide testing ideas or a testing focus. The trouble spot or real issue may not have been evident until you touched on it during a conversation. Don’t forget that some people need to internalize their thoughts and may need thinking time, so don’t rush them towards a resolution.

Face-to-face communication is the best option, but if that’s not possible, try live video or picking up the phone. Pay close attention to the way things are said or reacted to. I've heard of some places having a permanent web-cam link set up between different sites so people can talk directly to each other. Relevant general discussions are always good, but try to discover any ongoing concerns as well. Simply discussing something or scheduling a discussion with the relevant people may resolve them. Bringing things out of the shadows into active discussion can raise the level of quality (particularly on large or distributed teams), without a bug report in sight! Not only are there less bugs, but discussions of areas of concern can lead to much more solid design and implementation, meaning less chance of bugs in future changes.

How has close communication helped your work, or could it have helped?