XP Values: Communication

Agile teams value Communication and usually organize themselves to facilitate communication along some desired channels. For example:

• cross-functional teams unite developers, testers, analysts and sometimes business people to work on the same story. Communication within a project is preferred to communication inside communities of practices (such as the testers community in a company).
• the Sit Together principle keeps the team members at a short distance from each other, to stimulate casual interactions and conversations. This seems strange, but gives the possibility of hooking in into discussions to everyone: implementing DevOps includes having a system administrator that overhears you're storing files locally and warns you about the issue of sharing those files between multiple servers.
• User Stories are an excuse for having a conversation with the customer, being it external or internal to your company. A story physical representation is just a card divided in three rows, while the conversation is what matters as during it there is space to negotiate the scope of the story, split it or define its testable acceptance criteria.

Problems

Kent Beck write in XP explained, "Whenever you have a problem, think about how it could have been resolved with better communication." It is common that a wide category of problems is caused by noise in communication or in its absence:

• a customer which is not colocated with the development team (not even with a proxy person acting as a representative for quick questions), causing requirements and change to them to propagate slowly and with many analog/digital conversions.
• remote developers without the support they need to be effective (such as daily pairing with someone on-site).
• Functional silos as separation between development and operations (read programmers and sysadmins) that require deployments to be requested on stamped paper.

Scale

On and on, you can find dozens of examples about communication inside an Agile team and directed from the team towards external stakeholders, such as customers, suppliers, and regulators.

The challenge, however, is to make the communication channels scale. Every person has a limited time and attention span, and it is not feasible to sustain a situation where everyone routinely talks with every other person in the team (for business reasons - casual gatherings at the coffee machines or at the water cooler are welcome.)

The famous Brooks law Adding manpower to a late project makes it later captures this explaining that while the production capacity of a team may theoretically scale linearly with its N team members, the communication channels necessary grow with N*(N-1)/2. While N increases, communication can easily become the only accomplished task during the day, while XP makes it clear that everyone talking and no one producing is not the objective.

Here are some ideas to manage communication in your organization, specifically to avoid some of its costs:

• meetings cost N time their duration, where N is the number of participants. Remember every time you're calling a meeting of 2 Pomodoros that you're actually spending 2N Pomodoros.
• Asynchronous communication scale in software systems, but also in human systems. Internal mailing lists help diffuse non-urgent information such as upgrade notes, while an Erlang-like systems of post-it queues over each person avoid continuous interruptions by making them finish their Pomodoros before engaging in communication.
• Smaller teams (at the extreme as enunciato by Bezos 2 pizzas rule) can coordinate internally easily, while exposing just one interface towards the rest of the organization.

On the other hand, Communication is usually a value that is overlooked more than having to be controlled. Especially at scale, if you have a problem it's likely than someone else has had this problem before; the challenge is in getting the solution from the original solver to the rest of the team, but without boring peple with solutions to problems they'll never encounter and without pestering the ones that solve the most problems with constant requests for help.

Conclusions

Communication is a value necessary for the success of an Agile team, but that can be overlooked by most programmers coming from some backgrounds, such as freelancing. The constant rethinking of how to communicate more and with fewer costs is part of the costs of scale that a team encounters whenever it has more than 1 member.