Alistair Cockburn - Agile Software Development

The wording in the posters matters. One XP team had posted "Things we did wrong last increment." Another had posted, "Things to work on this increment." Imagine the difference in the projects: The first one radiated guilt into the project room, and was, not surprisingly, not referred to very much by the project team. The second one radiates promise. The people on the second team referred to their poster quite frequently when talking about their project.

Periodic reflection workshops such as these are used in Crystal Clear and XP projects. Obviously, this technique is appropriate for smaller, colocated groups.

A fourth use of information radiators is to show everyone the user stories delivered, in progress, the number of acceptance tests written and met, and so on. (Figure 3-11).

Figure 3-11. Graph showing growing completion. (Courtesy of Ron Jeffries)

The systems operations team at eBucks.com constructed a fifth use of information radiators, this time to keep the programmers from pestering them. Displaying System Status

The programmers kept asking, "Is system A up? Is system B up? Is the link to the back end up?" The maintenance team wrote the status of each system and link on the whiteboard outside their area. Each day, they updated the status. It looked rather like ski areas posting the status of lifts and runs (so skiers don't keep asking the ski resort staff.).

The group at eBucks.com came up with a sixth use of information radiators. This time it was the programmers who created the status displays:

Figure 3-10. Reflection workshop output. (Courtesy of IndustrialLogic, Inc.)

Displaying Work Progress

The programmers were being asked about the status of their work every hour or two, which caused them no end of frustration. They wrote on the whiteboard outside their office their intentions for the current week. As they completed their tasks, carefully sized to be of the half-day to two-day variety, they marked the tasks complete.

Once these boards had been tried by the programmers, several other groups started using them to broadcast their own priorities and progress.

Applying the Theory of Hot Air

People have long applied the above, "hot air theory of software development."

Gerald Weinberg discussed the damaging effect of removing a soda machine from a computer hel--desk area (Weinberg 1998). Thomas Allen, of MIT's Sloan School of Management, discussed the effect of building design on R&D organizations in (Allen 19??, Allen 19??). IBM and Hewlett Packard have incorporated such research in their R&D buildings since the late 1970s.

As a result of these and others' work, we consider it natural for research and development groups to have whiteboards in the hallways or near coffee machines. What we have forgotten, though, is the significance of actually being within sight and earshpt of each other.

Here are several examples. The first is from a Crystal Orange project, the second is from a project trying to apply Crystal Clear. After that I discuss the Caves and Commons room design recommended by XP, and close with a story from Lockheed's Skunkworks group. Repairing Design Discussions

On project "Winifred" (Cockburn SOOP), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.

As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.

He eventually left and I took his place. To reverse the situation, I arranged that we designed in conversations at the whiteboard. After some period of doing this, I started getting questions like, "Could you look at the responsibilities (or communication patterns) of these objects?"

By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.

Colocation is considered a critical element in Crystal Clear, a light methodology for small teams (see Chapter 6). A rule of Crystal Clear is that the entire team must sit in the same or adjacent rooms, in order to take advantage of convection currents of information and osmotic communications. Crystal un-Clear

"Pat" asked me to visit his Crystal Clear project.

When I arrived, he wasn't at his desk. The secretary said he was with his teammate. I offered to go to that office, but she said, "You can't. There is a combination lock in the hallway over to that section." !!...? Each time a team member wanted to ask a question, he had to stand, walk across the hall, punch in the lock combination and walk to the team mate's office. Clearly, this team was not getting the benefit of osmotic communication or low cost of information transfer. Changing the team seating was fortunately a simple matter to arrange.

Caves and Common

The Caves and Common room arrangement recommend in XP makes use of all three information exchange mechanisms. It is photographed in action in Figure 3-12 and diagrammed in Figure 3-13.

Figure 3-12. The RoleModel Software team at work (photo courtesy RoleModel Software)

Caves and Commons is very effective, but as Tom DeMarco correctly warns, it can easily be abused to become just a programming sweatshop. Therefore, I describe here not only the room layout, but also the social presuppositions that accompany its use: single project team, good team dynamics, provision for both private and project space.

The term Caves and Common refers to the creation of two zones in the room. The common area is organized to maximize osmotic communication and information transfer. Obviously, for this to make sense, the people in the room must be working on the same project. It is perfect for XP's single team of up to 12 people programming in pairs (Figure 3-12).

The Caves portion of the room is organized to give people a private place to do email, make phone calls, and take care of their need for separation. In RoleModel Software's office, private workstations are set up along one wall (Figure 3-12). At Evant, table came out from the walls on two sides of the room

Figure 3-13. The "caves and common" room layout used at RoleModel Software. (picture courtesy of RoleModel Software)

People who have worked in Caves and Commons facilities say that there needs to be ample wall space for whiteboards and posted flipcharts, and two more types of rooms for the team to use: a food preparation room, and areas for small discussions to take place.

You can see from the picture that while the caves and commons room is very efficient for transmitting information, it is also very efficient for transmitting coughs and colds. People who work in this sort of room encourage their colleagues to stay home if they don't feel well, and to return after they have recovered.

You can also see that it is drafty (in an information sense): the people sitting in this configuration should really need to overhear each other.

Finally, you can see that it is very effective as long as the morale of the group is good. Once the social chit-chat degenerates into negative chatter, the highly osmotic communication again magnifies its effect.

Skunkworks

It is useful to compare the above discussions against a group performing classical "engineering", one of the most effective aero-engineering groups, Lockheed's "skunk works" team. This team achieved fame for their rapid development of a series of radical new airplane designs in the second half of the 20th century, under the guidance of Jim Kelly and his successor, Ben Rich. Ben Rich wrote about their experiences in the book, Skunk Works (Rich 1994).

Rich highlights that, among the rules of the group, Kelly insistented on people taking accountability for decisions from design through testing, and on their sitting close together. The following is from that book. Skunkworks Rooms