Chapter 5 | Chapter 6 | Chapter 7
The following eleven behaviors are some possible personal exchanges that transpire during a group discussion. The ability to identify one's own or another person's behavior allows you to foresee how others may interpret/misinterpret you. I am not implying that you should analyze every statement you are ever going to say. Instead it should be made clear that certain ways of presenting information or emotions can be misunderstood by your audience. In addition, you should be aware that certain behaviors are not productive ways of discussing an issue. The eleven possible behaviors are grouped into four main categories: initiating, reacting, clarifying, and process behaviors.
5.1.1 Initiating Behaviors
Initiating behaviors are proposals or suggestions to the group that call for action. New proposals and an addition to a proposal are both examples of subject initiation. There are two initiating behaviors: Proposing and Building.
Proposing brings forth a new suggestion, proposal, or course of action (e.g. "I suggest that we organize the project into five modules." or "The File Menu can contain an option to print"). After all, a discussion has got to start somewhere.
Building takes the form of a proposal, but actually extends or further develops a proposal made by another person (e.g. "...and your plan would be even better if we added a scroll bar at the edge of the window." or "A pizza sounds great, and some sodas would be good too."). Since the initial proposal is not the final solution, building is effective in producing an alternative or revised plan.
5.1.2 Reacting Behaviors
Reacting behaviors involve the affirmation of or objection to a person, his/her opinions, or an issue. There are three reacting behaviors: Supporting, Disagreeing, and Defending/Attacking.
Supporting is a behavior that makes a conscious and direct declaration of agreement with or support for another person, or his/her concepts and opinions (i.e. "Sounds okay to me" or "Fine"). Positive feedback is always good.
Disagreeing is the direct objection to another person's opinions. Disagreeing is an issue-oriented behavior (e.g. "Your third point just isn't true." or "What you're suggesting just won't work."). This behavior is normal in a discussion, but don't let it evolve into a Defending or Attacking behavior.
Defending/Attacking entails attacking a person directly or by acting defensively. This behavior is usually people-oriented, and involves value judgments and emotional overtones (i.e. "That's stupid!" or "Don't blame me; it's not my fault. It's John's responsibility."). Defending and Attacking will only bring unhappiness and plenty of tension to the group. There are better ways of handling a discussion. If you are being verbally attacked, try not to play into the instigator's hands by shouting back. Instead try to speak rationally and direct the discussion to the issue at hand rather than playing a game of Who's To Blame.
5.1.3 Clarifying Behaviors
Clarifying behaviors attempt to clarify an individual's or group's understanding of the issues. Information interchange and summarization are involved in the clarification. Testing Understanding, Summarizing, Seeking Information, and Giving Information are the four behaviors that comprise this category.
Testing Understanding seeks to establish whether or not an earlier contribution has been understood by the individual. It differs from seeking information in that it is an attempt to ensure agreement or consensus of some kind, and refers to a prior question or issue (i.e. "Can I take it that we all now agree on our tasks assignments for this week?"). This behavior is similar to Summarizing, but takes the form of a question.
Summarizing restates the content of previous discussions or events in a compact form. This behavior can be useful to ensure that the entire group is up to date with events that have transpired (e.g. "So far we have agreed that John will finish module A, while Maria and I begin module B."). This will insure that you and the rest of the group have a clear understanding, even if the summary isn't in the form of a question.
Seeking Information seeks facts, opinions, or clarification from another person pertaining to a proposal (i.e. "Can anyone tell me which page this is on?" and "Have you tested that thoroughly?"). This behavior insure that you are up to date with the topic of discussion. If you have questions, ask them as soon as possible (i.e. don't leave questions until the night before the project is due).
Giving Information offers facts, opinions or clarification to a proposal (e.g. "The new system is easier to operate." and "I'm worried about missing the deadline."). Feedback is always appreciated even if it is not always positive.
5.1.4 Process Behaviors
Process behaviors entail the obstruction of or opening up of the discussion process to group members. Bringing In and Shutting Out are the two behaviors that constitute Process Behaviors.
Bringing In invites views or opinions from a member of the group who is not actively participating in the discussion (i.e. "Lee, what is your opinion on the layout of the User's Manual?"). This behavior may introduce some refreshing new ideas from a shy or reserved team member.
Shutting Out excludes another person or reduces their opportunity to contribute. Interruption is the most common form of shutting out (e.g. Lee: "David, what do you think?" Eric: "I think..." -- Eric has interrupted David and shut him out of the conversation). This behavior may seem harmless, but it is disrespectful and will not give someone the opportunity to contribute to the discussion.
5.2 Communication as Part of Software Development
In the previous section, you learned about the different types of communication. This section presents communication that will occur during the project within the team and between teams. Participating in a project team is not a one-time class activity that you endure like a visit to the dentist's office. You are in that team for the duration of the class, and it is more akin to being placed on an island with a group of people where your group task is to get back to civilization. Sounds a little dramatic and perhaps a bit exaggerated, but definite parallels exist. You have not necessarily chosen your teammates. You have a long-term goal (the project) which is comprised os several short-term goals that build upon one another. In both cases communication is key to success. One person will not have the time and resources to complete the course project or make it off the island.
Think of communication between member of a team and between teams (if applicable) as interfaces. Just as interfaces between modules of code are needed to run code cleanly, communication interfaces between software developers are needed to develop the project clearly. Maria, your teammate, is writing the user manual while you are implementing the front end of a database. While Maria should be familiar with all levels of the project, for the purposes of her task she needs to be familiar with the interface and features of the database that you are working on so that she can translate the technical details into a form that the user will understand. She does not need to be bogged down with all of the technical details that you are working on, but when changes are made that affect her work, it is your responsibility to inform her in a timely manner. The same means is communication is necessary if we were talking about two teams rather than two people. If there are multiple teams working on your class project, liaisons should be in place to act as the communication interface between groups.
In the case of communication between people and groups of people, communication
goes both directions. In the example above, Maria may offer you advice
on the Graphical User Interface because she has experience in the area
of Human-Computer Interaction. The key to having effective communication
is clear communication and timely communication. No one should have
to translate what someone is trying to tell them nor should they have to
hear about it after such a period of time that work will have to be redone.
When the project is underway, any change from one person/group affects
all other people/groups. Take advantage of email as a means of fast
communication. Waiting to talk to someone in class should not be
a primary means of communication.
6.1 Some or All Group Members Are Not Used To Group Projects
Many people are unaccustomed to working in a project group, and may feel uncomfortable participating in or initiating group discussions. During the initial formation of a group, there is often some tension present that can be compared to stage fright. This is normal for everybody. Social inhibitions create a lack of assurance about how to behave. At first comments are quietly spoken and very tentative. Long pauses occur between comments. This awkwardness will disappear quickly as group members get to know each other. Participation, communication, and negotiation will prepare group members, who are uneasy and unfamiliar with group interaction, for future group projects. The more practice in group communication, the better an individual will become in working with others.
In contrast, a group member may alienate him/herself from the group and try to do the project as his/her own little team, while ignoring everyone else. Possible solutions to this are to make an extra effort to make the group member feel included, discuss the matter with the individual, or as a last resort mediate the matter with the professor. After all, this is a true-to-life group project, not an individual assignment. Also, you can start the project off on a lighter note and have dinner or go bowling. You are going to have to work together for several weeks and an ice breaker activity is a good way to get to know one another.
6.2 The Dominant and/or Aggressive Group Member
This group member may try to dominate the time and issues covered in group discussions to meet his/her own agenda. It is up to the group to insure that no one person monopolizes the project or meeting, while each group member must exercise restraint and common sense (i.e. input various ideas without putting others down). If a team member is unnecessarily talkative and/or interrupts others, the team manager or other group member should assert him/herself and say something like, "That is a valid point" and then move to someone else or "I'd like to backtrack a bit to X-topic so that we can finish the task by Monday." It is a good idea to reroute the conversation to the project issue at hand (or sum up what has been said), because conversation will often stray away from seemingly unexciting or unpleasant topics.
If a group member is relentlessly domineering and/or aggressive, then discuss the issue openly. Be open but not confrontational. Confrontation only leads to defensiveness, and things can get out of hand. If no one in the team says anything directly to the offending team memger, the eventual result will lead to rising tension until the tolerance threshold is surpassed. This behavior is a prime candidate personal conflict (see Section 6.1). Negotiation will be especially important with a person with this personality, but don't sell yourself out in order to make someone else happy. After all letting a domineering person control the project can lead the team and project in some unpleasant directions -- they may be loud, but that doesn't mean they are right.
6.3 The Shy, Passive Group Member
This quiet group member is generally not participating at all (or very little) during group meetings. But don't assume that because this person is not speaking up, he/she does not have any good ideas. During group meetings, the rest of the group (or the manager at the very least) should make an effort to ask the shy group member for input in the discussion. As a result, the shy person may feel more comfortable with the group. If the quiet team member is not participating and is being ignored, then he/she may feel insignificant and alienated from the group. As a result, the individual may not perform his/her tasks effectively since no team loyalty will be present.
If the group member is also passive and easygoing, then a possible remedy is to bring in individual into the discussion in such a way that he/she is required to participate. You cannot say "Well Dave what do you think?", because Dave will answer with a nod or "It's fine." type of answer. Instead you would need to ask a question that requires a statement as an answer such as "Dave, what has been your experience with compression algorithms?" This may seem blunt, and thus an unappealing option for some to try, but it is often necessary to bring some people into a discussion.
6.4 The Group Member Who Feels Technically Unprepared For The Project
A group member who feels technically inadequate may become withdrawn and unproductive. The person can seek help on a specific technical aspect from another team member (or someone else), or take a role that best suits his/her abilities. Remember, no one is expected to know how to do everything in the project, otherwise why bother having it? However, all group members should have the opportunity for personal and professional growth during the course of the project. If the person really does not belong in the course, talk to him/her about and suggest that he/she has a chat with the professor. You shouldn't have to hand-hold them through every little task, you're busy enough. If it looks like the team will be meeting with the professor, have detailed examples ready to present.
6.5 The "I'll Do It All Myself" or "Anti-Group" Group Member
This group member is usually unaccustomed to working in a group setting and tries to make the group project his/her own personal challenge. Oftentimes, this individual is also a domineering or aggressive group member but this is not always the case. In my personal experience, this person is a quiet, keep-to-him/herself type of individual. This type of behavior is apparent from the offset of the project and the main symptom is the personal undertaking of group tasks that result in martyrdom and/or the recreation of the finished group task to meet his/her own standards. As incredulous as this sounds, I have seen this happen.
Possible solutions to rectify this behavior can range from open discussion to outright mutiny. Remedies are dependant on how cooperative or hostile the individual is. Discussion should always be earnestly attempted, and the whole group should be involved during the proceedings. If repeated open discussions are not fruitful, then seek out mediation with the professor. As I have said before, have substantiated and detailed proof when mediation is sought because the professor has to know whether or not the individual is being uncooperative or is being used as a scapegoat for group shortcomings. If all of this fails, then continue work on the project without the group member after informing him/her of your plans. Leave the option open for the group member to re-enter the group when he/she has outgrown his/her narcissism.
6.6 Cliques
When two or more group members create a subgroup that shuts out other members, this is called a clique. Cliques are potentially destructive in that they divide the group on personal issues. Sometimes coalitions can be productive in asserting ideas or thoughts to the group for discussion or approval, but cliques make an effort to steamroll ideas over non-clique members during discussion. The difference between coalitions and cliques, is that a coalition is a loose group of individuals based on an idea, while cliques is closed set of individuals that are tightly bound to similar ideas and personal (often extra-curricular) issues. Coalitions change with issues; cliques don't. This formation may be resolved with group discussion and/or group or role rearrangement. When groups are assigned, cliques are less likely to appear since the odds are in favor of friends not being assigned to the same group. As a result, assigned groups are more likely to be an even starting point for all members.
7.1 Personal Conflict
Personal conflicts occur when two or more group members cannot communicate, cannot stand each other, or cannot work together for whatever reason. In addition, a role mismatch can result in a personal conflict between the individual and the manager, the individual and the team member who is in the desired role, or both. This type of conflict can have disastrous effects on productivity due to tension among group members, when the group tolerance threshold has been exceeded. Possible remedies for personal conflicts are for the manager to channel the energy positively (this is easier said than done), and for the manager to examine the individual's personality in regard to the team and the perspective roles within it. Specific instances of personal conflict are discussed in Chapter 5. In these cases, the group will need to discuss these issues openly and frankly (but not in a confrontational manner).
7.2 Role Conflict
Role conflict occurs when the expectations of a team member are incompatible with reality. Examples of such conflict, are when a group member belongs to two teams and has overextended him/herself, and when a team manager imagines or encounters a loyalty conflict between his/her roles of manager (usually in regard to interaction to upper management) and as a team member. As a student, role conflict is possible, especially in a class like Computer Science 441. When I was enrolled in the Software Engineering II class, everyone was a member of two groups within one 30-person team. This type of conflict is often energy draining and leads to performance problems, because of the induced stress and guilt related to overwork. The best solution is to negotiate with upper management (the professor if he/she assigned the groups, otherwise with the teams involved), and the possible revision of one's role/assignments after examining existing work assignments and team structure. A good rule of thumb is to not overextend yourself by being the manager, or any other demanding role, in two groups. In the case of my CSC 441 class, no one was the manager of two sub-teams. In my case, I was the team's Product Manager and I balanced that large responsibility by avoiding large tasks in the Documentation group (of which I was also a member).
7.3 Issue Conflict
Issue conflict arises when members are at odds about the objectives for a software product they are trying to develop or personal values pertaining to them, when job performance is not as expected (piggybacking and social loafing), when rules and procedures are not followed, or when norms are violated (whether deliberately or not). Issue conflict is a normal part of problem solving, unless it interferes with productivity. This type of conflict can be avoided if the group establishes norms and procedural priorities ( in relation to the balance of power and the division of labor discussed in Chapter 1), clearly and early in the project. It is better to discuss how to reach a known goal rather than debate whether one was given the correct one.