Software Development Alistair Cockburn
describes various modes of communication that people may
choose to apply when working together (this work was
Media Richness Theory).
Figure 1, modified from
that book, shows a graph comparing the effectiveness of
these modes of communication with the richness of the
communication channel employed. The two arcs are interesting, the left-most one listing
communications options for when you are documenting
(paper includes electronic media such as HTML that could
be rendered to paper) and the other communication
options for when you are modeling.
These relative value of these options are of
course dependent on the situational: perhaps video
conversation, typically referred to as video conferencing,
is more effective between you and John than a
face-to-face conversation whereas the exact opposite is
true between you and Sally.
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:
How do we communicate?
Factors effecting communication
Communication and Agile Modeling
Towards agile documentation
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.
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.
Figure 2. Implication of the modes of communication.
| Communication Strategy
|| Within Team
|| With Stakeholders
| Face to face (F2F)
| F2F at Whiteboard
| Overview diagrams
| Online chat
| Overview documentation
| Teleconference calls
| Detailed Documentation
There are several factors that
effect communication, including:
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.
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
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.
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
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
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
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.
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.
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.
Many laptops, workstations, and phones now have cameras and software built in that enable videoconferencing.
Software tools used to check in/out, define, and
manage versions of project artifacts.
Tools that enable communication between several
people who are in different physical locations.
See the article Agile/Lean
Best Practices for Agile/Lean Documentation.
When is communication most
people are willing to work together and do what it takes
to get the job done.
This is why AM's principle of
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
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
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.
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
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
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
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.
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
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
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
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
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
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.