Agile is lots of Communication

This is the first post of a series of posts where I will try to define what I think are the most important properties of Agile. As I have been reading Alistair's book, the first post is about "Communication".

What is communication and why is so important in Agile?

To understand the importance of communication in Agile, let start by its definition. The Merriam-Webster definition says communication is "to transmit information, thought, or feeling so that it is satisfactorily received or understood". Another definition taken from Alistair Cockburn says "communication is transferring one idea from one person to another". The latter is a stronger definition as it implies the idea needs to be understand by the receiver (as opposed to just received).

Why is so important to communicate in Agile?

Agile reckons that the process of construction of a software solution is a creative game where the individuals involved interact continuously to build a solution. Cockburn calls the process "a cooperative game of invention and collaboration". During this game, all actors involved contribute their particular knowledge and therefore they need to communicate among them as effectively as possible.

Even more, most Agile methodologies deliver the solution incrementally and encourage highly concurrent development in each iteration. This means all actors are usually working in the same piece of functionality at the same time. Abundant and effective communication among all actors is vital.

Let's try to visualize this with an example. At the beginning of the iteration, an increment of functionality is proposed to be built. This functionality is expressed as a set of user stories written usually by the product owner. In the planning meeting, the product owner tries to communicate what s/he thinks are the key ideas of this new functionality. A conversation between the team members and the product owner is usually kicked off where the team members usually provide quick important feedback about the feasibility and also quite often new ideas that could improve what the product owner had in mind. During the iteration, teams need to communicate extensively with the product owner to clarify missed points and to show progress. This constant communication is key to build the right product (i.e. to build what the customer is expecting). Among the teams, communication needs to be fluent and constant as well. Developers and testers (and all other actors involved) need to design, develop and test a piece of software in a short period of time. A great flow of information circulates when designing the solution, the tests and after development has finished when the team converges and agree on the final product. Agile foster the creation of the test scenarios and test cases as a group and also the creation of code in pairs. It can be seen that the flows of communication go in all directions.

Individuals and interactions over processes and tools

What are these guys trying to say? The statement says a lot about the philosophy underlying Agile and it takes a great deal of time to understand it and interpret it. My current understanding says Agile values more a team of crafted software engineers collaborating towards the creation of a solution than the same team following a prescribed process. As it is explained in the Agile Manifesto webpage, it is a "We value more" statement. It doesn't mean processes should not be used or tools are useless. It means that the focus of the methodologies, processes and frameworks is on the people and their interactions rather than in the creation of intermediate work products, filling templates or following instruction lists.

How should this interaction occur? Agile delivers software incrementally in short iterations using highly concurrent development practices. All members need to communicate to produce something in a short period of time and therefore the communication needs to happen as efficiently and as effectively as possible. And which is the most effective way of communicating? The Agile Manifesto lists as one of its 12 principles: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".

Which are the most effective ways of communicating?

It is very difficult to communicate. If you think that even between people of the same culture and language talking face to face in a room there could be misunderstandings, you can imagine how difficult it could get (don't you have misunderstandings with your wife after living with her for many years?!!). People have their own context and ideas and so the information they receive is processed according to it. Besides, our natural language is limited and imperfect (and it reduces to the person that is trying to communicate).

So which are the most efficient and effective ways to communicate. How can we minimize misunderstandings? How can we communicate faster? Cockburn studied this and came with the following graph.

In the X axis, there's the temperature of the communication channel. Reading a paper document is the coolest of the channels and therefore, the least effective. Talking face to face in front of a whiteboard, while writing diagrams is the hottest and most effective way to communicate. I don't think many people would disagree with this. There is nothing like talking to someone while you see his face, his expressions and his body language. These "other" channels act in both directions and allow to reformulate or write a diagram if the receptors make "weird" expressions or even speed up if the receptors are getting bored. There is nothing like seeing the face of the people you are communicating with.

So how should this graph be used? All projects and all teams are different and run under different circumstances. If the team is small and it works in the same building, it is clear that they should all work in an open room, where they can talk to each other whenever they want (this is the Agile sweet spot). However, today's reality brings much more challenging projects, where the teams are distributed, in different countries, with different languages, cultures and worst of all, huge timezone differences. Generating the necessary communication channels in these situations could get really hard, but we need to keep in mind that communication is key to success in Agile. Each team will have to use the best of their imagination to figure out ways of heat the communication as much as they possibly can.

It is important not to loose pragmatism when thinking the communication channels. For example, Cockburn mentions that when the development team doesn't have full access to the business people, it is effective to leave some kind of "sticky information" that developers can check whenever they want. I found this example very valuable, because there are always fanatics that read the theory and stop thinking.

How does Agile "manage the incompleteness of communication"?

Agile tries to manage the incompleteness of communication by trying to improve the communication influx and by verifying, as soon as possible that what was communicated is what was really meant to be communicated.

Agile improves the communication:

- By encouraging open spaces where both business and technical users sit together. This fosters conversation among the technical members and with the business people, conversations can be overheard, everybody knows who is on its desk and who isn't and usually what are they working on. In short, it creates a medium where everybody is sharing the same information because the communication channels are shared by everybody. Cockburn calls this "osmotic communication".

- By having a daily standup. This short meeting that occurs daily pushes everybody to communicate.

- By doing pair programming, as XP suggests. This practice can be performed by 2 developers, 1 developer and 1 tester or 1 business people and either a developer or a tester. Although the main objective of this practice is to produce better code and minimize the bugs, it creates a great opportunity to exchange patterns, techniques (when done between technical members) and business information (when a business user is involved).

Agile provides several verification points because it delivers the software in iterations. This means that in a short period of time (from 1 week to 1 month) the business people can see working software and can verify if what they see is actually what they had in mind. Agile also encourages business users to write acceptance tests. These executable specifications are run as soon as the functionality is completed and also serve to verify that the develop functionality is what they are expecting.

Conclusion

Agile development relies on creative individuals which interact continuously to build the proposed solution. Communication could get hard, but is always necessary. Each project could bring its own challenge. Agile relies on these creative individuals to find ways to communicate as much and as good as they possibly can.