Software Project Planning - Software Team Dynamics

Abstract

Every group in every society has their set of group norms – those principles that serve to guide and regulate proper behavior. However, most group norms are unwritten rules of behavior that operate below the level of conscious awareness. The existence of group norms is both inevitable and good – norms keep us from becoming rampant sociopaths. However, when group members fail to share the same set of rules, conflict can become destructive. This paper looks at the function played by group norms in the workplace, specifically how group norms affect software development team formation and cohesion, so that conflict remains constructive and not destructive. It also suggests some methods of looking at our own norms and using them positively to reduce conflict. This paper includes both academic research and examples from my own experience.

Technical managers can especially benefit from a formal decision-tree tool, since technical curriculums do not cover organizational behavior or psychology in much depth (if at all). In conjunction with this paper, I also wrote a program that implements a Vroom-Jago decision tree, which can help a manager to determine the level of participation needed when making a particular decision.

Click here to download the Vroom-Jago decision tree program.

Click here to go to the case study, which gives more detail on the decision tree itself.

Introduction

Not all conflict is bad. Constructive conflict occurs anytime people discuss the merits and alternatives of an idea. Constructive conflict is a rational process and is largely depersonalized (Thompson, Aranda, and Robbins 218). By comparing differing opinions, a team can rethink problems and devise better ideas. Problems arise when conflict becomes personalized. People can then become preoccupied with reducing threats, increasing power, and avoiding blame. For a team to function effectively in the workplace, it must foster constructive conflict and eliminate destructive conflict. A group does this by establishing group “norms” – the standards of behavior.

The Merriam-Webster dictionary defines a norm as: “a principle of right action binding upon the members of a group and serving to guide, control, or regulate proper and acceptable behavior…. [also] a widespread or usual practice, procedure, or custom.” Many companies have formal norms, such as the employee handbook or the company’s ethics policy. However, most norms are those unwritten rules of conduct that govern our daily behavior as we interact with others. We are often unaware that these norms even exist; we simply learn them as we grow up in society. From birth, we are rewarded when we follow the norms and punished when we violate the norms. In the workplace, we get good reviews for behaving “rightly” and bad reviews for behaving “wrongly.” Because we are rarely aware of these norms on a conscious level, when they are violated we simply feel that something is “wrong;” and, since we are not aware of the norm, we tend to attribute the “wrongness” to the person who violated the norm. Sometimes they just “don’t fit in.”

However, what if the person who “doesn’t fit in” sees the group as exclusive – refusing to allow him or her to join? In a social setting this can be simply annoying; however, in a business setting it can cause an otherwise qualified employee to fail to perform. At its best, it provides a source of material for comedians and satirists; at its worst, it can devolve into dysfunctional politics, in-fighting, resignations, and project failure. Group cohesion – or solidarity – is essential to achieving the company’s goals.

Team Solidarity

French sociologist Emile Durkheim identified two types of cohesive forces in social groups: mechanical solidarity and organic solidarity. In a society held together by mechanical solidarity, an individual’s value to society is determined by how well the individual conforms to the norms and standards of the society – i.e. their “conformance” with the group norms and beliefs. Mechanical solidarity can be readily seen in pre-industrial societies, where the individual often had no value beyond their ability to conform to the social standards expected of them.

With industrialization came the division of labor, as illustrated in 1776, when Adam Smith published his landmark book Wealth of Nations. In his description of a hypothetical pin factory, he showed that ten workers acting alone could barely produce ten pins each day. However, by using a division of labor they could produce about 48,000 pins each day (qtd. in University pg. 67). British mathematics professor Charles Babbage expanded upon that concept, showing how a division of labor reduces the time needed to learn a job, reduces waste, allows workers to achieve higher skill levels, and allows worker’s skill’s to be matched to their jobs (qtd. in University pg. 68). Their work provided a solid foundation for the advantages of a division of labor, but what effect does this division have upon the solidarity of society?

By a division of labor, each person specializes in only a few functions, much like the organs of a body, each performing a specialized task. Singly, no one person can achieve the output levels required of an industrial society. It is only the combined effort of distinctly different (organic) parts that makes possible the high output of an industrial society. Therefore, in a society held together by organic solidarity, the value of the individual is determined by their unique skills – i.e. by their differences. This also confers upon the individual an intrinsic value that often did not exist under mechanical solidarity.

As societies grow they become more organic in structure, requiring more diverse types of labor to build and maintain the infrastructure. Durkheim warns that a sense of “belonging,” which once came from mechanical society, is generally absent in an organic society, which can result in alienation and a breakdown of standards and values. This can also happen in a company, unless employees can feel that they are a part of the shared vision. This is why, even in organic societies, there is still mechanical solidarity at the smaller level. Trade unions, church groups, street gangs, and sports teams are only a few examples of the smaller, mechanical groups in which the individual’s value is largely determined by their conformance to the group norms. These groups provide the individual with a sense of “belonging” to something.

A medium or large sized company is organic in that it requires a division of labor and thus employs people with widely diverse skills (such as finance, accounting, human resources, and various technical skills). However, at the department or team level the social bonding force becomes more mechanical, as team members are asked to “buy-in” to the team’s goals and norms. Teams and other small groups are more likely to display mechanical solidarity than organic. Next I examine, the process by which teams achieve mechanical solidarity, and the effect upon teams when new team members fail to conform to the group norms.

Team Formation and Dissolution

The dynamics of team formation and dissolution illustrates how group norms operate in the workplace. Understanding this process also allows us to identify and correct problems that stem from changes in the group norms.

Team Formation

The Tuckman model (1965) defines four stages of team formation:

Team Dissolution Process

McGrew, Bilotta, and Deeney (1999), in a study of several software development groups, extended the Tuckman model to include three stages of dysfunctional team dissolution. Teams that remain in place for a length of time may experience all these stages of dissolution, which in turn produces devolution of team performance:

De-Norming A drift in norms stems from changes to the team’s environment, project scope, size, or personnel. Even changes in personal priorities can undermine the established standards of behavior within the group. New members are not always familiarized with group norms. Also, there are few software development groups that support a formal concept of apprenticeship or initiation. Original team members sense a loosening of the social web that had enabled the group to reach a high level of performance, and they seek shortcuts to minimize the impact of their increasing workloads. With new members come new ideas that older group members feel attack the established order and require a defensive response. The expression of ideas and opinions becomes less open and begins to move underground. Previously accepted roles are rejected and often unilaterally redefined by the new members who, through assertion or neglect, decide what work or responsibilities they will accept.

De-Storming This is a reverse of the storming phase. De-storming, in contrast, raises the group's level of discomfort gradually as norming behavior declines, as group cohesion weakens, and as resistance to group influence grows. Heightened interpersonal emotions are once again turned against the task itself. When the discomfort level has built up enough, the group explodes in open conflict and polarization of the membership, and moves rapidly into the final stage. One of the key symptoms of de-storming is a personal attack like “He did this,” or “She didn’t deliver that.” Once role conflict becomes personal, the stated issues are not the real issues, and focusing on the stated issues only denies the de-storming process and allows it to continue into the final stage.

De-Forming Boundaries are aggressively re-explored and redefined in a struggle for control of pieces of the group. It is not uncommon to see even small teams become balkanized as each person claims for himself or herself those pieces of the group's overall responsibilities that he or she is willing to accept. The pieces that no one will accept are abandoned. Group members begin isolating themselves from each other and from their leaders. Performance declines rapidly because the whole job is no longer being done and group members little care what happens beyond their self-imposed borders. A key symptom of de-forming (in addition to resignations) is a task that is no longer being done – because someone always claims to be waiting for a decision from someone else, or because it is "not my job."

The Merriam Webster dictionary defines a role as: “1: a socially expected behavior pattern usually determined by an individual's status in a particular society … 2: a function or part performed especially in a particular operation or process.” During the team’s norming process, team members may establish their own roles, or roles may be imposed externally. Overcoming role conflict is essential for the team to complete the norming process. Role conflict occurs when one or more team members refuse to follow the expected behavior for their role, which in turn starts the de-norming process. Recognizing this role conflict and consciously resolving it can restore a team that is de-norming.

Example: In a classic study, William F. Whyte demonstrated the importance of status in the workplace (qtd. in University, pg. 395). Whyte felt that people worked more smoothly when high-status personnel customarily originated action for lower-status personnel. In instances where those of lower status were initiating action, a role conflict arose. He cited an instance in which waitresses passed their customers’ orders directly on to the cooks. Thus, low-status waitresses were initiating action for high-status cooks. The cooks perceived themselves to have a higher status than the waitresses because the waitresses only followed the customer’s orders and were paid less money, whereas the cooks performed the actual feats of cooking – which was why the customers came there in the first place! However, the waitresses perceived themselves to have a higher status than the cooks, since the cooks were supposed to prepare what they were told to prepare! Neither side was willing to accept the group norms, as they perceived them. In the next section, I will show how this role conflict was resolved.

Bringing it All Together

In this section, I combine the academic research with my own experience and present some solutions to the problems that can occur in team dynamics. Where I present examples, the circumstances and roles are unchanged (i.e. they were real incidents, not a composite of several incidents), but the names have been changed.

The Carousel – the Solution to the Restaurant Problem

Back at the restaurant, the solution was simple. Whyte noted that since both the cooks and the waitresses perceived themselves to be higher in status, the solution was to decouple their interaction. The restaurant installed a carousel to hold the orders – the type still seen in most restaurants today (qtd. in University, pg. 395). The waitress takes the customer’s order and, rather than giving it directly to the cook (which would constitute giving the cook an order), places it on the carousel. The waitress has no need to directly interact with the cook. The cook is then free to take the order at his or her own leisure. (Thus, the cooks were not actually taking orders from the waitresses!) This was enough to break the perception and end the conflict.

I used this lesson to resolve a conflict that arose in a small software group. “Sally,” a software tester, worked with “Tim,” a more experienced tester. Both Sally and Tim had the same grade-level. Sally routinely took direction from Tim, since Tim had more experience, and the two worked well together. After several months of working together, Sally was transferred (at her request) from testing to my software development team – as an entry-level developer. This was a lateral transfer, so Sally retained the same grade level as Tim. However, in Sally’s eyes, the transfer was an increase in status. Almost immediately, conflict arose between Sally and Tim. Now that Sally perceived herself to have a higher status, she began issuing orders to Tim! Since Tim had more experience and was up for promotion, Tim naturally felt that he had higher status, and refused to accept what he felt was a degradation of his position. My solution involved: a) explaining the perceived status issue to each person individually, and b) establishing a semi-formal handoff from software development to testing, using a checklist. Tim and Sally may still have retained some hard feelings, but they were soon working together constructively. Using the checklist as part of a semi-formal handoff process served to decouple their interaction.

Shortly afterwards, a similar problem occurred between the entire software group (including testing) and another department. The other department felt free to make demands for the software group’s time, such as performing installations or reviewing 200+ page documents. In software development, a written software change request has long been used to allow a requestor to request changes and to feel that they are being heard, while simultaneously giving the software group the control to assess the impact and to ensure that they have the resources they need before the request is approved. Tim simply instituted a less formal version of the software change request – a development group request form, which could be used to make any type of request for the software group’s time and resources. Each request was assigned a tracking number and could be scheduled as resources became available. This served the same role as the carousel in the restaurant and had the same effect. All departments now had a way to request services and feel that they were being fairly serviced, while we retained the ability to approve or disapprove requests for our time on an objective, rational basis.

Cross-Functional Education

For work-related tasks, educating each team member in the entire process is probably the most powerful tool for eliminating role conflict (i.e. giving them the “big picture”). In my own experience, in two separate companies with disparate corporate cultures, I have found that presenting classes in what I do and how I serve their needs has done more to dispel role conflict than an army of industrial psychologists. By making an effort to understand the needs of other team members, then presenting software development from the viewpoint of how I serve their needs, I de-mystified the software development process. Also, by showing how I was serving their needs, I was refusing to participate in the role conflict. I concluded each training session with how they can help me to serve them better (which was a sneaky way of telling them how they can serve me). Educating the other team members let them take control of their own roles. This method also allowed me to confirm each person’s competence through education and communication. This leads to another tool for eliminating role conflict – interpersonal communication skills.

Interpersonal Communication

A large body of literature and seminars already exists describing the importance of communication skills in the workplace. My opinion is that if other team members don’t understand or recognize my needs, it’s because I have failed to tell them in an appropriate way. This means that if I have told them and they still fail to understand, then I am using the wrong medium of communication. For example, if I am communicating via e-mail, then perhaps the telephone or face-to-face conversation would work better. If I am frequently discussing the same topic in meetings, a training session may better serve. Interpersonal communication becomes more challenging across even the smallest of cultural barriers. Here is an example from my own experience, in which two people created conflict purely out of differences in interpersonal communication styles.

The Scenario

Billy was an entry-level programmer whose primary duty was to provide technical support to the software testing group. Billy was enthusiastic, creative, and eager to take the initiative. He was well liked by his peers and always went directly to the point on any work issue.

Sally was a senior level tester in the software testing group. Sally was methodical, detail-oriented, and sociable. Sally was admired by her peers, and preferred chatting before getting into the work details. Both Billy and Sally were affable, professionally competent, and looked forward to working together.

There is a natural conflict between software developers and software testers. Developers work long, hard hours to write a program, only to watch the testers happily destroy those programs in mere minutes. Both mindsets are essential to producing quality software, and when the group is functional, the two mindsets produce a constructive dialectic – a beneficial conflict whose synthesis is greater than the sum of the parts (University 569). Unfortunately, this beneficial conflict did not occur between Billy and Sally.

After only a few weeks, Billy and Sally were nearly at each other’s throats! Their hostility had escalated to the point of angry e-mails criticizing each other’s attitude and behavior! Each one detailed instances where the other had misbehaved. Each felt that they were the innocent victim of the other person’s arrogance and stubbornness. Finally, Sally threatened to resign if she had to continue working with Billy. Worse still, they began copying their e-mails to their co-workers, and finally to their respective supervisors and the department vice-president! I had to act before their behavior became an issue for Human Resources.

Possible Outcomes

In functional organizations, the natural conflict between programmers and testers results in a collaborative effort to resolve the conflict. However, in this case it was producing destructive behavior. Initially, they both tried to resolve their dissatisfaction in a constructive manner, by privately voicing their concerns. However, that only fueled the fire! Eventually, they both became so dissatisfied that Sally’s behavior became actively destructive by threatening to quit, while Billy became passively destructive by avoiding his duties (University 209).

At this point, three scenarios seemed likely: 1) Billy would continue his passive-destructive behavior until Sally resigned, 2) the department vice-president would dictate an end to the unacceptable behavior, or 3) Human Resources would take disciplinary action, which generally meant probation or termination. Most companies prefer an impersonal method of handling conflict: address the behavior and not the attitude. This helps them to avoid incorrectly attributing the employee’s behavior to a perceived attitude (University 147-50).

Unfortunately, after talking with both individuals, I became convinced that addressing only the behavior would have a negative effect. Investigating only the facts and behaviors of each incident had only entrenched Billy and Sally even deeper in their positions (Thompson, Aranda, and Robbins 234-35). This is because both parties were interpreting events in the way that was most favorable to themselves. Each person felt that they were truly an innocent victim! Each person was convinced that only the other person held any bias. Therefore, Billy and Sally were unwilling to assess their own behavior.

Also, if each had simply been ordered to change their behavior – regardless of their attitudes – I believe that they would have simply withdrawn from interaction and become passively-destructive by avoiding their duties. Rather than collaborating or even compromising, they both would have chosen avoidance, eventually resulting in the loss of one or more valuable employees (University 573 – 74). To make matters worse, their antagonistic behavior began infecting others in the test and development groups, each seeing the other group as the “enemy.”

The Actual Outcome

I first became aware of the conflict when they began copying their supervisors and the department vice-president on their inflammatory e-mails. Individually, I knew that each person actually respected the other person’s job, so I knew that this was not merely an escalation of the normal programmer-tester dialectic. Also, I had frequently seen each person work well with other programmers and testers. This led me to believe that the issue was not simply a personality conflict or a perceived status difference between testers and developers. I suspected that the real conflict lay deeper than their consciousness.

Sociologist Edward Hall points out that “…the most important paradigms or rules governing behavior, the ones that control our lives, function below the level of conscious awareness…” (43). He also explains the difference between low context communication and high context communication. Low context communication relies on the words that are explicitly transmitted to carry the message. High context communication relies on shared symbols, such as body language and voice tones, and the communication lies in the shared meaning of those symbols. High context communication relies very little on the actual words to convey the meaning. High context communication is a rapid and efficient means of communication within the same cultural context, but is subject to distortion when used across cultural boundaries. Hall further asserts that modern management methods are less successful than they could be primarily because management consultants attempt to use only low-context communication and ignore the high-context messages within the organization (Hall 91 - 93).

Hall notes that when the high context message conflicts with the low context message, it is the high context message that is believed. I remember when I was young and would get caught with my hand quite literally in the cookie jar; my mother would scowl and ask: “What are you doing?” I immediately knew her high context scowl to be the real message – not her low context question. So rather than reply with “getting a cookie” (low context), I looked penitent (high context).

To look for Billy’s and Sally’s high context messages, I held private meetings with each person. Rather than listen to what they said, I listened to how they said it. I listened to the context of their messages, and carefully worded my responses with “I” language (e.g. “I perceive”, rather than “You are”), to reduce the tensions and promote honest responses (Adler and Towne 205 – 08). In this manner, I tried to discern the antecedent conditions that were producing the perceived conflict.

The first thing that became apparent was their use of rhetorical questions. Both in e-mails and in their early attempts at reconciliation, Sally frequently used rhetorical questions, such as “I don’t see why…,” or “Why can’t you… .” However, men and women use rhetorical questions for different reasons. According to Dr. John Gray, when a woman asks a rhetorical question she is generally expressing frustration and expects to receive sharing; whereas, when a man asks a rhetorical question it is generally meant as a direct challenge (51). Therefore, when Sally was asking “Why can’t you …” Billy was hearing a direct challenge to his ability. In addition, Sally’s habit of chatting about problems was perceived by Billy as an invitation for more advice (Gray 64). But Sally saw his “helpful advice” as unsolicited, condescending, and indifferent to her social needs; she felt insulted.

However, the greatest difference that I saw was in their styles of communication. Billy relied heavily on low context communication, while Sally relied heavily on high context messages. Billy’s voice was monotonic, and under stress he became even more flat and monotonic. Sally, on the other hand, had a wide vocal range and viewed a monotonic voice as anger. Also, Billy always went right to the facts, whereas Sally wanted to “connect” socially before getting to the technical issues.

What had happened was quite simple. When Billy went to Sally with an issue, he unintentionally ignored her need to connect and instead gave what she saw as “unsolicited advice,” in a monotonic voice (which she perceived as anger). Sally responded, using her naturally modulated voice (which Billy perceived as anger). Each one now thought that the other was angry – simply from their voice tones! Billy responded by speaking in more of a monotone; Sally then felt that he was getting angrier and became more modulated – and this cycle fed on itself until it grew out of control! Each one thought that the other person was angry, when in fact neither one had ever been angry with the other!

Once I saw the root cause, I stopped all discussion of the “facts” of the individual incidents, and instead made each person aware of how their communication style was being perceived by the other. I made it clear that I was not asking anyone to change styles; I only asked them to be aware of their style and realize that no one was actually angry. Within the week, Billy and Sally were happily working together, and the change was permanent!

Solidarity in Very Small Groups

A complete software development group requires both software developers and testers (though each may have different managers), but some software groups tend to be quite small. During the course of the project, both developers and testers must work together and share roles. However, which person feels that they have a higher “status?” In my own work experience, with few exceptions, both the developers and the testers each feel themselves to have a higher status than the other. Developers are proud of their creations, whereas testers are proud of how quickly they break them! This conflict is often ameliorated if the testers and developers are in separate groups, isolated by a formal layer of communication (i.e. a “carousel”). This allows each group to maintain their own set of norms without having to feel that they are “taking orders” from the other group. However, in very small groups this level of isolation may not be possible. In my own experience, I have only seen testers integrate into the same group with developers when both sides have some experience acting in the other person’s role, and both sides agree to share the same goals and norms. Adding a semi-formal handoff from development to testing (like a checklist) is also helpful. Such a small group is held together by mechanical solidarity, and conformance with the group norms is essential to avoid destructive conflict.

My experience in very small groups has been that the personality of the group members is at least as important as skill. Members of very small groups must share multiple, overlapping roles with other group members. In a small group, breadth of skill becomes more critical than depth, and personality becomes more important than technical ability. In one job experience, “Frank,” an extremely skilled tester, was rendered completely ineffective because he refused to accept any of our group norms. Since we were such a small group, walking over to someone’s desk and holding an impromptu meeting was the preferred method of resolving minor issues. Frank, however, refused to communicate either verbally or by e-mail and would only communicate using formal, written documents. Frank may have been effective in a large, organic company; but the resulting conflict in our small group ended in his eventual dismissal. His replacement was not as technically skilled, but was much more productive – by virtue of a personality that allowed acceptance and ownership of the norms in our tiny group.

Conclusion

Cross-functional groups frequently find themselves in role conflicts – Software development vs. Testing; Marketing vs. Engineering; Engineering vs. Manufacturing; customers vs. the Company; and Quality Assurance vs. Everybody. Each group member understands their own point of view and why they are essential to the project; but unless they have worked in other functional areas, they may fail to understand other member’s points of view. Even the most affable and competent employees may find themselves at odds, simply due to their perceived difference in knowledge and status, or by reason of different communication styles. With smaller groups come even less formal role boundaries and higher degrees of mechanical solidarity.

There are several methods to help teams to “gel” with mechanical solidarity, such as cross-functional education, interpersonal communication training, and formal methods of interaction. Supervisors must also be sensitive to the warning signals of de-norming. By maintaining an awareness of the group norms, supervisors and team members can eliminate destructive conflict and foster the kind of constructive conflict that makes the whole greater than the sum of the individual parts.

References

Adler, Ronald B., and Neil Towne. Looking Out, Looking In. 9th ed. New York: Harcourt Brace College Publishers, 1999.

Durkheim, Emile. Emile Durkheim, Selected Writings. Ed. and trans. Anthony Giddens. Cambridge: Cambridge University Press, 1993.

Gray, Ph.D., John. Mars and Venus in the Workplace. New York: HarperCollins, 2002.

Hall, Edward T. Beyond Culture. New York: Anchor Books, 1976.

McGrew, John F., John G. Bilotta, and Janet M. Deeney. "Software team formation and decay: Extending the standard model for small groups." Small Group Research. 30.2 (1999): 209-34.

Merriam-Webster’s 11th Collegiate Dictionary, version 3.0. CD-ROM. 2003.

Thompson, Leigh, Eileen Aranda, and Stephen P. Robbins. Tools for Teams. Ed. Craig Swenson. Boston: Pearson Custom Publishing, 2000.

Tuckman, B. W.. “Development sequence in small groups.” Psychological Bulletin. 63.6 (1965): 384-399.

University of Phoenix, ed. Organizational Behavior. University of Phoenix custom edition e-text. Boston: Pearson Custom Publishing, 2001. ORG/502 – Organizational Behavior. Resource. University of Phoenix. 5 Sept. 2001. <https://ecampus.phoenix.edu/secure/resource/resource.asp>.