- Property 1.Frequent Delivery
- Property 2.Reflective Improvement
- Property 3.Osmotic Communication
- Property 4.Personal Safety
- Property 5.Focus
- Property 6.Easy Access to Expert Users
- Property 7.Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
- Evidence: Collaboration across Organizational Boundaries
- Reflection on the Properties
- Footnotes
This chapter is from the book
This chapter is from the book
This chapter is from the book
Property 3. Osmotic Communication
Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work. Several people have related their experience of it much as this person did:
We had four people doing pair programming. The boss walked in and asked my partner a question. I started answering it, but gave the wrong name of a module. Nancy, programming with Neil, corrected me, without Neil ever noticing that she had spoken or that a question had been asked.
When osmotic communication is in place, questions and answers flow naturally and with surprisingly little disturbance among the team.
Osmotic communication and frequent delivery facilitate such rapid and rich feedback that the project can operate with very little other structure.
Does it take you 30 seconds or less to get your question to the eyes or ears of the person who might have the answer? Do you overhear something relevant from a conversation among other team members at least every few days?
Osmotic communication is the more powerful version that small projects can attain of close communication, a property core to the entire Crystal family. Osmotic communication makes the cost of communications low and the feedback rate high, so that errors are corrected extremely quickly and knowledge is disseminated quickly. People learn the project priorities and who holds what information. They pick up new programming, design, testing, and tool handling tricks. They catch and correct small errors before they grow into larger ones.
Although osmotic communication is valuable for larger projects, it is, of course, increasingly difficult to attain as the team size grows.
It is hard to simulate osmotic communication without having the people in the same room; however, adjacent rooms with two or three people in each confers many of the benefits. Herring (2001) reported the use of high-speed intranet with Web cameras, microphones, and chat sessions to trade questions and code, to simulate the single room to (some) extent. With good technology, teams can achieve some approximation of close communication for some purposes, but I have yet to see osmotic communication achieved with other than physical proximity between team members.
Discussion of osmotic communication inevitably leads to discussion about office layout and office furniture.
Crystal Clear needs people to be very close to each other so that they overhear useful information and get questions answered quickly. The obvious way to do this is to put everyone into a single room ("war room"; see Figure 2-1), repeatedly shown as being very effective (Olson 2000).
){kind=small}
Figure 2-1
Osmotic communication. (Courtesy of Tomax)
Many people who have private offices resist moving into a group space. However, you can sometimes turn lemons into lemonade (so to speak) with this move:
Lise was informed by her management that her department would have to reduce the number of square feet they used. This meant giving up private offices. She suggested that her people work together and design their own office spaces, three to five people in a combined area. The groups put fewer square feet around each work table so they could allocate space for additional areas with chairs, a sofa, or, in some cases, their own meeting rooms.
Figures 2-2 and 2-3 show what one group came up with. Note that although they had fewer square feet per person than before, they ended up with longer sight lines and a conversation area with soft chairs.
)
Figure 2-2
Floor plan. (Courtesy of Schlumberger)
){kind=small}
Figure 2-3
Photo of same office. (Courtesy of Schlumberger)
Figure 2-4 shows the small meeting room one group put on the side of their shared office. They used it to talk without disturbing whoever was still programming, and also to leave their design notes and plans up on the wall.
)
Figure 2-4
Group work room attached to shared office. (Courtesy of Schlumberger)
Lise's group used the usual office furniture: concave, designed to have the fat CRT back into the corner. This sort of table presents a disadvantage to an agile development team, because it is hard for a second or third person to see the screen. The war room in Figure 2-1 may look less glamorous, but there is a utility in those ugly tables: People can congregate around a screen; pairs of people can work together easily. It is for this reason that agile development teams prefer straight tables, or even better, tables that bulge outward toward the typist.
If you set up a war room work area, be sure to arrange another place for people to go to unwind and do their private e-mail. This allows people to focus when they step into the common area and find a bit of relief from the pressure by stepping out. Such an arrangement is referred to as a "caves and common" arrangement.
One project team got permission to set up a common discussion area with soft chairs and sofa (Figure 2-5). On the wall in front of the chairs is the ever-present whiteboard with whiteboard capture device. This is where the team adjourned to hold their group design discussions, iteration planning meetings, and reflection workshops.
)
Figure 2-5
Group discussion area. (Courtesy of Darin Cummins and ADP’s Dealer Services)
Agile Software Development (Cockburn 2002) contains additional information on "convection currents" of information flow within a group, osmotic communication, the value of colocation, and examples of office layout.
Osmotic communication generates its own hazards, most commonly noise and a flow of questions to the team's most expert developer. People usually self-regulate here and request less idle chit-chat or more respect for think time.
Attempting to "protect" the lead designer with a private office usually backfires. That person really needs to be sitting in the middle of the development team. The lead designer is often the technology expert, a domain expert, and the best programmer, and so is necessarily in high demand. When she is taken away, the younger developers miss the chance to develop good development habits, miss growing in the domain and the technology, and make mistakes that otherwise would get caught very quickly. The cost to the project ends up being greater than the benefit of quiet time to the lead designer. Having the lead designer in the same room as the rest of the team is a strategy called Expert in Earshot (Cockburn url eie), a special use of osmotic communication. (Andrews url) has a blog entry about creating such a seating arrangement accommodating twenty people.
Even the best success property is unsuitable under certain circumstances. Osmotic communication is no exception. If the lead designer gets so overloaded and so frequently interrupted as to be unable to make progress on anything, the lead designer needs a workplace with no interruptions at all and extremely limited communications with the team, a cone of silence, I call it. Many lead designers use the hours from 6:00 P.M. to 2:00 A.M. as their cone of silence, but it is better for all involved if an acceptable cone of silence can be set up within normal working hours. The cone of silence strategy is described in detail in (Cockburn 2003b).