Agile Software Development: Communicating, Cooperating Teams
- Convection Currents of Information
- Jumping Communication Gaps
- Teams as Communities
- Teams as Ecosystems
- What Should I Do Tomorrow?
This chapter is from the book
This chapter is from the book
This chapter is from the book
“Convection Currents of Information” compares the movement of information to the dispersion of heat and gas. The comparison yields several useful associations: the energy cost of information transfer, osmotic communication, information radiators, and information drafts.
“Jumping Communication Gaps” examines people’s efficiency in conveying ideas using warmer and cooler communication channels. It introduces the idea of adding “stickiness” to information and looks at how those two topics relate to transferring information across time.
“Teams as Communities” discusses amicability and conflict, the role of small team victories in team building, and the sorts of subcultures that evolve on a project. We will see that the differing cultural values are both useful to the organization and difficult for the team to deal with.
“Teams as Ecosystems” considers a software development team as an ecosystem in which physical structures, roles, and individuals with unique personalities all exert forces on each other. That each project produces its own, unique ecosystem makes the job of methodology design even more difficult.
Communicating, Cooperating Teams
Convection Currents of Information
Delays and Lost-Opportunity Costs
Erg-seconds
Osmotic Communication
Drafts
Information Radiators
Applying the Theory of Hot Air
Jumping Communication Gaps
Modalities in Communication
The Impact of Removing Modalities
Making Use of Modalities
Stickiness and Jumping Gaps across Space
Teams as Communities
Amicability and Conflict
Citizenship within Working Hours
Hostile XP versus Friendly XP
Building “Team” by Winning
Team Cultures and Subcultures
Teams as Ecosystems
What Should I Do Tomorrow?
Convection Currents of Information
Saying that software development is a cooperative game of communication implies that a project’s rate of progress is linked to how long it takes information to get from one person’s mind to another’s. If Kim knows something that Pat needs, the project’s progress depends on
- How long it takes Pat to discover that Kim knows something useful
- How much energy it costs Pat and Kim together to get the knowledge transferred to Pat
Let’s see how much this costs a project.
Delays and Lost-Opportunity Costs
A programmer these days costs a company about $2.10 per minute, so adding one minute to getting a question answered adds $2.10 to the cost of the project. Standing up and walking to another table can add that minute.
Suppose that people who program in pairs ask and get answers to 100 questions per week. Adding that minute’s delay costs the project $210 per programmer per week. On a 12-person team, this is about $2,500 per week for the team, which adds up to $50,000 for a 20-week project.
The project gets delayed almost a full week and costs an extra $50,000 for each minute of delay in getting questions answered, not assuming any other damage to the project for the questions taking longer to answer!
The delay is more on the order of five minutes if a person has to walk down the hall. If Kim is not there, it is likely that when Pat returns to his office, he has lost the train of thought he was working on and has to spend more time and energy recovering it.
Even worse, the next time Pat has a question, he may decide against walking upstairs, because Kim might not be there. For not asking the question, he makes an assumption. Some percentage of his assumptions will be wrong, and each wrong assumption results in Pat introducing an error into the program. Finding and fixing that error costs the project anything from multiple minutes to multiple days.
Thus, Pat’s not asking his question and getting it answered represents a large lost-opportunity cost. Over the course of the project, the lost-opportunity cost is far greater than the cost of walking upstairs.
I hope you palpably feel the project’s development costs rising in the following six situations:
- Kim and Pat pair-program on the same workstation (Figure 3-1). Pat wonders a question out loud, and Kim answers. Or, Kim mentions the answer in passing as part of their ongoing conversation, and Pat recognizes it as useful information. This takes little work by each person and takes the least time to accomplish.
- Kim and Pat sit at separate workstations, but right next to each other (side-by-side programming). Using peripheral vision or the usual chitchat that develops when sitting close together, Kim notices that Pat is looking for something on the Web and asks what the question is. Or, Pat simply asks. Kim answers, possibly without looking away from the screen. Not much work; not much time involved.
- Kim and Pat work on opposite sides of a room, facing away from each other (Figure 3-2). Kim is not likely to notice that Pat is looking for something, but Pat can easily see whether Kim is available to answer a question. At that point, Pat asks and Kim answers.
- Kim and Pat sit in adjacent offices, separated by a wall. Kim can’t see when Pat is looking for something, and Pat can’t see if Kim is available. Pat must get up, peek around the door frame to see if Kim is in, and then ask Kim the question.
- Kim and Pat sit on different floors or in adjacent buildings. Pat walks upstairs only to find that Kim is out! Now Pat has lost time, energy, the train of thought he was holding while he was working downstairs, and the motivation to walk upstairs the next time he has a question. The lost-opportunity cost starts to mount.
- Kim and Pat sit in different cities, possibly with several time zones between them. In this setting, not only will they not ask each other questions as often, they also will have to use less efficient, less rich communication channels to discuss the question and its answer. They expend more energy, over a longer period of time, to achieve the same communication result.
)
Figure 3-1 Two people pair programming.
(Photo courtesy of Evant Solutions Corporation)
)
Figure 3-2 Two people sitting at opposites sides of the room.
(Photo courtesy of Thoughtworks, Inc.)
The main question is, if you were funding this project, which working configuration would you like Kim and Pat to use?
What we see is that even minor differences have an impact on the rate of information flow.
Notice, in Figure 3-3, the two different situations occurring at the same time. The two people on the left are pair programming. It may be nice for them to have a small separation from the person on the right. However, if it happened to be the two people across the partition who needed to work together, the partition would soon become a problem. Indeed, I visited two people who were working across a partition, and it wasn’t long before they removed the partition. As one of them explained, “I couldn’t see his eyes.”
)
Figure 3-3 Pair programming and working across a partition. Between which pair of people will information discovery happen fastest?
(Photo courtesy of Thoughtworks, Inc.)
Erg-seconds
Comparing the flow of information with that of heat and gas is not as far-fetched as it may at first seem. With every speech act, Kim radiates both information and energy into the environment around her. That information or energy gets picked up by people within sight or hearing. Pat also radiates with every speech act.
In his case he radiates his need for information. Sooner or later, either Kim detects Pat’s information need, or Pat detects that Kim has the information. Whichever way the discovery goes, they then engage in conversation (or Pat reads Kim’s document, if Kim’s information is in written form).
In gas-dispersion problems, one analyzes the distance that molecules travel in a certain amount of time. The unit of measure for molecules is moles and that for distance is meters; therefore, gas dispersion is measured in mole-meters/second (how many moles of the gas travel how far, in how much time).
We can analyze the movement of ideas—memes, to borrow an appropriate term from The Selfish Gene (Dawkins 1990)—using similar terms. We are interested in how many useful memes flow through the project team each minute.
A meter is not the correct unit, though, because ideas travel through phone lines, e-mail notes, and documents, rather than through space.
What we care about is the amount of energy it takes to move a meme from one mind to another. The appropriate units are erg-seconds. An erg is a unit of work (such as walking up the stairs), and a second is a unit of time (such as time spent on the telephone); therefore, the term erg-seconds captures the cost in both labor and time to get a question answered.
(Bo Leuf comments that its inverse is also useful: argh-minutes, a measure of the pain of expending energy and not managing to convey the idea.)
Using this metaphor, let’s look at office layouts to see the energy cost associated with detecting that someone else has some needed information.
Suppose that Kim and Pat sit in offices some distance from each other (Figure 3-4). The walls between them keep Pat from seeing or hearing Kim. Kim radiates information as she walks around on her daily travels. The people in her room detect the greatest amount of information, and the people in earshot of her movement detect the next greatest amount. Information reaches Pat either as Kim walks into his office, or indirectly, through other people.
)
Figure 3-4 Energy and information moving through a barrier complex.
If their offices are next to each other, Kim is more likely to pop into Pat’s office, or vice versa (Figure 3-5, top). Just as gas molecules or convected heat move more easily between neighboring rooms, so also does project information.
If Kim and Pat share an office (Figure 3-5, middle), then just as Pat will smell Kim’s perfume sooner than anyone outside the office will, so will he notice if Kim radiates information that is useful to him.
)
Figure 3-5 Gas canisters (or people) in three different configurations.
The greatest rate of information movement occurs if they are sitting side by side. In the case of information, the information transmission is greater if they are working on the same task, pair programming, than if they are merely sitting side by side, working on different tasks (this has more to do with their focus of attention than the radiation).
Describing information transmission costs in erg-seconds captures the effect of distance and communication modality on project costs.
Assume face-to-face communications, sitting in your own office, versus walking 50 meters to a colleague’s office. Walking down the hall takes work (ergs) and time (seconds). Energy and cost increase, and the information transfer rate decreases. Move people closer, to the office next door. As the distance decreases, work required to visit the colleague decreases, and so do energy and project cost, while the information transfer rate increases.
Similarly, describing an idea on the phone takes more time than describing it in person. In this case, the time factor increases, and so does cost to the project.
The erg-seconds formula accounts for these changes well.
Of course, the formula does not account for wasted energy, such as jumping up and down while talking on the phone or walking around the building the long way in getting to a colleague’s office. It also does not guarantee that two people who work in the same room will ever actually understand each other. (See “The Impossibility of Communication.”) What it does say is that project costs increase in proportion to the time it takes for people to understand each other.
Osmotic Communication
While writing, reading, typing, or talking, we pick up traces of 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 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 used or perhaps only that a particular person was discussing a particular topic. In any case, we register enough to ask about it.
This taking in of 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, with Pat programming and Kim having a discussion, Pat may get just enough information to know that Kim has talked about the idea. If multiple people are working in the same room, then Pat knows 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 lost-opportunity cost of not asking questions
- The overall cost of detecting and transferring information (erg-seconds)
- The reduction in cost when people discover information in background sounds (osmotic communication)
The three magnify the effects of distance in office seating. People who sit close by each other benefit in all three effects; people who sit in separate locations suffer in all three.
According to this theory, sponsors should think twice 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 so uniform or simple that this will work in all cases.
Three more issues affect the answer in any one particular setting:
- The sort of information being shared
- People’s personal preferences
- Drafts
The team members exchange 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 encounters them. Chris might even see what Pat and Kim are doing and guide them in a different direction. The three of them can put their heads together at any instant to jointly invent something better than any one of them could do.
This sort of radical colocation (as it has recently been called) only works for very small teams. Among 12 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 chitchat 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 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 when 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 that work together have been recommended by many authors. These teams have been given names such as Holistic Diversity (Cockburn 1998), CASE teams (Hammer 1994), and Feature teams (McCarthy 1995). When this can be done, the project as a whole moves faster, based on the increase in both information flow and amicability across specialties.
Another issue 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 is 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 issue affecting the question of where to seat people concerns drafts.
Drafts
Drafty Cubicles
One day, while I was describing this peculiar notion of convection currents of information flow, one of the listeners suddenly exclaimed, “But you have to watch out for drafts!”
He went on to explain that he had been working in a place where he and the other programmers had low-walled cubicles next to each other and so benefited from overhearing each other.
On the other side of their bank of cubicles sat the call-center people, who answered questions on the phone all day. They also benefited from overhearing each other. But, and here was the bad part, the conversation of the call-center people would (in his words) “wash over the walls to the programmers’ area.” There was a “draft” of unwanted information coming from that area.
Drafts are the unwanted information in our newly extended metaphor.
Later, two programmers were talking about how their walls were too thin. They enjoyed their shared room but were bothered by their neighbors, who argued loudly with each other. Their room was drafty, in an information sense.
We now have a nice pair of forces to balance: We want to set up seating clusters that increase information flow among people sitting within hearing distance and balance that against draftiness—their overhearing information that is not helpful to them. You can develop a sense of this for yourself as you walk around.
Osmosis across Distances
Is there anything that teams can do to improve communication if they do not sit together, for whatever reason?
Charles Herring, in Australia, describes applying technology to simulate “presence and awareness,” a term used by a researcher in computer-supported collaborative work (Herring 2001). Following is a paraphrased summary of their experience:
E-Presence and E-Awareness
The people sat in different parts of the same building. They had microphones and Web cameras on their workstations and arranged small windows on their monitors, showing the picture from the other people’s cameras.
They wanted to give each person a sensation that they were sitting in a group (“presence”) and an awareness of what the other people were all doing.
Pat could just glance at Kim’s image to decide if Kim was in a state to be disturbed with a question. In that glance, he could detect if Kim was typing with great concentration, working in a relaxed mode, talking to someone else, or gone.
Pat could then ask Kim a question, using the microphone or chat boxes they kept on their screens. They could even drop code fragments from their programming workspaces into the chat boxes.
They reported a low distraction rate. Charles added that while programming, he could easily respond to queries and even answer programming problems without losing his main train of thought on his own work.
Pavel Curtis and others at Xerox PARC were able to simulate “whispering” (when a user would like to speak to just one person in a room) through video and audio. They also had their online chat rooms produce background sounds as people entered or left (Curtis 1995).
Because memes (ideas) don’t have to travel through air but travel through the senses, primarily audio and visual, we should be able to mimic the effects of convection currents of information using high-bandwidth technology. Still missing from that technology, of course, are the tactile and kinesthetic cues that can be so important to interpersonal communication.
Information Radiators
An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don’t need to ask questions; the information simply hits them as they pass.
Two characteristics are key to a good information radiator. The first is that the information changes over time. This makes it worth a person’s while to look at the display. This characteristic explains why a status display makes for a useful information radiator and a display of the company’s development process does not.
The other characteristic is that it takes very little energy to view the display. Size matters when it comes to information radiators—the bigger the better.
Hallways qualify very nicely as good places for information radiators. Web pages don’t. Accessing the Web page costs most people more effort than they are willing to expend, so the information stays hidden. The following story contributed by Martin Fowler, at Thoughtworks, reports an exception: This team found that a particular report worked best on a Web page.
Automated Build Report
A program auto-builds the team’s system every 15 minutes. After each build, it sends e-mail messages to each person whose test cases failed and posts the build statistics to a Web page.
The information about the system is updated every 15 minutes on the Web page. Martin reports that a growing number of programmers keep that Web page up on their screen at all times and periodically just press the Refresh button to check the recent system build history.
The first information radiators I noticed were at Thoughtworks, while talking with Martin Fowler about Thoughtworks’ application of XP to an unusually large (40-person) project (Figure 3-6 and Figure 3-7).
)
Figure 3-6 Hall with information radiators.
(Courtesy of Thoughtworks, Inc.)
)
Figure 3-7 Status display showing completion level and quality of user stories being implemented.
(Courtesy of Thoughtworks, Inc.)
Progress Radiators
Martin was describing that the testing group had been worried about the state of the system.
To assuage the testers’ concerns, the programmers placed this poster in the hallway (Figure 3-6) to show their progress.
The chart shows the state of the user stories being worked on in the iteration, with one Post-it note per story. The programmers moved the notes on the graph to show both the completeness and the implementation quality of the user stories they were working on. They moved a note to the right as a story grew to completion and raised it higher on the poster as its quality improved. A note might stop moving to the right for a time while it moved up.
The testers could see the state of the system without pestering the programmers. In this case, they saw that the work was further along than they thought and soon became less worried about the state of the project.
The best thing was that they could see the progress of the work daily, without asking the programmers a question.
Just as a heating duct blows air into a hallway or a heater radiates heat into a room, these posters radiate information into the hallway, onto people walking by. They are marvelous for passing along information quietly, with little effort, and without disturbing the people whose status is being reported.
A second use of information radiators, suited for any project using increments of a month or less, is to show the work breakdown and assignments for the next increment (Figure 3-8). The following example also comes from Thoughtworks.
)
Figure 3-8 Large information radiator wall showing the iteration plan, one flipchart per user story.
(Courtesy of Thoughtworks, Inc.)
Displaying Work Breakdown
The team created a flipchart for each user story. They put Post-it notes on the flipchart for the tasks they would need to do for that story.
They would move notes below a flipchart to show tasks being taken out of scope of the current iteration in order to meet the delivery schedule.
Evant’s XP team also used whiteboards and flipcharts as information radiators. Figure 3-9 shows the tasks for iteration “Mary Ann” (each iteration was nicknamed for someone on the Gilligan’s Island TV series).
)
Figure 3-9 Detail of an XP task signup and status for one iteration (nicknamed “Mary Ann”).
(Courtesy of Evant Solutions Corporation)
A third use of flipcharts as information radiators is to show the results of the project’s periodic reflection workshop (Figure 3-10). During these one- to two-hour workshops, the team discusses what is going well for them and what they should do differently for the next period. They write those on a flipchart and post it in a prominent place so that people are reminded about these thoughts as they work.
)
Figure 3-10 Reflection workshop output.
(Courtesy of Joshua Kerievsky, Industrial Logic, Inc.)
The wording in the posters matters. One XP team had posted “Things we did wrong last increment.” Another had posted “Things to work on this increment.” Imagine the difference in the projects: The first one radiated guilt into the project room and was, not surprisingly, not referred to very much by the project team. The second one radiates promise. The people on the second team referred to their poster quite frequently when talking about their project.
Periodic reflection workshops such as these are used in Crystal Clear and XP projects.
A fourth use of information radiators is to show everyone the user stories delivered or in progress, the number of acceptance tests written and met, and so on. (Figure 3-11).
The systems operations team at eBucks.com constructed a fifth use of information radiators, this time to keep the programmers from pestering them.
)
Figure 3-11 Graph showing growing completion.
(Courtesy of Ron Jeffries)
Displaying System Status
The programmers kept asking, “Is system A up? Is system B up? Is the link to the back end up?”
The maintenance team wrote the status of each system and link on the whiteboard outside their area. Each day, they updated the status. It looked rather like a ski area posting the status of lifts and runs (so skiers don’t keep asking the ski resort staff).
The group at eBucks.com came up with a sixth use of information radiators. This time it was the programmers who created the status displays:
Displaying Work Progress
The programmers were being asked about the status of their work every hour or two, which caused them no end of frustration.
They wrote on the whiteboard outside their office their intentions for the current week. As they completed their tasks, carefully sized to be of the half-day to two-day variety, they marked the tasks complete.
After these boards had been tried by the programmers, several other groups started using them to broadcast their own priorities and progress.
Applying the Theory of Hot Air
People have long applied the above-described “hot air theory of software development.”
Gerald Weinberg discussed the damaging effect of removing a soda machine from a computer help-desk area (Weinberg 1998). Thomas Allen, of MIT’s Sloan School of Management, discussed the effect of building design on R&D organizations (Allen 1984). IBM and Hewlett-Packard have incorporated such research in their R&D buildings since the late 1970s.
As a result of these and others’ work, it seems natural that research and development groups have whiteboards in the hallways or near coffee machines. What we have forgotten, though, is the significance of actually being within sight and earshot of each other.
Here are several examples. The first is from a Crystal Orange project. The second is from a project unsuccessfully trying to apply Crystal Clear. Next comes a discussion of the “caves and common” room design recommended by XP. The final example is a success story from Lockheed’s Skunk Works group.
Repairing Design Discussions
On project “Winifred” (Cockburn 1998), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.
As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.
He eventually left and I took his place. To reverse the situation, I arranged for us to design by having conversations at the whiteboard. After some period of doing this, I started getting questions like, “Could you look at the responsibilities (or communication patterns) of these objects?”
By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.
Colocation is considered a critical element in Crystal Clear, a light methodology for small teams. (See “Crystal Clear.”) A rule of Crystal Clear is that the entire team must sit in the same or adjacent rooms, in order to take advantage of convection currents of information and osmotic communications.
Crystal Un-Clear
“Pat” asked me to visit his Crystal Clear project. When I arrived, he wasn’t at his desk. The secretary said he was with his teammate.
I offered to go to that office, but she said, “You can’t. There is a combination lock in the hallway over to that section.”
“!! . . . ?”
Each time a team member wanted to ask a question, he had to stand, walk across the hall, punch in the lock combination, and walk to the teammate’s office. Clearly, this team was not getting the benefit of osmotic communication or the low cost of information transfer. Fortunately, changing the team seating was a simple matter to arrange.
Caves and Common
The “caves and common” room arrangement recommended in XP makes use of all three information-exchange mechanisms. It is shown in action in Figure 3-12 and is diagrammed in Figure 3-13.
“Caves and common” is very effective, but as Tom DeMarco correctly warns, it can easily be abused to become just a programming sweatshop. Therefore, not only the room layout is described in this section but also the social presuppositions that accompany its use: a single project team, good team dynamics, and provision for both private and project space.
The phrase caves and common refers to the creation of two zones in the room. The “common” area is organized to maximize osmotic communication and information transfer. For this to make sense, the people in the room must be working on the same project. It is perfect for XP’s single team of up to 12 people programming in pairs (Figure 3-12).
){kind=small}
Figure 3-12 The RoleModel Software team at work.
(Photo courtesy RoleModel Software)
)
Figure 3-13 The “caves and common” room layout used at RoleModel Software.
(Picture courtesy of RoleModel Software)
The “caves” portion of the room is organized to give people a private place to do e-mail, make phone calls, and take care of their need for separation. In RoleModel Software’s office, private workstations are set up along one wall (Figure 3-12). At Evant, a table came out from the walls on two sides of the room.
People who have worked in “caves and common” facilities say that there needs to be ample wall space for whiteboards and posted flipcharts, and two more types of rooms for the team to use: a food-preparation room and areas for small discussions to take place.
You can see from the picture that while the “caves and common” room is very efficient for transmitting information, it is also very efficient for transmitting coughs and colds. People who work in this sort of room encourage their colleagues to stay home if they don’t feel well and to return after they have recovered.
You can also see that it is drafty (in an information sense): The people sitting in this configuration should really need to overhear each other.
Finally, you can see that it is very effective as long as the morale of the group is good. If the social chitchat degenerates into negative chatter, the highly osmotic communication again magnifies its effect.
Skunk Works
It is useful to compare the above discussions against a group performing classical “engineering,” one of the most effective aero-engineering groups: Lockheed’s “skunk works” team. This team achieved fame for its rapid development of a series of radical new airplane designs in the second half of the 20th century, under the guidance of Jim Kelly and his successor, Ben Rich. Ben Rich wrote about their experiences in the book Skunk Works (1994).
Rich highlights that, among the rules of the group, Kelly insisted on people taking accountability for decisions from design through testing, and on their sitting close together. The following quotation is from that book:
Skunk Works Rooms
“Kelly kept those of us working on his airplane jammed together in one corner of our [building] . . . My three-man thermodynamics and propulsion group now shared space with the performance and stability-control people. Through a connecting door was the eight-man structures group. . . . Henry and I could have reached through the doorway and shaken hands.
“. . . I was separated by a connecting doorway from the office of four structures guys, who configured the strength, loads, and weight of the airplane from preliminary design sketches. . . . [T]he aerodynamics group in my office began talking through the open door to the structures bunch about calculations on the center of pressures on the fuselage, when suddenly I got the idea of unhinging the door between us, laying the door between a couple of desks, tacking onto it a long sheet of paper, and having all of us join in designing the optimum final design. . . . It took us a day and a half. . . .”
“All that mattered to him was our proximity to the production floor: A stone’s throw was too far away; he wanted us only steps away from the shop workers, to make quick structural or parts changes or answer any of their questions.”
Every project team should be on a quest to reduce the total energy cost of detecting and transferring needed ideas. That means noticing and improving the convection currents of information flow, getting the benefits of osmotic communication, watching for sources of drafts, and using information radiators. The end goal is to lower the erg-seconds required for team members to exchange information, whatever constraints their organization places on their seating, and with or without technology.