communicating, cooperating teams - … · 105 3 communicating, cooperating teams this chapter...

105

3

Communicating, Cooperating Teams

This chapter considers the effect of the physical environment, communi-cation modalities used for jumping the inevitable communication gaps,the role of amicability and conflict, and subcultures on the team. Theseissues highlight the fact that projects need people to notice importantevents and to be both willing and able to communicate to others whatthey notice.

“Convection Currents of Information” compares the movement ofinformation to the dispersion of heat and gas. The comparison yieldsseveral useful associations: the energy cost of information transfer,osmotic communication, information radiators, and information drafts.

“Jumping Communication Gaps” examines people’s efficiency in con-veying ideas using warmer and cooler communication channels. It intro-duces the idea of adding “stickiness” to information and looks at howthose two topics relate to transferring information across time.

“Teams as Communities” discusses amicability and conflict, the role ofsmall team victories in team building, and the sorts of subcultures thatevolve on a project. We will see that the differing cultural values are bothuseful to the organization and difficult for the team to deal with.

“Teams as Ecosystems” considers a software development team as anecosystem in which physical structures, roles, and individuals withunique personalities all exert forces on each other. That each project pro-duces its own, unique ecosystem makes the job of methodology designeven more difficult.

12_ASD_ch03.fm 05 Monday, September 25, 2006 11:08 AM

106

Communicating, Cooperating Teams

C

ONVECTION

C

URRENTS

OF

I

NFORMATION

. . . . . . . 107

Delays and Lost-Opportunity Costs. . . . . . . . . . . 107Erg-seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Osmotic Communication . . . . . . . . . . . . . . . . . . . . 111Drafts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Information Radiators . . . . . . . . . . . . . . . . . . . . . . 114Applying the Theory of Hot Air . . . . . . . . . . . . . . 118

J

UMPING

C

OMMUNICATION

G

APS

. . . . . . . . . . . . . . . 121

Modalities in Communication. . . . . . . . . . . . . . . . 121The Impact of Removing Modalities . . . . . . . . . . 124Making Use of Modalities . . . . . . . . . . . . . . . . . . . 125Stickiness and Jumping Gaps across Space. . . . . 127

T

EAMS

AS

C

OMMUNITIES

. . . . . . . . . . . . . . . . . . . . . 129

Amicability and Conflict . . . . . . . . . . . . . . . . . . . . 131Citizenship within Working Hours . . . . . . . . . . . 132Hostile XP versus Friendly XP . . . . . . . . . . . . . . . 133Building “Team” by Winning . . . . . . . . . . . . . . . . 134Team Cultures and Subcultures . . . . . . . . . . . . . . 135

T

EAMS

AS

E

COSYSTEMS

. . . . . . . . . . . . . . . . . . . . . . 139

W

HAT

S

HOULD

I D

O

T

OMORROW

? . . . . . . . . . . . . . 141

12_ASD_ch03.fm Page 106 Monday, September 25, 2006 11:08 AM

Convection Currents of Information •

107

C

O N V E C T I O N

C

U R R E N T S

O F

I

N F O R M A T I O N

Saying that software development is acooperative game of communicationimplies that a project’s rate of progress islinked to how long it takes information toget 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 thatKim knows something useful

•

How much energy it costs Pat andKim together to get the knowledgetransferred to Pat

Let’s see how much this costs a project.

D

ELAYS

AND

L

OST

-O

PPORTUNITY

C

OSTS

A programmer these days costs a com-pany about $2.10 per minute, so addingone minute to getting a questionanswered adds $2.10 to the cost of theproject. Standing up and walking toanother table can add that minute.

Suppose that people who program inpairs ask and get answers to 100 ques-tions per week. Adding that minute’sdelay costs the project $210 per program-mer per week. On a 12-person team, thisis about $2,500 per week for the team,which adds up to $50,000 for a 20-weekproject.

The project gets delayed almost a fullweek and costs an extra $50,000

for eachminute of delay

in getting questionsanswered, not assuming any other damage

to the project for the questions takinglonger to answer!

The delay is more on the order of fiveminutes if a person has to walk down thehall. If Kim is not there, it is likely thatwhen Pat returns to his office, he has lostthe train of thought he was working onand has to spend more time and energyrecovering it.

Even worse, the next time Pat has aquestion, he may decide against walkingupstairs, because Kim might not be there.For not asking the question, he makes anassumption. Some percentage of hisassumptions will be wrong, and eachwrong assumption results in Pat introduc-ing an error into the program. Finding andfixing that error costs the project anythingfrom multiple minutes to multiple days.

Thus, Pat’s not asking his question andgetting it answered represents a large

lost-opportunity cost

. Over the course of theproject, the lost-opportunity cost is fargreater than the cost of walking upstairs.

I hope you palpably feel the project’sdevelopment costs rising in the followingsix situations:

1.

Kim and Pat pair-program on the sameworkstation (Figure 3-1). Pat wonders aquestion out loud, and Kim answers.Or, Kim mentions the answer in passingas part of their ongoing conversation,and Pat recognizes it as useful informa-tion. This takes little work by each per-son and takes the least time toaccomplish.


108

• Chapter 3 COMMUNICATING, COOPERATING TEAMS

Figure 3-1

Two people pair programming.

(Photo courtesy of Evant Solutions Corporation)

2.

Kim and Pat sit at separate work-stations, but right next to each other(side-by-side programming). Usingperipheral vision or the usual chitchatthat develops when sitting closetogether, Kim notices that Pat is look-ing for something on the Web and askswhat the question is. Or, Pat simplyasks. Kim answers, possibly withoutlooking away from the screen. Notmuch work; not much time involved.

3.

Kim and Pat work on opposite sides ofa room, facing away from each other(Figure 3-2). Kim is not likely to noticethat Pat is looking for something, butPat can easily see whether Kim isavailable to answer a question. At thatpoint, Pat asks and Kim answers.

4.

Kim and Pat sit in adjacent offices, sep-arated by a wall. Kim can’t see whenPat is looking for something, and Patcan’t see if Kim is available. Pat mustget up, peek around the door frame tosee if Kim is in, and then ask Kim thequestion.

Figure 3-2

Two people sitting at opposites sides

of the room.

(Photo courtesy of Thoughtworks, Inc.)

5.

Kim and Pat sit on different floors or inadjacent buildings. Pat walks upstairsonly to find that Kim is out! Now Pathas lost time, energy, the train ofthought he was holding while he wasworking downstairs, and the motiva-tion to walk upstairs the next time hehas a question. The lost-opportunitycost starts to mount.

6.

Kim and Pat sit in different cities, pos-sibly with several time zones betweenthem. In this setting, not only will theynot ask each other questions as often,they also will have to use less efficient,less rich communication channels todiscuss the question and its answer.They expend more energy, over alonger period of time, to achieve thesame communication result.

The main question is, if you were fundingthis project, which working configurationwould you like Kim and Pat to use?



109

What we see is that even minor differ-ences have an impact on the rate ofinformation flow.

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.)

Notice, in Figure 3-3, the two different sit-uations occurring at the same time. Thetwo people on the left are pair program-ming. It may be nice for them to have asmall separation from the person on theright. However, if it happened to be thetwo people across the partition whoneeded to work together, the partitionwould soon become a problem. Indeed, Ivisited two people who were workingacross a partition, and it wasn’t longbefore they removed the partition. As oneof them explained, “I couldn’t see hiseyes.”

E

RG

-

SECONDS

Comparing the flow of information withthat of heat and gas is not as far-fetched asit may at first seem. With every speechact, Kim radiates both information andenergy into the environment around her.

That information or energy gets pickedup by people within sight or hearing. Patalso radiates with every speech act.

In his case he radiates his need forinformation. Sooner or later, either Kimdetects Pat’s information need, or Patdetects that Kim has the information.Whichever way the discovery goes, theythen engage in conversation (or Pat readsKim’s document, if Kim’s information isin written form).

In gas-dispersion problems, one ana-lyzes the distance that molecules travel ina certain amount of time. The unit of mea-sure for molecules is

moles

and that fordistance is

meters

; therefore, gas disper-sion is measured in

mole-meters/second

(how many moles of the gas travel howfar, in how much time).

We can analyze the movement ofideas—

memes

, to borrow an appropriateterm from

The Selfish Gene

(Dawkins1990)—using similar terms. We are inter-ested in how many useful memes flowthrough 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 thanthrough space.

What we care about is the amount ofenergy it takes to move a meme from onemind to another. The appropriate unitsare

erg-seconds

. An

erg

is a unit of work(such as walking up the stairs), and a

sec-ond

is a unit of time (such as time spenton the telephone); therefore, the term

erg-seconds

captures the cost in both laborand time to get a question answered.

(Bo Leuf comments that its inverse isalso useful:

argh-minutes

, a measure of the


110


pain of expending energy and

not

manag-ing to convey the idea.)

Figure 3-4

Energy and information moving

through a barrier complex.

Using this metaphor, let’s look at officelayouts to see the energy cost associatedwith detecting that someone else hassome needed information.

Suppose that Kim and Pat sit in officessome distance from each other (Figure 3-4).The walls between them keep Pat fromseeing or hearing Kim. Kim radiatesinformation as she walks around on herdaily travels. The people in her roomdetect the greatest amount of information,and the people in earshot of her move-ment detect the next greatest amount.Information reaches Pat either as Kimwalks into his office, or indirectly,through other people.

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 gasmolecules or convected heat move moreeasily between neighboring rooms, soalso does project information.

If Kim and Pat share an office (Figure 3-5, middle), then just as Pat will smellKim’s perfume sooner than anyone out-

side the office will, so will he notice if Kimradiates information that is useful to him.

Figure 3-5

Gas canisters (or people) in three dif-

ferent configurations.

The greatest rate of information move-ment occurs if they are sitting side byside. In the case of information, the infor-mation transmission is greater if they areworking on the same task, pair program-ming, than if they are merely sitting sideby side, working on different tasks (thishas more to do with their focus of atten-tion than the radiation).

Describing information transmissioncosts in

erg-seconds

captures the effect ofdistance and communication modality onproject costs.

Assume face-to-face communications,sitting in your own office, versus walking50 meters to a colleague’s office. Walkingdown the hall takes work (ergs) and time(seconds). Energy and cost increase, andthe information transfer rate decreases.Move people closer, to the office nextdoor. As the distance decreases, work

Kim

Pat

KimPat

Kim Pat

Kim Pat



111

required to visit the colleague decreases,and so do energy and project cost, whilethe information transfer rate increases.

Similarly, describing an idea on thephone takes more time than describing itin person. In this case, the time factorincreases, and so does cost to the project.

The

erg-seconds

formula accounts forthese changes well.

Of course, the formula does notaccount for wasted energy, such as jump-ing up and down while talking on thephone or walking around the building thelong way in getting to a colleague’s office.It also does not guarantee that two peoplewho work in the same room will everactually understand each other. (See “TheImpossibility of Communication” onpage 8.) What it does say is that projectcosts increase in proportion to the time ittakes for people to understand each other.

O

SMOTIC

C

OMMUNICATION

While writing, reading, typing, or talking,we pick up traces of the ongoing soundsaround us, using some background listen-ing mode even though we are not con-sciously paying attention.

If someone says something interesting,we may perk up and join the conversa-tion. Otherwise, the sound goes throughsome background processing, either justabove or just below our conscious level.

In some cases, we register enoughabout the conversation to be able todevelop what we need directly frommemory. Otherwise, we may recall aphrase that was used or perhaps only

that

a particular person was discussing a par-

ticular topic. In any case, we registerenough to ask about it.

This taking in of information withoutdirectly paying attention to it is like theprocess of osmosis, in which one sub-stance seeps from one system, through aseparator, into another.

Osmotic communication further lowersthe cost of idea transfer.

If Pat and Kim work in the same room,with Pat programming and Kim having adiscussion, Pat may get just enough infor-mation to know that Kim has talkedabout the idea. If multiple people areworking in the same room, then Patknows that someone in the room has theanswer.

We have seen three separate effects thatoffice layout has on communication costswithin a project:

•

The lost-opportunity cost of not ask-ing questions

•

The overall cost of detecting and trans-ferring information (erg-seconds)

•

The reduction in cost when peoplediscover information in backgroundsounds (osmotic communication)

The three magnify the effects of distancein office seating. People who sit close byeach other benefit in all three effects; peo-ple who sit in separate locations suffer inall three.

According to this theory, sponsorsshould think twice before sponsoring ageographically distributed project.

One might think that we now have aneasy answer to the riddle of how to seatpeople: “Obviously, put them into open


112


and shared workspaces.” Unfortunately,people are not so uniform or simple thatthis will work in all cases.

Three more issues affect the answer inany one particular setting:

•

The sort of information being shared

•

People’s personal preferences

•

Drafts

The team members exchange both busi-ness and technical information.

Suppose that Chris is the businessexpert in the group. If Chris, Pat, and Kimsit together, Chris can answer businessquestions as soon as Pat or Kim encoun-ters them. Chris might even see what Patand Kim are doing and guide them in adifferent direction. The three of them canput their heads together at any instant tojointly invent something better than anyone of them could do.

This sort of

radical colocation

(as it hasrecently been called) only works for verysmall teams. Among 12 programmers andfour business experts, who should sitclose to whom? How does one arrangeseating with two-person rooms?

The most common seating arrange-ment I encounter consists of program-mers sitting on one side of the buildingand business experts on the other.

This seating arrangement producestwo problems. The obvious one is the costof business communication, including thelost opportunity cost of missed earlyinterventions.

The second is that each group forms itsown community and usually complainsabout the other group. The chitchat in theosmotic communication is filled with

these complaints, interfering with theability of people in each group to workwith each other in an amicable way.

As is natural with osmotic communica-tion, this emotionally loaded backgroundnoise soaks into each group’s subcon-scious. In this case, it does not educatethem but rather attacks their attitude.Going into a meeting with “those idioticother people,” they don’t give full consid-eration to what the other people say anddon’t offer full information when speak-ing. The group’s amicability suffers, withall the attendant costs just discussed.

My current preference is to find seatingarrangements where one or more busi-ness experts sit close to two or more pro-grammers. Where this is not possible, Ilook for other business and social mecha-nisms that will get the business expert inregular, meaningful collaboration withthe programmers on a frequent (prefera-bly daily) basis.

Cross-specialty teams that worktogether have been recommended by manyauthors. These teams have been givennames such as

Holistic Diversity

(Cockburn1998), CASE teams (Hammer 1994), andFeature teams (McCarthy 1995). When thiscan be done, the project as a whole movesfaster, based on the increase in both infor-mation flow and amicability across special-ties.

Another issue is the matter of people’spersonal preferences.

As I started asking people about work-ing in shared rooms versus in privateoffices, several issues emerged.

Some people really value their quiet,private offices. They value them enoughthat they would feel offended if they had



113

to give them up, some even to the pointthat they would quit the company. If that isthe case, then any gain in communicationis partially lost if the person stays but feelsoffended, and is completely lost if the per-son leaves the company.

Thus, the clear theoretical argumentfor seating people close to the peoplethey need to interact with is affected bypersonal preferences. Several peoplehave told me, “I prefer having my ownoffice, but considering all the projects I’vebeen on, I would have to say that I wasnever so productive as when I shared anoffice with my project mate.” I havemoved out of private offices so often thatI eventually noticed it as a pattern. As Inoticed other experts doing it, it became aproject-management strategy, which I call“Expert in Earshot” (Cockburn 2001a).

The third issue affecting the question ofwhere to seat people concerns drafts.

D

RAFTS

D

RAFTY

CUBICLES

One day, while I was describing this peculiarnotion of convection currents of informa-tion flow, one of the listeners suddenlyexclaimed, “But you have to watch out fordrafts!”

He went on to explain that he had beenworking in a place where he and the otherprogrammers had low-walled cubicles nextto each other and so benefited from over-hearing each other.

On the other side of their bank of cubi-cles sat the call-center people, whoanswered questions on the phone all day.They also benefited from overhearing eachother. But, and here was the bad part, the

conversation of the call-center peoplewould (in his words) “wash over the wallsto the programmers’ area.” There was a“draft” of unwanted information comingfrom that area.

Drafts are the unwanted information in ournewly extended metaphor.

Later, two programmers were talkingabout how their walls were too thin. Theyenjoyed their shared room but were both-ered by their neighbors, who arguedloudly with each other. Their room wasdrafty, in an information sense.

We now have a nice pair of forces tobalance: We want to set up seating clus-ters that increase information flow amongpeople sitting within hearing distanceand balance that against draftiness—theiroverhearing information that is not help-ful to them. You can develop a sense ofthis for yourself as you walk around.

Osmosis across DistancesIs there anything that teams can do to

improve communication if they do not sittogether, for whatever reason?

Charles Herring, in Australia, describesapplying technology to simulate “pres-ence and awareness,” a term used by aresearcher in computer-supported collab-orative work (Herring 2001). Following isa paraphrased summary of theirexperience:

E-PRESENCE AND E-AWARENESS

The people sat in different parts of thesame building. They had microphones andWeb cameras on their workstations andarranged small windows on their monitors,showing the picture from the other peo-ple’s cameras.


114 • Chapter 3 COMMUNICATING, COOPERATING TEAMS

They wanted to give each person a sensa-tion that they were sitting in a group(“presence”) and an awareness of whatthe other people were all doing.

Pat could just glance at Kim’s image todecide if Kim was in a state to be dis-turbed with a question. In that glance, hecould detect if Kim was typing with greatconcentration, working in a relaxedmode, talking to someone else, or gone.

Pat could then ask Kim a question,using the microphone or chat boxes theykept on their screens. They could evendrop code fragments from their program-ming workspaces into the chat boxes.

They reported a low distraction rate.Charles added that while programming,he could easily respond to queries andeven answer programming problemswithout losing his main train of thoughton his own work.

Pavel Curtis and others at Xerox PARCwere able to simulate “whispering”(when a user would like to speak to justone person in a room) through video andaudio. They also had their online chatrooms produce background sounds aspeople entered or left (Curtis 1995).

Because memes (ideas) don’t have totravel through air but travel through thesenses, primarily audio and visual, weshould be able to mimic the effects of con-vection currents of information using high-bandwidth technology. Still missing fromthat technology, of course, are the tactileand kinesthetic cues that can be so impor-tant to interpersonal communication.

INFORMATION RADIATORS

An information radiator displays infor-mation in a place where passersby can seeit. With information radiators, the pass-ersby don’t need to ask questions; theinformation simply hits them as theypass.

Two characteristics are key to a goodinformation radiator. The first is that theinformation changes over time. Thismakes it worth a person’s while to look atthe display. This characteristic explainswhy a status display makes for a usefulinformation radiator and a display of thecompany’s development process does not.

The other characteristic is that it takesvery little energy to view the display. Sizematters when it comes to informationradiators—the bigger the better.

Hallways qualify very nicely as goodplaces for information radiators. Webpages don’t. Accessing the Web page costsmost people more effort than they are will-ing to expend, so the information stayshidden. The following story contributed byMartin Fowler, at Thoughtworks, reportsan exception: This team found that a par-ticular report worked best on a Web page.

AUTOMATED BUILD REPORT

A program auto-builds the team’s systemevery 15 minutes. After each build, it sendse-mail messages to each person whose testcases failed and posts the build statistics toa Web page.

The information about the system isupdated every 15 minutes on the Webpage. Martin reports that a growing num-ber of programmers keep that Web page


Convection Currents of Information • 115

up on their screen at all times and periodi-cally just press the Refresh button to checkthe recent system build history.

Figure 3-6 Hall with information radiators.

(Courtesy of Thoughtworks, Inc.)

The first information radiators I noticedwere at Thoughtworks, while talking withMartin Fowler about Thoughtworks’application of XP to an unusually large (40-person) project (Figure 3-6 and Figure 3-7).

PROGRESS RADIATORS

Martin was describing that the testing group hadbeen worried about the state of the system.

To assuage the testers’ concerns, theprogrammers placed this poster in the hall-way (Figure 3-6) to show their progress.

The chart shows the state of the userstories being worked on in the iteration,with one Post-it note per story. The pro-grammers moved the notes on the graphto show both the completeness and theimplementation quality of the user storiesthey were working on. They moved a noteto the right as a story grew to completionand raised it higher on the poster as itsquality improved. A note might stop movingto the right for a time while it moved up.

Figure 3-7 Status display showing completion level and quality of user stories being implemented.


The testers could see the state of thesystem without pestering the programmers.In this case, they saw that the work was fur-ther along than they thought and soonbecame less worried about the state of theproject.

The best thing was that they could seethe progress of the work daily, without ask-ing the programmers a question.

Just as a heating duct blows air into a hall-way or a heater radiates heat into a room,these posters radiate information into thehallway, onto people walking by. They aremarvelous for passing along informationquietly, with little effort, and withoutdisturbing the people whose status isbeing reported.

A second use of information radiators,suited for any project using increments ofa month or less, is to show the workbreakdown and assignments for the nextincrement (Figure 3-8). The followingexample also comes from Thoughtworks.

12_ASD_ch03.fm 5 Monday, September 25, 2006 11:08 AM


Figure 3-8 Large information radiator wall show-ing the iteration plan, one flipchart per user story.


DISPLAYING WORK BREAKDOWN

The team created a flipchart for each userstory. They put Post-it notes on the flipchartfor the tasks they would need to do for thatstory.

They would move notes below a flip-chart to show tasks being taken out ofscope of the current iteration in order tomeet the delivery schedule.

Evant’s XP team also used whiteboardsand flipcharts as information radiators.Figure 3-9 shows the tasks for iteration“Mary Ann” (each iteration was nick-named for someone on the Gilligan’s IslandTV 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 informationradiators is to show the results of theproject’s periodic reflection workshop(Figure 3-10). During these one- to two-hour workshops, the team discusses whatis going well for them and what theyshould do differently for the next period.They write those on a flipchart and post itin a prominent place so that people arereminded about these thoughts as theywork.

The wording in the posters matters.One XP team had posted “Things we didwrong last increment.” Another hadposted “Things to work on this incre-ment.” Imagine the difference in theprojects: The first one radiated guilt intothe project room and was, not surpris-ingly, not referred to very much by theproject team. The second one radiatespromise. The people on the second teamreferred to their poster quite frequentlywhen talking about their project.

Figure 3-10 Reflection workshop output.

(Courtesy of Joshua Kerievsky, Industrial Logic, Inc.)

Periodic reflection workshops such asthese are used in Crystal Clear and XPprojects.

A fourth use of information radiators isto show everyone the user stories deliv-ered or in progress, the number of accep-tance tests written and met, and so on.(Figure 3-11).

The systems operations team ateBucks.com constructed a fifth use ofinformation radiators, this time to keepthe programmers from pestering them.

DISPLAYING SYSTEM STATUS

The programmers kept asking, “Is system Aup? Is system B up? Is the link to the backend up?”

The maintenance team wrote the statusof each system and link on the whiteboardoutside their area. Each day, they updatedthe status. It looked rather like a ski areaposting the status of lifts and runs (so skiersdon’t keep asking the ski resort staff).

Figure 3-11 Graph showing growing completion.

(Courtesy of Ron Jeffries)



The group at eBucks.com came up with asixth use of information radiators. Thistime it was the programmers who createdthe status displays:

DISPLAYING WORK PROGRESS

The programmers were being asked aboutthe status of their work every hour or two,which caused them no end of frustration.

They wrote on the whiteboard outsidetheir office their intentions for the currentweek. As they completed their tasks, care-fully sized to be of the half-day to two-dayvariety, they marked the tasks complete.

After these boards had been tried by theprogrammers, several other groups startedusing them to broadcast their own prioritiesand progress.

APPLYING THE THEORY OF HOT AIR

People have long applied the above-described “hot air theory of softwaredevelopment.”

Gerald Weinberg discussed the damag-ing effect of removing a soda machinefrom a computer help-desk area (Weinberg1998). Thomas Allen, of MIT’s SloanSchool of Management, discussed theeffect of building design on R&D organi-zations (Allen 1984). IBM and Hewlett-Packard have incorporated such researchin their R&D buildings since the late 1970s.

As a result of these and others’ work, itseems natural that research and develop-ment groups have whiteboards in the hall-ways or near coffee machines. What we

have forgotten, though, is the significanceof actually being within sight and earshotof each other.

Here are several examples. The first isfrom a Crystal Orange project. The secondis from a project unsuccessfully trying toapply Crystal Clear. Next comes a discus-sion of the “caves and common” roomdesign recommended by XP. The finalexample is a success story fromLockheed’s Skunk Works group.

REPAIRING DESIGN DISCUSSIONS

On project “Winifred” (Cockburn 1998),the lead programmer announced at regularintervals that design was unnecessary andthat code simply grew under his fingertips.

As a predictable result, the young pro-grammers working in the room with himalso felt it unnecessary to design. The codelooked that way, too.

He eventually left and I took his place. Toreverse the situation, I arranged for us todesign by having conversations at the white-board. After some period of doing this, Istarted getting questions like, “Could youlook at the responsibilities (or communica-tion patterns) of these objects?”

By setting an audible tone in the roomand making these design discussionslegitimate and valued, the programmersstarted to converse about design together.

Colocation is considered a critical ele-ment in Crystal Clear, a light methodol-ogy for small teams. (See “Crystal Clear”on page 357.) A rule of Crystal Clear is



that the entire team must sit in the sameor adjacent rooms, in order to take advan-tage of convection currents of informationand osmotic communications.

CRYSTAL UN-CLEAR

“Pat” asked me to visit his Crystal Clearproject. When I arrived, he wasn’t at hisdesk. The secretary said he was with histeammate.

I offered to go to that office, but shesaid, “You can’t. There is a combination lockin the hallway over to that section.”

“!! . . . ?”

Each time a team member wanted to ask aquestion, he had to stand, walk across thehall, punch in the lock combination, andwalk to the teammate’s office. Clearly, thisteam was not getting the benefit ofosmotic communication or the low cost ofinformation transfer. Fortunately, chang-ing the team seating was a simple matterto arrange.

Caves and CommonThe “caves and common” room arrange-

ment recommended in XP makes use of allthree information-exchange mechanisms.It is shown in action in Figure 3-12 and isdiagrammed in Figure 3-13.

“Caves and common” is very effective,but as Tom DeMarco correctly warns, itcan easily be abused to become just a pro-gramming sweatshop. Therefore, not onlythe room layout is described in this sec-tion but also the social presuppositionsthat accompany its use: a single projectteam, good team dynamics, and provisionfor both private and project space.

The phrase caves and common refers tothe creation of two zones in the room. The“common” area is organized to maximizeosmotic communication and informationtransfer. For this to make sense, the peo-ple in the room must be working on thesame project. It is perfect for XP’s singleteam of up to 12 people programming inpairs (Figure 3-12).

Figure 3-12 The RoleModel Software team at work.

(Photo courtesy RoleModel Software)



Figure 3-13 The “caves and common” room lay-out used at RoleModel Software.

(Picture courtesy of RoleModel Software)

The “caves” portion of the room is orga-nized to give people a private place to doe-mail, make phone calls, and take care oftheir need for separation. In RoleModelSoftware’s office, private workstations areset up along one wall (Figure 3-12). AtEvant, a table came out from the walls ontwo sides of the room.

People who have worked in “cavesand common” facilities say that thereneeds to be ample wall space for white-boards and posted flipcharts, and twomore types of rooms for the team to use:a food-preparation room and areas forsmall discussions to take place.

You can see from the picture that whilethe “caves and common” room is veryefficient for transmitting information, it isalso very efficient for transmitting coughs

and colds. People who work in this sort ofroom encourage their colleagues to stayhome if they don’t feel well and to returnafter they have recovered.

You can also see that it is drafty (in aninformation sense): The people sitting inthis configuration should really need tooverhear each other.

Finally, you can see that it is very effec-tive as long as the morale of the group isgood. If the social chitchat degeneratesinto negative chatter, the highly osmoticcommunication again magnifies its effect.

Skunk WorksIt is useful to compare the above discus-

sions against a group performing classical“engineering,” one of the most effectiveaero-engineering groups: Lockheed’s“skunk works” team. This team achievedfame for its rapid development of a seriesof radical new airplane designs in the sec-ond half of the 20th century, under theguidance of Jim Kelly and his successor,Ben Rich. Ben Rich wrote about their expe-riences in the book Skunk Works (1994).

Rich highlights that, among the rules ofthe group, Kelly insisted on people takingaccountability for decisions from designthrough testing, and on their sitting closetogether. The following quotation is fromthat book:

SKUNK WORKS ROOMS

“Kelly kept those of us working on his air-plane jammed together in one corner ofour [building] . . . My three-man thermo-dynamics and propulsion group now sharedspace with the performance and stability-control people. Through a connecting doorwas the eight-man structures group. . . .


Jumping Communication Gaps • 121

Henry and I could have reached throughthe doorway and shaken hands.

“. . . I was separated by a connectingdoorway from the office of four structuresguys, who configured the strength, loads,and weight of the airplane from preliminarydesign sketches. . . . [T]he aerodynamicsgroup in my office began talking throughthe open door to the structures bunchabout calculations on the center of pres-sures on the fuselage, when suddenly I gotthe idea of unhinging the door between us,laying the door between a couple of desks,tacking onto it a long sheet of paper, andhaving all of us join in designing the opti-mum final design. . . . It took us a day and ahalf. . . .”

“All that mattered to him was our prox-imity to the production floor: A stone’s

throw was too far away; he wanted us onlysteps away from the shop workers, to makequick structural or parts changes or answerany of their questions.”

Every project team should be on a quest toreduce the total energy cost of detectingand transferring needed ideas. That meansnoticing and improving the convectioncurrents of information flow, getting thebenefits of osmotic communication, watch-ing for sources of drafts, and using infor-mation radiators. The end goal is to lowerthe erg-seconds required for team membersto exchange information, whatever con-straints their organization places on theirseating, and with or without technology.

JU M P I N G CO M M U N I C A T I O N GA P S

To make communications as effective aspossible, it is essential to improve the like-lihood that the receiver can jump the com-munication gaps that are always present.The sender needs to touch into the high-est level of shared experience with thereceiver. The two people should provideconstant feedback to each other in thisprocess so that they can detect the extentto which they miss their intention.

MODALITIES IN COMMUNICATION

Imagine a simple discussion at the white-board. How many communication mech-anisms are at play? Consider these 11:

Physical proximity. Standing about onemeter from each other, the people detect

minute visual cues, tiny movements ofeye muscles to overall muscle tension.

The speaker may move closer to indi-cate aggressiveness or enthusiasm. The lis-tener may move closer to indicate interest,agreement, or the desire to speak; or, thelistener may move away to indicate fear,disagreement, or the need to think pri-vately for a moment. The speaker and lis-tener manipulate their relative distance toexpress various emotions and stages ofagreement, disagreement, aggressiveness,trust, and distrust.

The signals vary across cultures andpersonalities, but the signals are bothpresent and used.

Three-dimensionality. The people noticevisual parallax, or 3D information.



The parallax shift of the visual image islost when the same people talk over avideo link, even if they are similarly closeto the camera and screen.

Smell. Smell is one of those senses that isunimportant to some people, very impor-tant to others, and important but subcon-scious to many.

One person reported that she can oftensense sublimated fear and distress, proba-bly through sense of smell. It certainly isthe case that those cues are available atthe whiteboard and are lost in remotecommunications.

Kinesthetics. Many people use kinesthet-ics (sensation of movement) to help themthink and remember. The speaker mightuse it to help construct a new explanationor to help improve the building of aquestion.

Touch. One person touches another onthe shoulder to mean “Don’t feel threat-ened by this discussion” or perhaps “Thisis really important” or “I have somethingto say.”

Touching is part of the overall manipu-lation of proximity and personal space. Insome cases there are objects to touchwhose feel is important to the conversa-tion.

Sound. In the simple use of language, aspeaker emphasizes points with colorfuladjectives, exaggerations, metaphors, andthe like.

Besides that simple use of language,the speaker uses pitch, volume, and pac-

ing to differentiate and emphasize ideasin a sentence.

Visuals. People communicate throughgestures as well as words, often making apoint by gesturing, raising an eyebrow, orpointing while speaking.

The people may wave their hands tomake shapes in the air or to accentuatethe speaking. They may raise an eyebrowto indicate questioning or emphasis.

Again, they use pacing to differentiateand emphasize ideas—for example, mov-ing rapidly over obvious parts of a draw-ing and slowing down or pausing foreffect at less obvious or more importantparts.

A person also draws on the whiteboardto present (particularly spatially oriented)information for the other to consider. Thedrawings may be standardized notations,such as class or timing diagrams. Theymay be loose sketches. They may even besquiggles having no particular meaning,whose sole purpose is to anchor in a pub-lic, static location the thought beingdiscussed for later reference.

Cross-modality timing. One of the mostimportant characteristics of two people atthe whiteboard is the timed correlation ofall of the above.

The speaker moves facial muscles andgestures while talking, draws while talk-ing and moving, pauses in speech foreffect while drawing, and carefullyannounces key phrases in time, whiledrawing lines between shapes.

Cross-modality emphasis helps anchorideas in the listener’s mind, enhancingthe memory associations around the idea.



Drawing otherwise meaningless squig-gles on the board while talking givesmeaning to the squiggles—meaning thatthe speaker and listener can later refer to.

Low latency. Because the two are standingnext to each other, watching and listeningto each other, the round-trip time for a sig-nal and a response is very small. Thisallows real-time question and answer, andinterruptions:

• Real-time question-and-answer. The recei-ver asks questions to reveal ambiguityand missed communication in thespeaker’s explanation. The timing ofthe questions sets up a pattern of com-munication between the people.

• Interruptions. With the very fast round-trip times available in face-to-face com-munication, the listener can interruptthe speaker, asking for clarification onthe spot. During the course of conver-sation, the speaker may be able to tunethe presentation to fit the receiver’sbackground. The listener can give thespeaker feedback in the middle of theexpression of an idea, perhaps through araised eyebrow or other nonverbalmodality. The speaker can then adjustthe expression on the fly.

Trust and learning. Through modalitiesand rapid feedback, two people are likelyto develop a sense of comfort and trust incommunication with each other.

This is comfort and trust of the form,“Oh, when he speaks in that tone of voicehe is not actually angry, but just excited.”The two find ways to not hurt each other

in communication and to know that theywill not be hurt in the communication.

They build small emotional normaliz-ing rituals of movement and expression toindicate things like “I’m starting to feelattacked here” and “You don’t need to,because this is not an attack on you.”

Those rituals serve the people well overthe course of the project, particularlywhen they can’t see each other during thecommunication. At that juncture, touch-ing into the shared experience of these rit-uals becomes crucial.

You see an example of the need forthese normalizing rituals in the amount ofairplane travel going on:

FLYING PLACES TO BE THERE

A senior executive of a video communica-tions firm returned to San Jose from Lon-don. It was her second trip in 10 days, eachbeing for a single meeting.

The astonishment for us was that sheobviously had access to state-of-the-art vid-eoconferencing facilities and yet felt that shecould not conduct her business over thevideo link. Her meetings still required thelowest-latency, richest, multimodal commu-nication possible: “in person.”

We decided that it is easy to start nego-tiations over the phone or Internet but diffi-cult to bring them to conclusion that way.

Use of a shared, persistent informationradiator. The whiteboard holds thedrawn information in place, while wordsdissolve in the air. The people can all seethe board, draw on the board, and refer tothe board just minutes later in theconversation.



THE IMPACT OF REMOVING MODALITIES

What happens when you remove some ofthose mechanisms and go to other com-munication settings?

Remove only physical proximity. Withpeople at opposite ends of a video link,the visual and temporal characteristicsshould be very much the same as being inperson.

Somehow, though, they aren’t, as wit-nessed by the video communicationsexecutive who still flew to London forsingle meetings.

My teammates, in Lillehammer, and I,in Oslo, often found that we made designprogress only when we took the train triptogether. Even walking to the train stationtogether was a more effective design envi-ronment for us than talking over ourvideo link.

Remove the visuals (use a telephone).Removing visuals also removes cross-modality timing. You lose the drawings,the gestures, the facial expressions, sightof the muscle tone, proximity cues, andthe ability to link speech with action.

Remove voice (use e-mail). With this, youlose vocal inflection, the ability to pausefor effect, to check for interruptions, tospeed up or slow down to make a point, toraise your tone or volume to indicate sur-prise, boredom, or the obviousness of thetransmitted idea.

Remove the ability to ask questions(but possibly reinstate one of the abovemodalities). Without the questions, thesender must guess what the receiverknows, doesn’t know, would like to ask,and what an appropriate answer to theguessed question might be—all withoutfeedback.

Now, the sender really doesn’t knowwhat the receiver needs to hear, where thecommunication gaps are too wide, orwhere the shared experience lies. (This, ofcourse, applies to me, communicating withyou. How many words—which words—do I need to spend on this idea?)

Finally, remove almost everything. Re-move visuals, sound, timing, kinesthetics,cross-modality timing, question-and-answer, and you get . . . paper.

How surprising it is in retrospect thatmost projects require documentation inthe least effective communication formatpossible! The person who is trying tocommunicate a design idea must guess atwhat will work for the reader, does notget to use timing, vocal, or gestural inflec-tions, and gets no feedback along the way.

With this view in mind, it is not sur-prising that the busiest and best projectteam leaders say:

“Put all the people into one room.”

“Don’t give me more than four peo-ple; that’s all I can get into one roomand talking together.”

“Give me printing whiteboards, andkeep all the rest of your drawingtools.”



“Make sure there are whiteboardsand coffee corners all over thebuilding.”

The above are standard recommendationsamong successful project leaders, whocount on using the highest communica-tion mode: people, communicating face toface.

The discussion of communicationmodalities matches the findings ofresearchers, such as McCarthy and Monk(1994).

MAKING USE OF MODALITIES

The graph in Figure 3-14 serves to capturethe above discussion visually. In thegraph you see two sets of situations: thosein which question and answer are avail-able and those in which they are not.

The horizontal axis indicates the “tem-perature” of the communication channel.Warmer indicates that more emotionaland informational richness gets con-veyed. E-mail is cooler than audio or vid-eotape, and two people communicatingface to face is the hottest channel.

Figure 3-14 Effectiveness of different modes of communication.

What we see in the graph is communica-tion effectiveness rising with the richness(temperature) of the communicationschannel. Two people at the whiteboardare using the richest form.

The graph provides an idea about howto improve the effectiveness of archivaldocumentation:

VIDEOTAPED ARCHIVAL DOCUMENTATION

Have the designer give a short, 5- to 15-minute description of the design to one ortwo colleagues who are not familiar withthe work. These one or two will act asombudsmen for the viewers of the video-tape. While the designer leads the discus-sion, the colleagues interrupt and askquestions as they need to.

Videotape the discussion. At the end, capture and print the exam-

ples and drawings used in the discussion, toact as mnemonic anchors of the discussion.

You might consider posting the talkonline, where others can access it usinghyperlinked media.

Lizette Velasquez, of Lucent Technolo-gies, reported that not only had shealready used that technique with success,but she added that I had forgotten some-thing important:

It is also important to mark and indexplaces where “something interesting hap-pened.”

While much of the discussion proceedsat a relatively slow pace, occasionally aquestion triggers a flurry of significantdiscussion, and the viewers will want torefer to those sections.



Several people report that they havevideotaped talks on their project, but weare missing experiments telling us aboutthis technique in actual use: how to set upthe room, how long the discussion can be,what sort of person should be used for theombudsman. Most of all, I am still wait-ing for someone to perform this experi-ment and then, six months later, reflect onwhether this was a good idea and whatwould make it better.

If you are willing to try out this experi-ment, please let me know these details:what you did, what happened, and whatyou thought about it months later.

As a thought experiment about the util-ity of the graph and the experiment, con-sider the book Design Patterns (Gamma1995). This book is excellent but difficult. Istill have trouble understanding the pat-terns that I have not yet used. I supposethat others have similar difficulties. Imag-ine that instead of trying to extract themeaning of the patterns from the book,you could see one of the authors explain-ing the pattern in a video clip. Theauthors would, of course, rely on tonalinflections, gestures, and timing to get theidea across. I’m sure that most peoplewould understand those difficult patternsmuch more easily.

The lesson is that we should try to moveteam communications up the curve as faras possible, for the situation at hand. Weshould rely on informal, face-to-face con-versation, not merely tolerate it. Face-to-

face communication should become a corepart of your development process.

There is a second lesson to pay attentionto. Sometimes a cooler communicationchannel works better, because it containsless emotional content.

COOLER COMMUNICATIONS NEEDED

A project leader told me that her teamdeals better with her when they speak overthe phone, because she is too aggressivewith her emotions in person.

A married couple told me that they com-municated in a more “even” and less emo-tional level over the phone than in person,just because the face-to-face setting floodedthem with visual and emotional cues.

Hovenden (2000) describes a meeting inwhich a senior designer ruined a meeting’soriginal plan by standing up and taking overthe whiteboard for the rest of the meeting.In this case, the lack of anonymity created asocial ranking that interfered with theintended meeting.

Bordia and Prashant (1997) describe thatbrainstorming improves when social rankinginformation is hidden from the participants.

McCarthy and Monk (1994) remind usthat e-mail has the advantage of allowingpeople to reread their own messagesbefore sending them, thereby giving them achance to clarify the message.

Thus, warmer communications channelsare more effective in transferring ideas,but cooler communications channels stillhave important uses.



STICKINESS AND JUMPING GAPS ACROSS SPACE

You can see, at this point, how the team ofRussian programmers got low cost peridea transferred (“The Russian Program-mers” on page 13). Sitting in a roomtogether, they got convection currents ofinformation, osmotic communication, face-to-face communication, and real-timequestion and answer.

So why did they need to write use casesat all?

The answer is: To give the informationsome stickiness. Information that isrecorded on paper has a sort of sticki-ness—or permanence—that the informa-tion in a conversation doesn’t, a stickinessyou sometimes want.

The person who went to Russia withthe use cases wanted to make sure that hedid not forget what he was supposed tocover in his conversations. He wanted tomake sure that after he explained the usecases to the Russian programmers, theycould subsequently read the use cases,understand them, and recall the informa-tion without having to ask him again.

Figure 3-15 Two people working at a shared, sticky information radiator.


The use-case writer, knowing that theuse cases were only game markers toremind them of what they already knewor had discussed, could balance the timehe spent writing the use cases against thetime that would be spent discussing othermaterial. He could decide how muchdetail should go into the writing.

Large, sticky, revisable shared informa-tion radiators are often used by people toachieve greater understanding and toalign their common goals. Figure 3-15 andFigure 3-16 show a useful mix of white-boards (static information radiators) andpeople (dynamic information radiators).

Both whiteboards and paper are partic-ularly good static information radiatorsand can be written on by all parties, mak-ing them shared, sticky information radiators.

Until recently, archivability and porta-bility were still problems with white-boards. If a discussion results in reallyvaluable information being placed on thewhiteboard, no one dares erase it, and thegroup can’t archive it. This slows thearchiving of valuable information andshuts down the board for the next use. As

Figure 3-16 Dynamic and static information radi-ators at work.




Ron Jeffries put it, “If you never erase thewhiteboards, you might as well write onthe walls.”

A colleague, Mohammad Salim,responded to this situation by covering allthe walls and hallways with rolls ofbutcher paper so that people could liter-ally draw on the walls wherever theywere. He said, “If you have to take time towalk to a workstation or find a blankwhiteboard, you just lost your idea.” Hecontinued, saying that when a section ofpaper gets full, to just roll it up and dateit. That way all discussions are archivedand can be pulled out for later examina-tion. In his description of finding rolls ofpaper for later examination, he made useof the fact that humans are good at look-ing around, as discussed in the last chap-ter. He also worked hard to reduce thecost of invention and communicationwhile preserving archivability for laterdiscussions.

A number of people report that theyare using digital cameras in conjunctionwith software that cleans up the image(“Whiteboard Photo” at www.pixid.comis one that they refer to). Printingwhiteboards continue to be very practical.Often, people start a discussion thinkingthe outcome will not be significant but seeat the end that the whiteboard holds valu-able information. With a printing white-board, they can simply push the Printbutton if they wish.

Different information radiators aresuited for different sizes of discussiongroups, of course. A piece of paper worksfor two or three people; a whiteboardworks for perhaps a dozen.

Recalling these differences will serve uswell when we consider methodologies fordifferent projects, in the next chapters.

STICKING THOUGHTS ONTO THE WALL

On one project, the business analysts werefrustrated because their work was growingmore and more interdependent. At thattime they had no way of holding theirthoughts in clear view, and still, while plan-ning their joint work.

We held a discussion about cooperativegames, game markers, and stickiness. Thepeople saw that creating a large, persistentand revisable display of their mental terri-tory would help them do their work. Oneof them immediately posted a picture ofthe domain on the corridor wall as a start-ing point.

They worked on it over the weeks,experimenting with representations of theirconcerns that would allow them to viewtheir mutual interdependence.

There is an interesting and relevant asideto mention about this group, having to dowith expectations and citizenship. Forreasons I won’t go into, this team of busi-ness analysts thought they were sup-posed to work in the XP style and that XPprohibited them from writing thingsdown.

Notice four things about their situation:

1. They misunderstood XP. It does notforbid people to write things down.

2. Their citizenship was so strong thatrather than be poor citizens and writedown their thoughts on the domainmodel, they chose to be good citizensand not write down their businessmodel at all!


Teams as Communit ies • 129

3. Actually, they knew that the projectwouldn’t succeed if they really wrotenothing down. So they each clandes-tinely wrote pseudo use cases andother notes, which they passed to theprogrammers. They still did not createa domain model for themselves.

4. By writing down those notes, theysubverted their own (mistaken) inter-pretation of the official process. I findthis situation particularly interesting,because they were at war with them-selves about whether to be good citi-zens and follow the process (at theexpense of the project) or to be goodcitizens and protect the project (by vio-lating the process).

What was significant in the end was thatthey posted an information radiator onthe corridor wall, on which they scribbledindividually and as a group, to give theirthoughts and decisions some stickiness.

Jumping Gaps across TimeFinally, let us look at communicating

across time and the twist that lies in storehere.

You might expect, after the precedingdiscussion, that to preserve informationacross time you would definitely dropreliance on face-to-face communication infavor of paper, audiotape, and videotape.

However, on long-running projects, itturns out to be critically important thatthe chief architect stay around! This per-son’s contribution is to keep memories ofkey ideas alive on changing developmentteams. Once again, people are used as thearchival medium!

Individual people transfer informationeffectively across both time and space. Asan IBM Fellow put it, while talking abouttechnology transfer, “The way to geteffective technology transfer is not totransfer the technology itself but to trans-fer the heads that hold the technology!”

TE A M S A S CO M M U N I T I E S

We have looked at what it takes for some-one to notice something of value on aproject and what it takes for someone tocommunicate something of value. It is timeto consider whether a person cares tonotice and communicate anything.

On an effective team, the people pullapproximately in the same direction.They actually all pull in slightly differentdirections, according to their personalgoals, personal knowledge, stubbornness,and so on (Figure 3-17). They worktogether at times and against each other attimes. The directions are more closely

aligned on a more effective team thanthey are on a less effective team.

You can create a large overall effect onthe project by eliciting small changes ineach person’s behavior. This is “micro-touch” intervention: getting people tomake changes they don’t mind making, inways that get amplified by the number ofpeople on the project. As each personpulls in a direction closer to the desiredand common direction, the changes felt byany one individual are small but the com-posite effect is large (Figure 3-18).



Figure 3-17 An average team working to pull toward a goal on the right.

The small changes come from peoplebeing given

• Additional information about thedirection in which they should pull

• Additional information about theeffects of their actions so that theynotice which actions pull in a differentdirection

• A better reason to pull in the desireddirection

The result is that people start contributingto each other’s work as opposed to ignor-ing or accidentally working against eachother.

With small changes like these, peoplesee greater project output for similaramounts of energy and without having tolearn major techniques or philosophies.As they notice this, they develop greaterpride in their work and more trust in eachother. Usually, morale improves, and theproject team becomes a better communityin which to live.

The Project Priority ChartThe project priority chart is one simple

mechanism that every project team shoulduse to help align team members’ effort.

Figure 3-18 A slightly better aligned team.

This chart is also described in AdaptiveSoftware Development (Highsmith 2000)and Crystal Clear (Cockburn 2005).

At the start of the project, the executivesponsors and the developers discuss andwrite down the single aspect of the devel-opment that everyone should attend to. Itmay be time-to-market, defect reduction,response time, ease of learning to use,speed of expert usage, memory used,extensibility, or ease of maintenance. Theymay write a second one, such as time tomarket and ease of casual use.

They then select, from among all theother desirable characteristics the teamshould strive for, those three or four thatthe team should be willing to sacrifice inorder to achieve the main two.

From this exercise, each person seeswhat sorts of trade-offs are permitted onthe project and how to prioritize theiractions. With a modicum of goodwillbetween team members, simply writingthe choices down in a joint meeting andreferring to it periodically gets goal align-ment close enough.

The project priority contract addressesa common problem: The executive spon-sor wants the software out soon (to hit amarket window), but the programmers



want to “design it right” (delaying theiroutput to improve the design aesthetics).Or the reverse may be true: The program-mers are used to working fast and sloppyto hit market windows, and the sponsorswant them to take more time and makefewer mistakes. In these cases, the entireorganization suffers for a simple, correct-able miscommunication of the desiredpriorities (assuming that the rewardstructures in place align with the priori-ties being requested).

Sometimes the priorities need tochange in the middle of a project. Forexample, a competitor may come out witha new product. At that instant, it maybecome important to reverse priorities,shifting from development speed todefect freedom or vice versa. Should thishappen, the sponsors should get the teammembers together again and announcethe shift in priorities.

AMICABILITY AND CONFLICT

Amicability is the willingness of people tohear the thoughts of another person withgoodwill and to speak without malice.

Amicability is the weaker cousin totrust. Trust is wonderful and should benurtured, but amicability is easier toachieve within a group and still confersadvantages. I always watch the amicabilitylevel in an organization to learn to whatextent information is being revealed ver-sus concealed in conversations.

When people conceal information fromtheir colleagues, they lower the rate ofinformation discovery, which raises thelost-opportunity cost as well as the over-all cost per idea developed.

Amicability permits successful conflictto occur when the project goes through astressful period. The people, knowingthat the others are not intending to behurtful, can look past the current dis-agreement toward resolving the issues.

One might think that removing all con-flict from a project team would be thebest, but that turns out not to be the case.People need to be able to disagree, inorder to identify design problems! I wassurprised to find one organization thatsuffered from too little conflict:

NOT ENOUGH CONFLICT

In a church organization I visited, each staffmember was employed for as long as shewished. The group cherished virtues ofhumility, peacefulness, and amicability. Theunsuspected negative effect that accumu-lated was the absence of both disagree-ment and initiative!

Each person would think twice (ormore) before criticizing someone else’sidea, for fear of being seen as seeding dis-cord or of disrupting the group. Peoplewould also think twice (or more) beforetaking initiative, lest they be consideredglory-hungry or power-hungry.

The net result was that projects movedvery slowly.

Before you start offering suggestions forthis group, recall the values of the group.They will improve their development prac-tice only when they can find ways to dis-agree without jeopardizing their values ofhumility and amicability.

Schrage (1999) describes the intentionaluse of small doses of conflict to get peopleto meet and learn to talk with each other.This is like introducing a weakened form



of a virus so that the body can build waysof handling the stronger virus:

DELIBERATE CONFLICT

“[A]ccording to some reports, engineers onthe 777 design-build teams deliberatelyintroduced conflicts with other systems intotheir proposed designs.

“. . . Although Boeing officially acknowl-edges only that interferences naturallyevolved, according to at least one mechani-cal engineer, some of those interferenceswere intentional. Why? So that engineers inone part of Boeing could use the interfer-ence to find the people in other parts ofthe company with whom they needed todiscuss future design issues. . . . [T]he soft-ware’s ability to notify appropriate partiesabout interferences became, at least insome instances, a tool to forge interactionsbetween various groups within Boeing.

“. . . The resulting conversations andnegotiations resolved design conflicts beforemore serious problems could emerge.”

CITIZENSHIP WITHIN WORKING HOURS

Good citizenship is a matter of acting inways that benefit others. Citizenship isillustrated by people

• Getting to meetings on time• Answering questions from other

people• Bothering to mention things that they

notice• Following group coding conventions• Using code libraries

Citizenship permits programmers whodisagree about coding styles to nonethe-less create a common coding standard for

themselves. As many lead programmershave said, “It’s not what I would like, butI recognize that many ways work, andselecting any one of them is better thannot selecting any at all.”

Helping other people in the company isa characteristic of citizenship. Dixon (2000)reports on the strong effect of taking timeto help other people. She cites, amongmany examples, a woman at TandemComputers who was asked about takingaway from her work time to answer ques-tions posted on the corporate discussionboards. The woman responded, “Answer-ing questions like this is part of being agood company citizen.”

I often find that workers show citizen-ship and sacrifice from the moment theystart work, and management takes toomuch advantage of it. People join a newcompany and work overtime, thinkingthat after they contribute this extra workthe company will respond in kind andgive them more recognition and time off.What they don’t realize is that theirbosses and colleagues assume that how-ever they work in the first month is howthey will work and act forever. As a result,people regularly get poor evaluations fordropping their working hours from 65down to a mere 50!

I am afraid that managers will use thepretext of good citizenship to coerce peo-ple into working yet more overtime. ReadDeath March (Yourdon 1997) for examplesof this.

Citizenship should be encouragedwithin normal working hours, not as ameans of lengthening normal workinghours. There are plenty of ways in whichto apply citizenship within working hours.



HOSTILE XP VERSUS FRIENDLY XP To round out this discussion, let’s look atthe consequences of working with andwithout attention to community. I chooseto discuss Extreme Programming (XP),because although communication andcommunity are core values within XP, Ihave seen it practiced with and withoutthat community: “friendly” XP and “hos-tile” XP, as it were. The difference isprofound.

The three following situations are somein which customers and programmersmight magnify their differences and cre-ate a hostile XP environment:

• The customers are not quite sure whatthey want. The programmers insist,“Tell us what to build,” so the custom-ers say something. The programmersbuild exactly that and then say, “Tellus what to build next.”

In this situation, neither group is reallysure what the correct thing is to buildnext. The programmers escape the pres-sure of the situation by shifting the bur-den over to the customers (which they areallowed to do). The customers experiencethe situation as unsettling: There is littletime to reflect, examine, experiment, andsort out options.

As a result, the customer’s instructionsover the course of succeeding iterationsconflict with each other: “Build this. . . .No, now build this. . . . No, try buildingthat now.” Both parties become depressedabout the lack of clear progress.

• The programmers do whatever thecustomers say, even if they are surethat the idea is silly.

As with the story “Not Enough Conflict,”a project suffers when the developersdon’t mention problems they notice. Theproject loses the creative interplay ofsharp programmers offering their insightsto refine the requests of the customers.

• The customers tell the programmersthat a particular feature will be com-ing up and ask if the programmerswill please design the system to han-dle that gracefully. The programmerscite a series of the XP mantras: “Keepit simple,” “You aren’t gonna need it,”“We’ll do the simplest thing that willpossibly work,” and they ignore anysuggestion of what to build into thesoftware.

The consequence is that the designers runthrough a sequence of designs everyoneknows are incorrect, until the criticalrequirements finally appear. By then, timehas been spent redesigning the systemseveral times. In the cases I have encoun-tered, the programmers were happy aboutthe exercise and the sponsors wereunhappy.

In each of these cases, the programmerswithheld information. Withholding theirown thoughts and experience from thediscussion, they abdicated responsibilitytoward the overall project. By doing so,they damaged the project by concealingfrom view superior developmentstrategies.



In friendly XP, practiced with commu-nity, the three situations play out differ-ently. In each case, the programmersactively share their views, experiences,cost estimates, and solutions.

• In the first situation, not knowingwhat to build next, the programmershelp the customers gain experience invoicing what they want. They can dothis by producing small working pro-totypes tailored to discovering thedesired characteristics.

• In the case of the silly idea, the pro-grammers volunteer their informationthrough amicable dialogue: “I’m notsure you really want this thing youasked for. It will be so-and-so difficultto implement and has the followingroll-on effects.” The customer mightstill request the feature, but quiteoften, the person had no idea aboutthose effects and is happy to havethem mentioned. Usually, customersappreciate the insights, whether ornot they change the request.

• In the story-sequencing situation, theprogrammers help the customers byfinding those story cards that affectthe decisions in question. They canthen jointly consider in which orderthe cards should be tackled. The neworder might not simply ask for morefunctionality along a business-valuetrajectory but might converge morequickly on the actual system the cus-tomers want.

Any development methodology, even onethat advocates amicability and community,can be practiced without it to the detri-ment of the project.

BUILDING “TEAM” BY WINNING

Team spirit was once built through sing-ing company songs and attending com-pany functions. (Any of you still haveyour IBM songbook?) When singing onthe job went out of style, nothing immedi-ate took its place.

Some companies start projects with oneor several days of offsite team building.This is good, even if it is good mostlybecause the people recognize the effortthe company is putting forth to show thatteamwork is important. Although notevery team-building exercise actuallybuilds a team, a number of successfulteams have pointed to their team-build-ing days at the start of the project as hav-ing helped them work together moreeffectively. As a result, their companyleaders consider the money well spentand plan on continuing the tradition.

Programmers give mixed reviews tooutside-of-work team-building exercises.Several said, roughly, “I’m not interested inwhether we can barbeque together orclimb walls together. I’m interested inwhether we can produce softwaretogether.”

What does build teams? Luke Hohmannoffered this observation in an e-mail note:

“The best way to build a team is byhaving them be successful in pro-ducing results. Small ones, big ones.It doesn’t matter. This belief has



empirical support; see, for instance,Brown (1990). Fuzzy team buildingis (IMO) almost always a waste oftime and money.”

Support for this is also found in Weick’sdescription of the importance of “smallwins” (Weick 2001) as well as in inter-views of successful project managers.

One successful project manager told ofa key moment when the project moraleand “team”-ness improved. We found thefollowing elements in the story:

• The people, who sat in different loca-tions, met each other face to face.

• Together, they accomplished some sig-nificant result that they could not haveachieved without working together.

• At some point, they placed them-selves in some social jeopardy (ven-turing new thoughts, or admittingignorance) and received support fromthe group when they might have beenattacked.

The second of those characteristics is“producing results,” as Luke Hohmannmentions. The first and the third buildamicability, the positive absence of fearand distrust.

TEAM CULTURES AND SUBCULTURES The project team itself creates a mini-culture. That mini-culture sits within theculture formed within the larger organiza-tion and also within the dominant nationalculture around it.

Often, the programming project endsup with its own culture, different from thenational or corporate cultures in which itis embedded. People on the project findthis useful, because they have a greaterneed to trade information about what isworking and what is about to break.

Sometimes, the wider organization tol-erates this different culture, and some-times it fights back. One person who hadexperienced the resistance wrote, “Watchout for the organizational antibodies!”

Cultures and their values can be char-acterized in many ways. In one character-ization (Constantine 1995), sociologistsname four culture types by their commu-nication, power, and decision-makinghabits (Figure 3-19). These four culturetypes are described in the following para-graphs:

Hierarchical cultures have the tradi-tional top-down chain of command. Typi-cally, older, larger corporations have ahierarchical culture. Many people inter-nalize this as the dominant or natural ordefault corporate culture as they grow up,and they have to be trained away from it.

Figure 3-19 Four organizational paradigms.



Random is the opposite of hierarchical. Itindicates a group in which there is little orno central control. Many start-up compa-nies work this way. Some people considerrandom a fun way to work and regret theloss of the small, informal group whenthe company grows. Others find it stress-ful, because there are no clear points ofcontrol.

Collaborative groups work by consen-sus. I had the opportunity to encounter acollaborative group in action at LucentTechnology:

CONSENSUS CULTURE AT WORK

Someone in the organization decided thatuse cases would be a good way to capturerequirements and asked me to teach acourse to the people on a project.

I met the team leads (who are actuallycalled coaches, because in a collaborativeculture they don’t lead, of course, theycoach).

About a month later, I was called toteach it again, for more of the group.

Several months after that, I was asked tolecture one last time, for the entiredepartment. Even though the coach haddecided that use cases were good, the groupwas not going to use them until they had allhad a chance to see and understand them.

The behavior of the coach in the finalmeeting was interesting: He programmedon his laptop while I taught. He was physi-cally present in the room, but just barely. Farfrom being insulting, I found his actions fullyappropriate in light of the value systems inplay around his situation. As a senior devel-oper, he demonstrated that he was stillcontributing directly to the team’s work. Asa coach, he demonstrated support for thematerial being presented, which he was

hearing for the third time. Thus, his behaviorwas a natural expression of his place in twoprofessional societies: developer and coach.

Synchronous, or “silent,” groups are theopposite of collaborative. They coordinateaction without verbal communication,with people performing their roles with-out attempting to affect the other roles’work styles.

Constantine gives two examples ofsynchronous teamwork. The first comesfrom a scene in the movie Witness, inwhich members of the Amish communityraise a new barn in a single day, scarcelyuttering a word. The second comes froman accident that happened inside a hospi-tal, when a heavy table fell on a person’sleg. Without speaking to each other, thepeople in the room took coordinatedaction: Two lifted the table, one held theperson’s hand, one went to call for an X-ray, and one went to get a gurney.

In both cases, the people involvedknew the rules of the situation and thegoals and the roles involved. They couldsimply step into a needed role. Constan-tine points out that in a synchronous envi-ronment, “team members are alignedwith the direction established by a sharedvision and common values.”

It may turn out, in an odd twist, thatprogrammers operate within a silent orsynchronous culture. If this is true, it willbe interesting to see how the cooperativegame gets reshaped to fit that culturalpattern. Certainly, the current wave ofdevelopment methodologies, includingXP and Crystal, require much moreconversation than previous ones. Either



the programmers will shift their culture,or the methodologies will have to adapt.

In many organizations, programmersare expected to work massive overtime. Itwas a great shock to me to move from onesuch organization to the Central Bank ofNorway, where personal life was stronglyvalued and overtime discouraged:

OVERTIME LIGHTS AT NORGES BANK

At the Central Bank of Norway, the officialworkday ended at 3:30 p.m.

On a typical day, that is the time I sud-denly waken from whatever else I am doingand ask myself what I really want to get donethat day. As a result, I found myself wander-ing the halls at 3:45, trying to “really getsome work completed before the end ofthe day” and unable to send faxes, get signa-tures on paper, or get questions answered.The staff really did go home at 3:30!

Then, at 5:00, the lights automaticallyturned off! I learned how to turn on the“overtime lights” but got a second shockwhen the lights turned off again at 7:00 p.m.(“You really, really ought to go home now.”)

Cultures also differ by their attitudetoward frankness and politeness inspeech. The Japanese are renowned forworking to preserve face, while Ameri-cans are considered frank. Frankness istaken to extremes in some places, such asMIT, Stanford, and Israel. An Israelifriend was coaching me in direct speak-ing: When I saw him after he had to missa review meeting I said, “We missed youat the meeting.” He replied, “In Israel wewould say, ‘Why weren’t you there?’”

In other cultures, such as the churchorganization described earlier, even

disagreeing mildly or taking initiative areconsidered slightly negative behaviors,signs of a person’s having excessive ego.

As a result of differences around frank-ness in speech, people coming from differ-ent cultures sometimes have difficultyworking together. The overly frank personstrikes the other as rash and abrasive,while the overly polite person strikes theother as not forthcoming, not contributing.

Professional SubculturesEach profession also builds its own cul-

ture, with its own cultural values andnorms. Project managers have theirs, asdo experienced object-oriented develop-ers, relational database designers, COBOLprogrammers, salespeople, users, and soon. Even novices in each group have theirown values and norms, distinct from theexperts. Here are a few:

• Project managers need an orderly atti-tude to sort out and predict deliverydates and costs and the complexdependencies within the project.

• OO programmers need quiet time,abstract thinking ability, and the abil-ity to deal with the uncertainty ofsimultaneously evolving program-ming interfaces.

• Requirements analysts rely on thor-ough thinking, going through therequirements and the interfaces oneline at a time, looking for mistakes.

• Marketing people benefit from strongimaginations and people skills anddealing with the constant surprisesthat the market (and the programmers)throw at them.



Let’s consider programmers’ “noncom-municative and antisocial” behavior for amoment. Actually, as a number of themsaid when they wrote to me, they do liketo talk . . . about technical things. Theyjust don’t like talking about things theyconsider uninteresting (baseball gamesand birthday parties, perhaps). What theyreally detest is being interrupted duringtheir work. It turns out that there is agood reason for this.

Software consists of tying togethercomplex threads of thought. The pro-grammer spends a great deal of time lift-ing and holding together a set of ideas.She starts typing, holding in her mind thistangled construct, tracing the mental linksas she types.

If she gets called to a meeting at thispoint, her thought structure falls to theground, and she must rebuild it after themeeting. It can take 20 minutes to buildthis structure and an hour to makeprogress. Therefore, any phone call, discus-sion, or meeting that distracts her forlonger than a few minutes causes her tolose up to an hour of work and animmense amount of energy. It is little won-der that programmers hate meetings. Anti-social behavior, meeting-avoidance inparticular, is a protective part of theirprofession.

Thus, the values of each group contrib-ute to their proper functioning, and thedifferences are necessary for the properfunctioning of the total organization, eventhough they clash.

It would be nice to say that all of thevalues and norms are constructive. Notall are, though.

An example introduced earlier isthe Invent-Here-Now Imperative. It isdeveloped as a cultural value and normall the way through college. In most orga-nizations, however, inventing new solu-tions where old ones already exist iscounterproductive to the aims of the orga-nization. The ideal norm would be toscavenge existing solutions wherever pos-sible and to invent only where it leads theorganization past its competitors.

Adapting to SubculturesMost people’s initial reaction is to force

one group’s values on the other groups.

• Researchers in formal developmenttechniques want more math to betaught in school.

• Managers who are uncomfortablewith iterative development want theirprogrammers to get the design rightthe first time.

• The programmers, frustrated with notbeing able to communicate with theirmanagers, want the managers to learnobject-oriented programming prior tomanaging a project.

There are two problems with the make-them-change approach:

• The less serious problem is that it isreally, really hard to get people tochange their habits and approaches.

• The more serious problem is that wedon’t yet understand the subcultures.To force them to change their values isa bit like prescribing medicine with-out understanding the body’s defensemechanisms.


Teams as Ecosystems • 139

In the face of this situation, there arethings that the industry can do, thingsthat a few individuals can do, and thingsthat everyone can do.

As an industry, we can

• Encourage more ethnographic stud-ies of software development groups,as Hovenden (2000) has done.

• Identify and understand the norms inplay, showing the contribution of eachto the organization.

• Experiment with cultural changes.

Every consulting company can benefitfrom employing a social anthropologist orethnographer. That person will help theconsulting team understand the socialforces in play on their projects, which willenhance the team’s effectiveness.

People who are fluent in several spe-cialties, such as programming and data-base design, programming and projectmanagement, or teaching and designing,can act as translators. These people helpby converting statements phrased in onenormative value set into sentences mean-ingful within a different value set. A num-ber of people who perform this functionhave written to me to describe the diffi-culty and necessity of this role.

Finally, everyone can practice patienceand goodwill in listening. Pretend thatthe other person’s sentences, howevercrazy they may sound to you, make sensein the other culture’s value system. Listenthat way first, and then decide if you stillneed to disagree.

TE A M S A S EC O S Y S T E M S

A software project sets up a small ecosys-tem made up of personalities fromdiverse cultures. We have seen some ele-ments of the ecosystem, including

• Walls acting as barriers and openspaces acting as conduits

• People in their professional specialtiesacting as interacting subspecies

• Individuals with strong personalitieschanging the way in which the eco-system works

Everything affects everything: the chairs,the seating, the shape of the building,whether people share a native language,even the air conditioning.

LIZARDS AND PENGUINS

At one company, moving from our oldbuilding to a new one nearly caused fights.

In the old building, we each had a privateoffice, and each office had its own thermo-stat. In the new building, we would still haveprivate offices, but there was only going tobe one thermostat for every two offices.Each adjacent office pair had to use thesame temperature setting.

Suddenly, the workforce polarized intothose who liked warm offices (the “lizards”)and those who liked cold offices (the “pen-guins”). People were jockeying for positionsso they could share the thermostat withsomeone of similar temperature preferences.



In some work situations, it is hard for peo-ple to change companies. In other situa-tions, people change jobs every fewmonths. The two situations create differentattitudes and behaviors in the workforce.

Every job role and every person affectsevery other. Key individuals play a moresignificant role in shaping the ecosystemthan others. They focus or, more fre-quently, block conversations. When theyleave, the entire network of relationshipschanges.

Each project’s ecosystem is unique. Inprinciple, it should be impossible to sayanything concrete and substantive aboutall teams’ ecosystems.

It is.Only the people on the team can

deduce and decide what will work in thatparticular environment and tune the envi-ronment to support them.

If the people on the team understandsome key characteristics of humans andof methodologies, they can look around,introspect about what they observe, andconstruct a best first guess as to what con-ventions and policies might work well forthem, suiting their own strengths andweaknesses.

The people on the teams will naturallyreexamine and adjust their conventionsover time, periodically or whenever amajor event changes their ecosystem (aswhen a particularly influential individualjoins or leaves the organization).

The set of conventions and policies Irefer to as the team’s methodology. As wewill see in the next chapter, a methodol-ogy is a personal thing—“a social con-struction,” to quote Ralph Hodgson ofIBM.

Considering the methodology as theteam’s own social construction is useful.It highlights the idea that no methodol-ogy will work “straight out of the box.”The team members will have to adaptboth themselves and the methodology towork together to create their own, local,effective ecosystem.

Ecosystems and methodologies havethis interesting characteristic in common:If the team members construct many com-plicated rules for themselves, they tiethemselves to a narrow ecological niche.

However, narrow ecological niches arenotoriously fragile, and the market has anasty habit of changing the terrainaround a company. The many rules thatensure effective behavior in one ecologi-cal setting are ill suited for use in another.

In biology, we use the phrase “becomeextinct.” In business, the phrase is “go outof business.”

If, on the other hand, the team createsand periodically updates a few well-placed guidelines, it can draw on theintelligence, pride-in-contribution, com-munication, and spontaneity of its mem-bers. The people will adapt thoseguidelines to the situation at hand,achieving robust behavior in the face oftechnological, social, and market sur-prises. Dee Hock, designer of the highlydecentralized VISA system in the 1960sand 1970s, said this:

“Simple, clear purpose and princi-ples give rise to complex, intelligentbehavior.

“Complex rules and regulationsgive rise to simple, stupid behavior.”


What Should I Do Tomorrow? • 141

WH A T SH O U L D I DO TO M O R R O W?

Walk around your place of work. Notice

• The convection currents of information • The drafts• The information radiators• The separate communities of practice• The background conversation compli-

menting or denigrating other groupsin the organization

See

• How you can improve the flow of infor-mation and reduce the erg-secondsrequired to detect and transmit criticalinformation

• If you can colocate your team• What it takes to partition the project

so that teams are located around theircommunication needs

Try

• Removing partitions between people• Pair programming

• Arranging for daily visits betweenprogrammers and business experts

• Micro-touch intervention (peoplemaking small changes that they don’tmind making but that result in theirpulling more in the same direction)

• Listening to the words of someone in adifferent professional specialty accord-ing to her cultural norms, not yourown

• Translating between two subculturesin their own cultural terms

Observe the interaction between yourmethodology’s rules and your project’secosystem. Note the fits and the misfitsand the influence of a few key individuals.

Consider what conventions or policiesmight improve the way in which yourgroup gets things done. They may be con-ventions about seating, tools, workinghours, process, lighting, meetings,anything.

Do this, and you are halfway to tailor-ing your methodology to fit yourorganization.


communicating, cooperating teams - … · 105 3 communicating, cooperating teams this chapter...

Documents