Communication is the act of transmitting information between individuals. The need to communicate effectively pervades software development, operations, and support. Developers and end users must communicate with one another. Developers and operations staff must communicate. Developers and management must communicate. And so on.

In this article I explore the issues surrounding communication, and in particular focus on how to become more agile in your documentation efforts. For many people modeling and documentation go hand in hand, a concept that I argue is questionable at best, and therefore is a topic that needs to be addressed. This article is organized into the following sections:

Figure 1. Modes of Communication.

Implications of Figure 1:

Strive to follow the most effective communication technique applicable to your situation. If you're working together with someone in the same room, it's likely best that you discuss something with them face-to-face at a whiteboard than to write them a document which you eventually hand-off to them. If you're working with someone at another location, then you'll want to set up regular video conference calls with them, have a shared information repository, and email regularly -- flying them in every so often so you can work face-to-face would be a great idea too. See Figure 2 and the article Choose the Right Communication Technique for more thoughts. Be prepared to vary your approach throughout a project. Team dynamics will change throughout a project, so the communication strategy that worked well for you yesterday may not work well today. The daily conference call which you introduced three months ago to address communication challenges between distributed team members may no longer be needed now that people have built up a rapport and are now using a shared wiki and chat software and are making impromptu calls when needed. The implication is that you should regularly question the ways that you're communicating, a good option is to do so at the end of each iteration during a process improvement retrospective.

The Ambysoft 2008 Agile Principles and Practices survey, amongst many issues, explored the concepts captured in Figure 1. Two of the questions explored the effectiveness of communication strategies between developers within an agile software development team and between team members and stakeholders. The results are summarized in Table 1, with answers rated on a range of -5 (very ineffective) to +5 (very effective), aligning fairly well with what Figure 1 predicts. It is interesting to note that overview documentation was perceived as being reasonably effective although detailed documentation was not. Also, online chat was thought to be effective between developers but not with stakeholders, likely a reflection of cultural differences and experiences between the two communities.

Table 1. Effectiveness of communication strategies on agile development teams.

Communication Strategy Within Team With Stakeholders Face to face (F2F) 4.25 4.06 F2F at Whiteboard 4.24 3.46 Overview diagrams 2.54 1.89 Online chat 2.10 0.15 Overview documentation 1.84 1.86 Teleconference calls 1.42 1.51 Videoconferencing 1.34 1.62 Email 1.08 1.32 Detailed Documentation -0.34 0.16

There are several factors that effect communication, including:

Physical proximity. The closer people are to one another the greater the opportunities for communication. At one end of the spectrum two people can be working side-by-side pair programming at the same workstation and at the other end of the spectrum two people can be in different buildings. Temporal proximity. Whether or not two people are working at the same time affects communication. You may be separated from some of your co-workers by several time zones, it is quite common for North American firms to outsource development work to Asian or European companies, or even simply by different personal schedules. I once commuted from Toronto to San Francisco to work on a development contract, spending four days a week in San Francisco. I quickly learned that I couldn't continually be changing my internal clock to match the time zone that I was in, there is a three hour difference between the cities, so decided to stay on Toronto time. Being a morning person I was waking up at 3 in the morning San Francisco time, however, many of my co-workers were night people and would typically work until 3 or 4 in the morning. We found this quite effective: I would work during the day and stay at the office until they started to arrive, talking face-to-face with them as needed. I then left for my hotel, slept, and started dealing with email immediately upon waking, allowing me to find out what they had worked on during the night and then helping out via email where needed. It wasn't ideal but we made it work. Amicability. Cockburn believes that amicability, the willingness of someone to hear the thoughts of another person with good will and to speak without malice, is an important success factor. The greater the amicability a greater amount and quality of information will be communicated and less will be concealed. Amicability is closely by the trust that people have for one another and the sense of community that they share. Cockburn reports that sometimes amicability can run too high, people can be so worried about offending their colleagues that they are afraid to disagree with them or be afraid to take the initiative for fear of being perceived as glory seekers.

When people are working close together, both physically and temporally, there exists an opportunity for what Cockburn calls osmotic communication: indirect information transfer through overhearing conversations or simply noticing things happening around you. Osmotic communication can often be beneficial, I've lost track of the number of times I was working away and subconsciously picked up valuable information such as finding out that someone was finished their current task, that something wasn't working as expected, or even that management was thinking about canceling the project. Osmotic communication can often be harmful, particularly if another group of people is being rowdy near your or if you're picking up false rumors such as management is thinking about canceling the project.

Teams that pair together stay together.

Effective communication is a fundamental requirement for agile modeling. You need to recognize that you have several communication options available to you, as Figure 1 shows, and that you want to pick the best communication option for your current situation. Sometimes that will be email, sometimes it will be face-to-face communication, and sometimes it will be writing a document. Furthermore, you want to use technology effectively, as always the practice Use The Simplest Tools applies. Table 2 describes several types of communication technologies that you have available to you, and web sites such as www.collaboration-tools.com are an excellent resource if you are looking for new collaboration tools and techniques.

Table 2. Communication Technologies.

Technology Description Collaborative modeling tools Software-based modeling tools (SBMTs), also known as computer aided software engineering (CASE) tools, that enable several developers to simultaneously work on one or models with real-time updates of those models. These tools are typically browser-based and hosted via a SAAS strategy. Collaborative writing tools Word processing tools that enable several people to simultaneously write a document with real-time updates of that document. Wikis and Google Docs are examples of this. Discussion tools Tools such as email, newsgroups, mailing lists, instant messaging, and chat rooms that enable transmission of text messages, and potentially other attachments, between people. Inclusive Modeling Tools Simple tools such as whiteboards, sheets of paper, sticky notes and so on. Personal video Many laptops, workstations, and phones now have cameras and software built in that enable videoconferencing. Version control tools Software tools used to check in/out, define, and manage versions of project artifacts. Virtual meeting tools Tools that enable communication between several people who are in different physical locations.





See the article Agile/Lean Documentation and Core Practices for Agile/Lean Documentation.





When is communication most effective? When people are willing to work together and do what it takes to get the job done. This is why AM's principle of Open and Honest Communication is important because if you don't trust the information that you are receiving, or for that matter the people that are providing it to you, then your goal of effective communication is lost. I believe that the concept that everyone can learn from everyone else is critical to your success because it defines a mindset that enables communication: someone who believes they can learn something from the person(s) they are communicating with are much more receptive than someone who believes otherwise. This principle has it's roots in AM's value of Humility, a value that time and again proves to be a significant success factor for developers.

Effective communicators realize that the goal is to share information, and that this information sharing is typically a two-way street. For example, I recently attended a meeting where members of my development team were meeting with members of the team that operated another system that we needed to integrate with. Our goal was to define a contract model that described the interface to this system, something that ended up being a simple file transfer. The two groups met, as usually happens many of the people involved knew each other from previous efforts, and we very quickly got down to business. For the most part talked and drew diagrams on the POW, my team had brought a deployment diagram with us that depicted how we currently believed the two systems would work together, and as a group we negotiated changes to the overall approach. Both teams came to the meeting wanting to work together. We knew that we needed this other team and the other team knew that their job was to support groups like mine. Everyone was focused on working together, and that meant that we needed to communicate well. Attitude counts.

Another important success factor is your ability to pick the right mode of communication. In the example above we chose to get the right people in a room to discuss the issue face-to-face and work things out together. When we needed to we drew on the POW, we even drew on our initial deployment diagram, and most importantly we talked and we listened. Yes, we could have taken a different approach. I have no doubt that we could have emailed back and forth to one another. We could also have written documents and sent them back and forth to each other. The point is that we chose not to. We had the opportunity to use a superior form of communication: face-to-face communication at a POW: and we used that technique. It was fast, it was effective, it was agile.

Finally, you need a positive view of documentation. Documentation can either be good or bad, therefore you should strive to stick with the good and avoid the bad. Documentation can come in many forms, including both paper and video recordings, as you saw in Figure 1. The point is that you shouldn't forget that documentation can often be versatile and perhaps not even very painful to create. Agile Modeling's fundamental message regarding documentation is that you should write it only when it's your best choice and only when it adds the best possible value to your project.