Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.
One might think that removing all conflict from would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems! I was surprised to find one organization that suffered from too little conflict: Not Enough Conflict
In a church organization I visited, each staff member was employed for as long as they wished. The group cherished virtues of humility, peacefulness, and amicability. The unsuspected negative effect that accumulated was the absence of both disagreement and initiative!
Each person would think twice (or more) before criticizing someone else's idea, for fear of being seen as seeding discord, or of disrupting the group. People would also think twice (or more) before taking initiative, lest they be considered glory- or power-hungry. The net result was that projects moved very slowly.
Before you start offering suggestions for this group, recall the values of the group. They will only improve their development practice when they can find ways to disagree without jeopardizing their values of humility and amicability.
Schrage (2000?) describes the intentional use of small doses of conflict to get people to meet and learn to talk with each other. It reminds me of introducing a weakened form of a virus so that the body can build ways of handling the stronger virus: Deliberate Conflict
"...according to some reports, engineers on the 777 design-build teams deliberately introduced conflicts with other systems into their proposed designs.
"...Although Boeing officially acknowledges only that interferences naturally evolved, according to at least one mechanical engineer, some of those interferences were intentional. Why? So that engineers in one part of Boeing could use the interference to find the people in other parts of the company with whom they needed to discuss future design issues. ... the software's ability to notify appropriate parties about interferences became, at least in some instances, a tool to forge interactions between various groups within Boeing. "...The resulting conversations and negotiations resolved design conflicts before more serious problems could emerge."
Citizenship within Working Hours
Good citizenship is a matter of acting in ways that benefit others. Citizenship shows up with people
· Getting to meetings on time
· Answering questions from other people
· Bothering to mention things that one notices
· Following group coding conventions
· Using code libraries Citizenship permits programmers who disagree on coding styles to nontheless create a common coding standard for themselves. As many lead programmers have said, "It's not what I would like, but I recognize that there many ways work, and selecting any one of them is better than not selecting any at all."
Helping other people in the company is a characteristic of citizenship. Dixon (2000) reports on the strong effect of taking time to help other people. She cites, among many examples, a woman at Tandem Computers who was asked about taking away from her work time to answer questions posted on the corporate discussion boards. The woman responded, "Answering questions like this is part of being a good company citizen"
I would suggest increasing citizenship levels to get better project results, except that I usually find workers already show citizenship and sacrifice, and management already takes too much advantage of it.
People join a new company and work overtime, thinking that after they contribute this extra work, the company will repay the compliment and give them more recognition and time off. What they don't realize is that their bosses and colleagues assume that however they work in the first month is how they will work and act forever. As a result, people regularly get poor evaluations for dropping their working hours from 65 down to a mere 50!
I am afraid that managers will use the pretext of good citizenship to coerce people into working yet more overtime. Read Death March (Yourdon 1998) for examples of this.
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