This chapter is from the book
This chapter is from the book
This chapter is from the book
Teams as Communities
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 a 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 and against each other at times. The directions are more closely aligned on a more effective team than they are on a less effective team.
){kind=link}
You can create a large overall effect on the project by eliciting 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 get amplified 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).
){kind=link}
Figure 3-17 An average team working to pull toward a goal on the right.
The small changes come from people being given
Additional information about the direction in which they should pull
Additional information about the effects of their actions so that they notice which actions pull in a different direction
A better reason to pull in the desired direction
The result is that people start contributing to each other's work as opposed to ignoring or accidentally working against each other.
With small changes like these, people see greater project output for similar amounts of energy and without having to learn major techniques or philosophies. As they notice this, they develop greater pride in their work and more trust in each other. Usually, morale improves, and the project team becomes a better community in which to live.
The Project Priority Chart
The project priority chart is one simple mechanism that every project team should use to help align team members' effort.
Figure 3-18 A slightly better aligned team.
This chart is also described in Adaptive Software Development (Highsmith 2000) and Crystal Clear (Cockburn, forthcoming).
At the start of the project, the executive sponsors and the developers discuss and write down the single aspect of the development that everyone should attend to. It may be time-to-market, defect reduction, response time, ease of learning to use, speed of expert usage, memory used, extensibility, or ease of maintenance. They may write a second one, such as time to market and ease of casual use.
They then select, from among all the other desirable characteristics the team should strive for, those three or four that the team should be willing to sacrifice in order to achieve the main two.
From this exercise, each person sees what sorts of trade-offs are permitted on the project and how to prioritize their actions. With a modicum of goodwill between team members, simply writing the choices down in a joint meeting and referring to it periodically gets goal alignment close enough.
The project priority contract addresses a common problem: The executive sponsor wants the software out soon (to hit a market window), but the programmers want to "design it right" (delaying their output to improve the design aesthetics). Or the reverse may be true: The programmers are used to working fast and sloppy to hit market windows, and the sponsors want them to take more time and make fewer mistakes. In these cases, the entire organization suffers for a simple, correctable miscommunication of the desired priorities (assuming that the reward structures in place align with the priorities being requested).
Sometimes the priorities need to change in the middle of a project. For example, a competitor may come out with a new product. At that instant, it may become important to reverse priorities, shifting from development speed to defect freedom or vice versa. Should this happen, the sponsors should get the team members together again and announce the shift in priorities.
Amicability and Conflict
Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.
When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.
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 a project team 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 she 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 hungry 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 (1999) describes the intentional use of small doses of conflict to get people to meet and learn to talk with each other. This is like 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. . . . [T]he 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 is illustrated 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 who disagree about coding styles to nonetheless create a common coding standard for themselves. As many lead programmers have said, ÒItÕs not what I would like, but I recognize that 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 often find that workers show citizenship and sacrifice from the moment they start work, and management 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 respond in kind 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 1997) for examples of this.
Citizenship should be encouraged within normal working hours, not as a means of lengthening normal working hours. There are plenty of ways in which to apply citizenship within working hours.
Hostile XP versus 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 Extreme Programming (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 some in which customers and programmers might magnify their differences and create a hostile XP environment:
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 say, "Tell us what to build next."
In this situation, neither group is really sure what the correct thing is to 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 customers experience the situation as unsettling: There is little time to reflect, examine, experiment, and sort out options.
As a result, the customer's instructions over the course of 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 customers say, even if they are sure that the idea is silly.
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 to refine the requests of the customers.
The customers tell the programmers that a particular feature will be coming up and ask if the programmers will 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 they 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 through 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 them mentioned. Usually, customers appreciate the insights, whether or not they change the request.
In the story-sequencing situation, the programmers help the customers by finding those story cards that affect the decisions in question. They can then jointly consider in which order the cards should 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 one that advocates 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 offsite team building. This is good, even if it is good mostly because the people recognize the effort the company is putting forth to show that teamwork is important. Although 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 offered this observation in an e-mail note:
"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."
Support for this is also found 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 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 embedded. 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!"
Cultures and their values can be characterized in many ways. In one characterization (Constantine 1995), sociologists name four culture types by their communication, power, and decision-making habits (Figure 3-19). These four culture types are described in the following paragraphs:
){kind=link}
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 they have to be trained away from it.
Figure 3-19 Four organizational paradigms.
Random is the opposite of hierarchical. It indicates a group in which there is little or no central control. Many start-up 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, because there are no clear points of control.
Collaborative groups work by consensus. I had the opportunity to encounter a collaborative group in action at Lucent Technology:
Consensus Culture at Work
Someone in the organization decided that use cases would be a good way to capture requirements and asked me to teach a course to the people on a project.
I met the team leads (who are actually called coaches, because in a collaborative culture they don't lead, of course, they coach).
About a month later, I was called to teach it again, for more of the group.
Several months after that, I was asked to lecture one last time, for the entire department. Even though the coach had decided that use cases were good, the group was not going to use them until they had all had a chance to see and understand them.
The behavior of the coach in the final meeting was interesting: He programmed on his laptop while I taught. He was physically present in the room, but only just barely. Far from being insulting, I found his actions fully appropriate in light of the value systems in play around his situation. As a senior developer, he demonstrated that he was still contributing directly to the team's work. As a coach, he demonstrated support for the material being presented, which he was hearing for the third time. Thus, his behavior was a natural expression of his place in two professional societies: developer and coach.
Synchronous, or Òsilent,Ó groups are the opposite of collaborative. They coordinate action without verbal communication, with people performing their roles without attempting to affect the other rolesÕwork styles.
Constantine gives two examples of synchronous teamwork. The first comes from a scene in the movie Witness, in which members of the Amish community raise a new barn in a single day, scarcely uttering a word. The second comes from an accident that happened inside a hospital, when a heavy table fell on a person's leg. Without speaking to each other, the people in the room took coordinated action: Two lifted the table, one held the person's hand, one went to call for an X-ray, and one went to get a gurney.
In both cases, the people involved knew the rules of the situation and the goals and the roles involved. They could simply step into a needed role. Constantine points out that in a synchronous environment, "team members are aligned with the direction established by a shared vision and common values."
It may turn out, in an odd twist, that programmers operate within a silent or synchronous culture. If this is true, it will be interesting to see how the cooperative game gets reshaped to fit that cultural pattern. Certainly, the current wave of development methodologies, including XP and Crystal, require much more conversation than previous ones. Either the programmers will shift their culture, or the methodologies will have to adapt.
In many organizations, programmers are expected to work massive overtime. It was a great shock to me to move from one such organization to the Central Bank of Norway, where personal life was strongly valued and overtime discouraged:
Overtime Lights at Norges Bank
At the Central Bank of Norway, the official workday ended at 3:30 p.m.
On a typical day, that is the time I suddenly waken from whatever else I am doing and ask myself what I really want to get done that day. As a result, I found myself wandering the halls at 3:45, trying to "really get some work completed before the end of the day" and unable to send faxes, get signatures on paper, or get questions answered. The staff really did go home at 3:30!
Then, at 5:00, the lights automatically turned off! I learned how to turn on the "overtime lights" but got a second shock when the light turned off again 7:00 p.m. ("You really, really ought to go home now.")
Cultures also differ by their attitude toward frankness and politeness in speech. The Japanese are renowned for working to preserve face, while Americans are considered frank. Frankness is taken to extremes in some places, such as MIT, Stanford, and Israel. An Israeli friend was coaching me in direct speaking: When I saw him after he had to miss a review meeting I said, "We missed you at the meeting." He replied, "In Israel we would say, 'Why weren't you there?'"
In other cultures, such as the church organization described earlier, even disagreeing mildly or taking initiative are considered slightly negative behaviors, signs of a person having excessive ego.
As a result of differences around frankness in speech, people coming from different cultures sometimes have difficulty working together. The overly frank person strikes the other as rash and abrasive, while the overly polite person strikes the other as not forthcoming, not contributing.
Professional Subcultures
Each profession also builds its own culture, with its own cultural values and norms. Project managers have theirs as do experienced object-oriented developers, relational database designers, COBOL programmers, salespeople, users, and so on. Even novices in each group have their own values and norms, distinct from the experts. Here are a few:
Project managers need an orderly attitude to sort out and predict delivery dates and costs and the complex dependencies within the project.
OO programmers need quiet time, abstract thinking ability, and the ability to deal with the uncertainty of simultaneously evolving programming interfaces.
Requirements analysts rely on thorough thinking, going through the requirements and the interfaces one line at a time, looking for mistakes.
Marketing people benefit from strong imaginations and people skills and dealing with the constant surprises that the market (and the programmers) throw at them.
Let's consider programmers' "noncommunicative and antisocial" behavior for a moment. Actually, as a number of them said when they wrote to me, they do like to talk . . . about technical things. They just don't like talking about things they consider uninteresting (baseball games and birthday parties, perhaps). What they really detest is being interrupted during their work. It turns out that there is a good reason for this.
Software consists of tying together complex threads of thought. The programmer spends a great deal of time lifting and holding together a set of ideas. She starts typing, holding in her mind this tangled construct, tracing the mental links as she types.
If she gets called to a meeting at this point, her thought structure falls to the ground and she must rebuild it after the meeting. It can take 20 minutes to build this structure and an hour to make progress. Therefore, any phone call, discussion, or meeting that distracts her for longer than a few minutes causes her to lose up to an hour of work and an immense amount of energy. It is little wonder that programmers hate meetings. Antisocial behavior, meeting-avoidance in particular, is a protective part of their profession.
Thus, the values of each group contribute to their proper functioning, and the differences are necessary for the proper functioning of the total organization, even though they clash.
It would be nice to say that all of the values and norms are constructive. Not all are, though.
An example introduced earlier is the Invent-Here-Now Imperative. It is developed as a cultural value and norm all the way through college. In most organizations, however, inventing new solutions where old ones already exist is counter-productive to the aims of the organization. The ideal norm would be to scavenge existing solutions wherever possible and to invent only where it leads the organization past its competitors.
Adapting to Subcultures
Most people's initial reaction is to force one group's values on the other groups.
Researchers in formal development techniques want more math to be taught in school.
Managers who are uncomfortable with iterative development want their programmers to get the design right the first time.
The programmers, frustrated with not being able to communicate with their managers, want the managers to learn object-oriented programming prior to managing a project.
The less serious problem is that it is really, really hard to get people to change their habits and approaches.
The more serious problem is that we don't yet understand the subcultures. To force them to change their values is a bit like prescribing medicine without understanding the defense mechanisms of the body.
In the face of this situation, there are things that the industry can do, things that a few individuals can do, and things that everyone can do.
As an industry, we can
Encourage more ethnographic studies of software development groups, as Hovenden (2000) has done
Identify and understand the norms in play, showing the contribution of each to the organization
Experiment with cultural changes
Every consulting company can benefit from employing a social anthropologist or ethnographer. That person will help the consulting team understand the social forces in play on their projects, which will enhance the team's effectiveness.
People who are fluent in several specialties, such as programming and database design, programming and project management, or teaching and designing, can act as translators. These people help by converting statements phrased in one normative value set into sentences meaningful within a different value set. A number of people who perform this function have written to me to describe the difficulty and necessity of this role.
Finally, everyone can practice patience and goodwill in listening. Pretend that the other person's sentences, however crazy they may sound to you, make sense in the other culture's value system. Listen that way first, and then decide if you still need to disagree.