Communication is one of the fundamental values of AM, although it would be more accurate to say that effective communication is what AM deems critical to your success.  What is communication?  With respect to AM, communication is the act of transmitting information between individuals.  Why is communication an issue worth discussing?  Because the need to communicate effectively pervades software development, operations, and support.  Developers and users must communicate.  Developers and operations staff must communicate.  Developers and management must communicate.  Developers and …  well, you get the idea.

In this paper 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 paper is organized into the following sections:

1. How do we communicate?

2. Factors effecting communication

3. Communication and Agile Modeling 

4. Towards agile documentation

5. Effective communication

1. How Do We Communicate?

Figure 1. Modes of Communication.

Cockburn contends that the most effective communication is person-to-person, face-to-face, particularly when enhanced by a shared modeling medium such as a plain old whiteboard (POW), flip chart, paper, or index cards. As you move away from this situation, perhaps by removing the shared medium or by no longer being face-to-face you experience a drop in communication effectiveness.  As the richness of your communication channel cools you lose physical proximity and the conscious and subconscious clues that such proximity provides.  You also lose the benefit of multiple modalities, the ability to communicate through techniques other than words such as gestures and facial expressions.  The ability to change vocal inflection and timing is also lost, people not only communicate via the words they say but how they say those words.  Cockburn points out that a speaker may emphasize what they are saying, thus changing the way they are communicating, by speeding up, slowing down, pausing, or changing tones.  Finally, the ability to answer questions in real time, the point that distinguishes the modeling options curve from the documentation options curve, are important because questions provide insight into how well the information is being understood by the listener.

Implications of Figure 1:

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.
2. 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.

2. Factors Effecting Communication

There are several factors that effect communication, including:

1. 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.

2. 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.

3. 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.

3. Communication and Agile Modeling

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 1 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 1. Communication Technologies.

4. Towards Agile Documentation

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

5. Effective Communication

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. 

6. Recommended Resources

• Agile/Lean Documentation: Strategies for Agile Software Development
• Best Practices for Agile/Lean Documentation

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

7. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.