Alistair Cockburn - Agile Software Development

Citizenship should be encourages within normal working hours, not as a means of lengthening normal working hours. There are plenty of ways to apply citizenship within working hours.

Hostile XP vs. Friendly XP

To round out this discussion, let's look at the consequences of working with and without attention to community. I choose to discuss XP, because although communication and community are core values within XP, I have seen it practiced with and without that community, "friendly" XP and "hostile" XP, as it were. The difference is profound.

The three following situations are ones in which customers and programmers might magnify their differences and create a hostile XP:

· The customers are not quite sure what they want. The programmers insist, "Tell us what to build," so the customers say something The programmers build exactly that and then ask, "Tell us what to build next."

In this situation, neither group is really sure what is the correct thing build next. The programmers escape the pressure of the situation by shifting the burden over to the customers (which they are allowed to do). The customer experiences the situation as unsettling: there is little time to reflect, examine, experiment, and sort out options.

As a result, the customer's instructions over succeeding iterations conflict with each other ("Build this... No, now build this... No, try building that, now"). Both parties become depressed about the lack of clear progress.

· The programmers do whatever the customer says, even if they are sure it is a silly idea.

As with the story, "Not enough conflict," a project suffers when the developers don't mention problems they notice. The project loses the creative interplay of sharp programmers offering their insights into the requests of the customers.

· The customers tell the programmers that a particular feature will be coming up, and would the programmers please design the system to handle that gracefully. The programmers cite a series of the XP mantras: "keep it simple," "you aren't gonna need it," "we'll do the simplest thing that will possibly work," and ignore any suggestion of what to build into the software.

The consequence is that the designers run through a sequence of designs everyone knows are incorrect, until the critical requirements finally appear. By then, time has been spent redesigning the system several times. In the cases I have encountered, the programmers were happy about the exercise, and the sponsors were unhappy.

In each of these cases, the programmers withheld information. Withholding their own thoughts and experience from the discussion, they abdicated responsibility toward the overall project. By doing so, they damaged the project by concealing from view superior development strategies.

In friendly XP, practiced with community, the three situations play out differently. In each case, the programmers actively share their views, experiences, cost estimates, and solutions.

· In the first situation, not knowing what to build next, the programmers help the customers gain experience in voicing what they want. They can do this by producing small working prototypes tailored to discovering the desired characteristics.

· In the case of the silly idea, the programmers volunteer their information in an amicable dialogue, "I'm not sure you really want this thing you asked for. It will be so-and-so difficult to implement, and has the following roll-on effects." The customer might still request the feature, but quite often, the person had no idea about those effects, and is happy to have it mentioned. Usually, the customer appreciates the insights, whether or not she changes the request.

· In the story sequencing situation, the programmers help the customers by finding those story cards that affect the decisions in question. They would then jointly consider in what order these cards might be tackled. The new order might not simply ask for more functionality along a business-value trajectory, but might converge more quickly on the actual system the customers want.

Any development methodology, even those that advocate amicability and community, can be practiced without it, to the detriment of the project.

Building "Team" by Winning

Team spirit was once built through singing company songs and attending company functions. (Any of you still have your IBM songbook?) When singing on the job went out of style, nothing immediate took its place.

Some companies start projects with one or several days of off-site team-building. This is good, even if it is good mostly because the people recognize the effort the company is putting forth in showing show that teamwork is important. While not every team-building exercise actually builds a team, a number of successful teams have pointed to their team-building days at the start of the project as having helped them work together more effectively. As a result, their company leaders consider the money well spent, and plan on continuing the tradition.

Programmers give mixed reviews to outside-of-work team building exercises. Several said, roughly, "I'm not interested in whether we can barbeque together or climb walls together. I'm interested in whether we can produce software together."

What does build teams? Luke Hohmann writes:

"The best way to build a team is by having them be successful in producing results. Small ones, big ones. It doesn’t matter. This belief has empirical support; see, for instance, Brown (1990). Fuzzy team building is (IMO) almost always a waste of time and money."

I find support for this also in Weick's description of the importance of "small wins" (Weick 2001) as well as in interviews of successful project managers.

One successful project manager told me of a key moment when the project morale and "team"-ness improved. We found the following elements in the story:

· The people, who sat in different locations, met each other face-to-face.

· Together, they accomplished some significant result that they could not have achieved without working together.

· At some point, they placed themselves in some social jeopardy (venturing new thoughts, or admitting ignorance), and received support from the group when they might have been attacked.

The second of those characteristics is "producing results," as Luke Hohmann mentions. The first and the third build amicability, the positive absence of fear and distrust.

Team Cultures and Subcultures

The project team itself creates a mini-culture. That mini-culture sits within the culture formed within the larger organization, and also within the dominant national culture around it.

Often, the programming project ends up with its own culture, different from the national or corporate cultures in which it is imbedded. People on the project find this useful, because they have a greater need to trade information about what is working and what is about to break.

Sometimes, the wider organization tolerates this different culture, and sometimes it fights back. One person who had experienced the resistance wrote, "Watch out for the organizational antibodies!"

Figure 3-19. Four organizational paradigms.

There are many ways to characterize cultures and their values. In one (Constantine 1995), sociologists name four culture types by their communication, power and decision-making habits (Figure 3-19).

Hierarchical cultures have the traditional top-down chain of command. Typically, older, larger corporations have a hierarchical culture. Many people internalize this as the dominant or natural or default corporate culture as they grow up, and have to be trained away from it.

Random is the opposite of hierarchical. It indicates a group in which there is little or no central control. Many startup companies work this way.

Some people consider random a fun way to work, and regret the loss of the small, informal group when the company grows. Others find it stressful, since there are no clear points of control.