At its most basic level, software development is both enabled by, and constrained by, the quality of the communication that takes place among the people involved. Customers form ideas about what they need, and communicate them to the development team; the team-members communicate with each other and with the customer to build functionality that satisfies those needs; the customer communicates feedback to the team about what's been built; and throughout this process, everyone communicates with each other about questions they have, obstacles they encounter, opportunities they see, and how they are feeling (satisfied, concerned, etc.)

Consider a Product Owner in one location and a development team in another location. The quality of the communication between them will directly determine how much business value (in the form of useful, high-quality software) is delivered. Every misunderstanding between the Product Owner and team means a little less value will be delivered; when the team implements a piece of functionality incorrectly, and has to go back and redo it, there is other work that in the end will not be completed. Also, the more effort the communication requires, the less business value will be produced; if the team has to leave 3 voicemails for the Product Owner to get a response to their question, the Product Owner will inevitably get a little less software in the end; the team was spending their time dialing and waiting, not coding! Great software is typically produced only when there is great communication between the people involved, and poor communication will limit the quantity, quality, and correctness of the end result.

So how do we ensure that communication between the Product Owner and team is as effective as possible?

First, there are practical considerations. The various modes of communication – email, telephone, face-to-face conversation – can be placed on a "richness" scale, which looks something like this:

By and large, the higher up this scale you are, the richer and easier the communication, the more natural the interaction and the more immediate and faithful the understanding between people.

Email is, unfortunately, the go-to mode of communication between most distributed Product Owners and teams, and this is a mixed blessing. Its great strength is that it is not dependent on both parties being present simultaneously, and it preserves a record of the discussion that can be referenced later. The big disadvantage of email is that it is often much more time and effort-intensive. A discussion that might otherwise require a single, five-minute telephone chat could easily turn into 10 back-and-forth emails, each cc:ed to other people (thus consuming their time and attention, if even just to hit the delete key). Email conversations also breed misunderstanding, and as a result, unnecessary or unintended emotionality; without the subtle cues of voice intonation and facial expression, one can easily misunderstand the mood, tone, and intent of the writer.

ScrumMasters working with teams and Product Owners that are distributed need to help everyone shift away from email as the primary means of communication. This starts with making live communication as effortless as possible.

First, the group itself (including the Product Owner) needs to agree that wherever possible, conversations should take place live rather than via email. (If the conversation needs to be documented, either party is always free to send a brief email summary after the call.)

It is important for the Product Owner to clearly communicate to the team that it is acceptable to phone with quick, urgent questions without any "pre-scheduling" required – otherwise, many teams will assume that it is not ok to call, and will default to email.

Next, everyone's (and especially the Product Owner's) desk and mobile phone numbers and IM usernames need to be placed on a wiki or other shared location, along with acceptable outside-of-offices hours to phone with urgent questions, as well as a photo of the person (to remind us that it is in fact a person!). For example:

Tom (Product Owner)
desk: +1-123-456-5678 mobile: +1-123-456-6789
office hours: Mon-Fri, 8am-6pm PST = 8:30pm-6:30am India time
urgent questions: Call mobile Mon-Fri 6:30am-9:30pm PST = 7pm-10am India time

In the team work area, there should be a high-quality speakerphone (for example, a Polycom SoundStation) with the speed-dial buttons programmed to the Product Owner's desk and mobile phone numbers (preceded by any long-distance "unlocking" codes), plus a sticker attached to the phone with the acceptable local hours to call (or clocks will the different location times).

In addition, each team-member's desk phone or VOIP application (and if possible, mobile phone as well) should also have the Product Owner's telephone numbers programmed on speed dial.

Enabling easier telephone communication is an important step, but it is not enough. All of the key Scrum meetings – Sprint Planning, Product Backlog Grooming, Sprint Review, and Sprint Retrospective – should be conducted visually. The problem with audio-only meetings are many. One misses out on facial expressions and body language entirely. It can be unclear which voice belongs to which person. The natural "flow" and cadence of a conversation is often missing; there are either unintentional interruptions, or people are afraid to speak up for fear of interrupting. If participants have unfamiliar accents, it is harder to understand them without a view of their face as they speak. However, the most significant dysfunctions of voice-only calls is people "multitasking" during the call; without a visual on what they are doing, people will often find checking email or surfing the Internet irresistable, and only pay partial attention to what is being discussed. Participants are effectively only "half-there."

Some companies have invested in sophisticated videoconference equipment, but teams may find it complex and cumbersome to operate, or the conference room where it is located is often booked. It may be more effective to provide the team with an improvised solution as follows:

Video: Skype with a wide-angle high-resolution webcam. (It is important to use a wide-angle webcam – this gives a wider field of view, enabling more people to be seen on-camera)

Audio: High-quality conference phone connected via a land-line, with multiple extension microphones for the table. (In some cases doing the audio via Skype is sufficient, but generally a high-quality conference phone on a land-line will produce much better fidelity.)

Ideally, the above equipment should be set up and ready to use at any time in the team room, and this should be replicated at the Product Owner's side. While the quality may not compare with a more sophisticated system, it more than compensates with its simplicity, low cost, and convenience, and it provides the most important visual information: Who is speaking, their expression and body language, and whether people are paying attention. And perhaps most importantly, you are reminded that your colleague is not just a disembodied voice on the end of the line, but a real, live human being!

If the team itself is split between multiple locations, it is strongly recommended to equip each team-member with a webcam and a comfortable, high-quality headset with microphone. This allows for quick, one-to-one audio-video communications at any time, without people even leaving their seats. In addition, there should ideally also be an "always-on" videoconference between the team's locations: a high-resolution wide-angle webcam and large-screen plasma display in each of the team work areas, with continuous Skype video streaming between the two. This serves as a "window" between the two rooms, and because it is always on, it enables instantaneous multi-person conversation and collaboration.

In addition to videoconferencing capability, it is important to also have some type of desktop-sharing software with virtual whiteboard capabilities. Many teams also find it useful to use a low-cost digital tablet for diagramming on this virtual whiteboard.

Finally, for the key Scrum Meetings – Sprint Planning, Product Backlog Grooming, Sprint Review, and Sprint Retrospective – it's helpful to have simultaneous videoconferencing and whiteboarding capability. The following diagram shows a conference room with an ad-hoc setup for doing this, with two projectors side-by-side (one projector displaying the Skype video feed from the other location, and the second projector displaying the shared desktop or virtual whiteboard), plus a high-quality conference phone on a land-line.

Offshore teams may feel uncomfortable asking for these investments in quality communication for fear of being perceived as burdensome or demanding, but when one considers the "big picture," it is hard to justify not making this investment: