Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 3. Communicating, Cooperating Teams Convection Currents of Information
-
Часть 3
-
While writing, reading, typing, or talking, we pick up traces of the the ongoing sounds around us, using some background listening mode, even though we are not consciously paying attention.
If someone says something interesting, we may perk up and join storetourism.ru the conversation. Otherwise, the sound goes through some background processing, either just above or just below our conscious level.
In some cases, we register enough about the conversation to be able to develop what we need directly from memory. Otherwise, we may recall a phrase that was spoken, or perhaps only that a particular person was discussing a particular topic. In any case, we can ask about it.
This taking in information without directly paying attention to it is like the process of osmosis, in which one substance seeps from one system, through a separator, into another.
Osmotic communication further lowers the cost of idea transfer.
If Pat and Kim work in the same room, Pat programming and Kim having some other discussion, Pat may get just enough information to know that Kim has talked about the idea. If there are multiple people working in the same room, then Pat gets to know that someone in the room has the answer.
We have seen three separate effects that office layout has on communication costs within a project:
· The reduction in cost when people discover information in background sounds (osmotic communication)
· The overall cost of detecting and transfering information (erg-seconds)
· The lost opportunity cost of not asking questions The three magnify the effects of distance in office seating. People sitting close by each other benefit in all three effects, people sitting in separated locations suffer in all three.
According to this theory, sponsors should think a second time before sponsoring a geographically distributed project.
One might think that we now have an easy answer to the riddle of how to seat people: "Obviously, " put them into open and shared workspaces. Unfortunately, people are not quite so uniform or simple.
Three more issues affect the answer in any one particular setting:
· The sort of information being shared
· People's personal preferences
The team members exchanges both business and technical information.
Suppose that Chris is the business expert in the group. If Chris, Pat and Kim sit together, Chris can answer business questions as soon as Pat or Kim encounter them. Chris might even see what Pat and Kim are doing, and head them in a different direction. The three of them can put their three heads together at any instant, to jointly invent something better than any one of them can do.
This sort of radical colocation (as it has recently been called) only works for very small teams. Among twelve programmers and four business experts, who should sit close to whom? How does one arrange seating with two-person rooms?
The most common seating arrangement I encounter consists of programmers sitting on one side of the building and business experts on the other.
This seating arrangement produces two problems. The obvious one is the cost of business communication, including the lost opportunity cost of missed early interventions.
The second is that each group forms its own community, and usually complains about the other group. The chit-chat in the osmotic communication is filled with these complaints, interfering with the ability of people in each group to work with each other in an amicable way.
As is natural with osmotic communication, this emotionally loaded background noise soaks into each group's subconscious. In this case, it does not educate them, but rather it attacks their attitude. Going into a meeting with "those idiotic other people, " they don't give full consideration to what the other people say, and don't offer full information in speaking. The group's amicability suffers, with all the attendant costs just discussed.
My current preference is to find seating arrangements where one or more business experts sit close to two or more programmers. Where this is not possible, I look for other business- and social mechanisms that will get the business expert in regular, meaningful collaboration with the programmers on a frequent (preferably daily) basis.
Cross-specialty teams working together have been recommended by many authors, and given names such as Holistic Diversity (Cockburn 1998), CASE teams (Hammer 19? ?), and Feature teams (McCarthy 199? ?) When this can be done, the project as a whole moves faster, based on the increase in both information flow and amicability across specialties.
The second of the three remaining issues is the matter of people's personal preferences.
As I started asking people about working in shared rooms versus in private offices, several issues emerged.
Some people really value their quiet, private offices. They value them enough that they would feel offended if they had to give them up, some even to the point that they would quit the company. If that is the case, then any gain in communication is partially lost if the person stays, but feels offended, and completely lost if the person leaves the company.
Thus, the clear theoretical argument for seating people close to the people they need to interact with is affected by personal preferences. Several people have told me, "I prefer having my own office, but considering all the projects I've been on, I would have to say that I was never so productive as when I shared an office with my project mate. " I have moved out of private offices so often that I eventually noticed it as a pattern. As I noticed other experts doing it, it became a project management strategy, which I call "Expert in Earshot" (Cockburn 2001a).
The third mitigating factor is drafts.
-