Alistair Cockburn - Agile Software Development

Bordia and Prashant (1997) describe that brainstorming improves when social ranking information is hidden from the participants. McCarthy and Monk (1994) remind us that email has the advantage of allowing people to reread their own messages before sending them, thereby clarifying the message.

Thus, warmer communications channels are more effective in transferring ideas, but cooler communications channels still have uses.

Stickiness and Jumping Gaps across Space

We can see, at this point, how the team of Russian programmers (Chapter 1) got low cost per idea transfered. Sitting in a room together, they got convection currents of information, osmotic communication, face-to-face communication, realtime question and answer.

So why did they need to write use cases at all?

The answer is: To give the information some stickiness. Information on paper has a sort of stickness that the information in a conversation doesn't, a stickiness we sometimes want.

The person who went to Russia with the use cases wanted to make sure that he did not forget what he was supposed to cover in his conversations. He wanted that after he explained the use cases to the Russian programmers, they could subsequently read the use cases, understand and recall the information without having to ask him again.

The use case writer, knowing that the use cases were only game markers to remind them of what they already knew or had discussed, could balance the time spent writing the use cases against the time that would be spent discussing other material. He could decide how much detail should go into the writing.

Figure 3-15. Two people working at a shared, sticky information radiator. (Courtesy of Evant, Inc.)

Large, sticky, revisable shared information radiators are often used by people to achieve greater understanding and to align their common goals.

Figure 3-15 and Figure 3-16 shows a useful mix of whiteboards (static information radiators) and people (dynamic information radiators).

Both whiteboards and paper are particularly good, and can be written on by all parties, making them shared, sticky information radiators.

Until recently, archivability and portability were still problems with whiteboards:. If a discussion results in really valuable information being placed on the whiteboard, no one dares erase it, and the group can't archive it. This slows the archiving of valuable information and shuts down the board for the next use. As Ron Jeffries put it, "If you never erase the whiteboards, you might as well write on the walls."

Figure 3-16. Dynamic and static information radiators at work. (Courtesy of Evant, Inc.)

A colleague, Mohammad Salim, responded to this situation by covering all the walls and hallways with rolls of butcher paper, so that people could literally draw on the walls wherever they were. He said, "If you have to take time to walk to a workstation or find a blank whiteboard, you just lost your idea." He continued, saying that when a section of paper gets full, to just roll it up and date it. That way all discussions are archived and can be pulled out for later examination. I noticed in his description of finding rolls of paper for later examination, how he made use of humans being good at looking around, as discussed in the last chapter. Also that he worked hard to reduce the cost of invention and communicaiton, while preserving archivability for later discussions.

A number of people report they are using digital cameras in conjunction with software that cleans up the image ("Whiteboard Photo" at www.pixid.com is one that they reference). Printing whiteboards continue to be very practical. Often, people start a discussion thinking the outcome will not be significant, but see at the end that the whiteboard holds valuable information. With printing whiteboard they can simply push the Print button if they wish.

Different information radiators are suited for different sizes of discussion groups, of course. A piece of paper works for two or three people, a whiteboard works for perhaps a dozen.

Recalling these differences will serve us well when we consider methodologies for different projects, in the next chapters. Sticking Thoughts onto the Wall

On one project, the business analysts were frustrated because their work was growing more and more interdependent. They had, at that time, no way to hold their thoughts in clear view, and still, while planning their joint work.

We held a discussion about cooperative games, game markers, and stickiness. The people saw that creating a large, persistent and revisable display of their mental territory would help them do their work. One of them immediately posted a picture of the domain on the corridor wall as an staring picture. They worked on it over the weeks, experimenting with representations of their concerns that would allow them to view their mutual interdependence.

There is an interesting and relevant aside to mention about this group, having to do with expectations and citizenship. For reasons I won't go into, this team of business analysts thought they were supposed to work in the XP style, and that XP prohibited them from writing things down. Notice four things about their situation:

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

2. Their citizenship was so strong that rather than be poor citizens and write down their thoughts on the domain model, they chose to be good citizens and not write down their business model at all!

3. Actually, they knew that the project wouldn't succeed if they really wrote nothing down. So they each clandestinely wrote pseudo- use cases and other notes, which they passed to the programmers. They still did not create a domain model for themselves.

4. By writing down those notes, they subverted their own (mistaken) interpretation of the official process. I find this situation particularly interesting, because they were at war with themselves about whether to be good citizens and follow the process (at the expense of the project), or to be good citizens and protect the project (by violating the process).

What was significant in the end was that they posted an information radiator on the corridor wall, on which they scribbled individually and as a group, to give their thoughts and decisions some stickiness.

Jumping Gaps across Time

Finally, let us look at communicating across time, as another twist lies in store for us here.

We might expect, after the preceding discusion, that to preserve information across time, we would definitely drop reliance on face-to-face communication, and prefer paper, audiotape and videotape.

However, on long-running projects, it turns out to be critically important that the chief architect stays around! This person's contribution is to keep memories of key ideas alive across changing development teams. Once again, people are used as the archival medium!

Individual people transfer information effectively across both time and space. As an IBM Fellow put it

We have looked at what it takes for someone to notice something of value on a project, and what it takes for someone to communicate something of value. It is time to consider whether the person cares to notice and communicate anything.

On an effective team, the people pull approximately in the same direction. They actually all pull in slightly different directions, according to their personal goals, personal knowledge, stubbornness, and so on (Figure 3-17). They work together at times, against each other at times. The directions are more aligned on a more effective team than on a less effective team.

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

We can create a large overall effect on the project from small changes in each person's behavior. This is "micro-touch" intervention: getting people to make changes they don't mind making, in ways that gets amplied by the number of people on the project. As each person pulls in a direction closer to the desired and common direction, the changes felt by any one individual are small, but the composite effect is large (Figure 3-18). in a lecture about technology transfer, "The way to get effective technology transfer is not to transfer the technology itself, but to transfer the heads that hold the technology!"