Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.

htm

Communication on Agile Software Teams

Home Start Here Core Practices Disciplines Artifacts Resources Contact Me

Search

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:

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?
In Agile Software Development Alistair Cockburn describes various modes of communication that people may
choose to apply when working together (this work was based on 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.

Figure 1. Modes of Communication.

1 of 6 12/8/20, 11:34 AM
Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.htm

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. See Figure 2 and the article Choose the Right Communication
Technique for more thoughts.
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

2 of 6 12/8/20, 11:34 AM
Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.htm

each iteration during a process improvement retrospective.

Figure 2. Implication of the modes of communication.

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

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.

3 of 6 12/8/20, 11:34 AM
Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.htm

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.

Teams that pair together

stay together.

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 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
Software-based modeling tools (SBMTs), also known as computer aided
software engineering (CASE) tools, that enable several developers to
Collaborative
simultaneously work on one or models with real-time updates of those
modeling tools
models. These tools are typically browser-based and hosted via a SAAS
strategy.

4 of 6 12/8/20, 11:34 AM
Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.htm

Word processing tools that enable several people to simultaneously write a

Collaborative
document with real-time updates of that document. Wikis and Google Docs
writing tools
are examples of this.
Tools such as email, newsgroups, mailing lists, instant messaging, and chat
Discussion tools rooms that enable transmission of text messages, and potentially other
attachments, between people.
Inclusive Modeling Simple tools such as whiteboards, sheets of paper, sticky notes and so on.
Tools
Many laptops, workstations, and phones now have cameras and software
Personal video
built in that enable videoconferencing.
Version control Software tools used to check in/out, define, and manage versions of project
tools artifacts.
Virtual meeting Tools that enable communication between several people who are in different
tools physical locations.

4. Towards Agile Documentation

See the article Agile/Lean Documentation and Core 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

5 of 6 12/8/20, 11:34 AM
Communication on Agile Software Teams http://www.agilemodeling.com/essays/communication.htm

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.

Recommended Reading
This book, Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your
Way of Working, is an indispensable guide for agile coaches and practitioners to
identify what techniques - including practices, strategies, and lifecycles - are
effective in certain situations and not as effective in others. This advice is
based on proven experience from hundreds of organizations facing similar
situations to yours. Every team is unique and faces a unique situation,
therefore they must choose and evolve a way of working (WoW) that is
effective for them. Choose Your WoW! describes how to do this effectively,
whether they are just starting with agile/lean or if they're already following
Scrum, Kanban, SAFe, LeSS, Nexus, or other methods.
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 fundamental programming and testing techniques for successful
agile solution delivery. The book also shows how to move from your agile
models to source code, 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 Techniquesbook.

Copyright 2001-2020 Scott W. Ambler This site owned by Ambysoft Inc.

6 of 6 12/8/20, 11:34 AM