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 of 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 (Instant Messaging, texting, etc.) 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. People may feel uneasy about other people volunteering to complete tasks. 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. Creating roles for everyone can be helpful here, that way everyone feels that they have responsibility. Don't assume that working with all of your friends would solve the problem (Check out Part IV: Student Project Myths).
In contrast, a group member may alienate him/herself from the group and try to do the project as his/her own little team (a team of one), 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 early, 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.
So far I have talked about general team dynamics, but specific meeting conduct is also important to discuss also. There needs to be agreement and buy-in from all group members in order for meetings to work. If someone does not show up or shows up late on a regular basis, this behavior is very disruptive and time is wasted bringing the person up to speed (or you don't do anything while you wait for him/her to arrive). Cell phone interruptions are also annoying, rude, and can lead to wasting everyone else's time. When brainstorming or issue discussion is taking place, the meeting facilitator should ensure that all group members are being heard from and not just the loudest or most aggressive members. You could be losing valuable knowledge during your team meetings and not even know it.
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 that we can add to our list of open issues" and then move to someone else or "I'd like to backtrack a bit to topic X 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 member, 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.
A side effect of the verbally dominant team member is that others will not get a chance to speak or shy team members will withdrawl altogether. I have seen this happen and then the domineering student accused the others of not participating when it came to peer evaluations.
You and your teammates may be successful in getting the domineering student to at least try to modify his/her behavior. But then again, you may not. After all you can't change someone but they can change their behavior if they want to. Take a moment and think about what the specific issue(s) are:
Many of these issues can be addressed with team and meeting structure. Team structure means roles. Even if you are going to use the Egoless approach, you still need to have some roles even at a low level or for limited periods of time. That enables each team member to know what he/she is in charge of while still accepting input or managing others in that area that the role covers. Such roles can provide leadership in various areas that still provides for input and feedback by others.
Meeting structure is critical for a domineering student (and other types as well). Please see Section 1.4 Running Group Meetings for further discussion.
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. It is harder to not answer a specific, pointed question.
A similar situation is when your boss (or instructor) is asking you how your project is going. Most of the time, you will just say "fine" as you type away on your keyboard, bleary eyed. 'Fine' does not help your boss. A more targeted question would help your boss elicit more information out of you.
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. The nice thing about the web is that there are numerous tutorials and information to help you. Your department may have tutoring available. If you need help, take advantage of it and allot time for it in your personal schedule. However, if the person really does not belong in the course, talk to him/her about it 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.
On occasion I have seen such a student remain in the course. If this turns out to be the case, be sure to include the student but we thoughtful as to what tasks are assigned to the team member. I have seen teams assign students critical project tasks when it was clear that the student would not fulfill them. Another mistake that I have seen teams make is to assign the student the task of creating or maintaining the documentation (e.g. SRS, test plan). In this situation, the risk exists that the student will not complete his/her duties (thus negatively impacting the team's project artifacts) but the student does not get the chance to learn new technical skills. These situations have always perplexed me as an instructor. Provide challenging, technical work but do not have it be in the project's critical path for delivery.
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 at the first instance of this behavior. 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.
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.
6.7 Polar Opposites or When 2 Team Members Just Won't Get Along
This is a variant of the team members described in section 6.2 and/or 6.5. Having two team members who virtually always disagree and who are certain in their individual position can potentially tear the whole team apart and leave many casualties (including the project itself). As an instructor I have seen a team that falls into this situation.
The team consisted of five upper-division students. All of the students were competent though two of the students were higher achievers. These two students were bright, self-confident individuals who were also diametrically opposed and sure of their positions. They would interrupt each other and others on the team, and at times yelling and name calling ensued (though I was not there for that behavior). Each person also saw themselves as the victim of the other's behavior. The other team members spoke to me outside of the team meetings about things that happened and guidance. Each of the two 'polarized' team members also spoke to me, though individually. As behavior quickly escalated (with project work jeopardized and teammates becoming more frazzled), I (as the instructor) had to firmly lay down the law during a team meeting. I took great effort to speak to the team as a whole, noting the behaviors, without embarrassing anyone. During the rest of the project, I kept in touch with all team members (in addition to general advising) to ensure that they were not alone. While the behavior did not entirely disappear, things did improve greatly. The project was successful and the team was professional.
I would be delusional if I believed that I changed the behavior of the two students. However, creating boundaries and consequences for them kept the project and team on track. If this situation is present in your team, try to impose a meeting structure where a Facilitator runs the meeting. The Notetaker should document negative behaviors that you need to share with the instructor. Try to talk to each "polarized" student individually. You want to avoid affixing blame, but instead speak to behaviors and their solution/mitigation. Such team members have big egos, and they will defend them when attacked. In the situation outlined above this did not go anywhere without instructor intervention. So speak to your instructor before the team and the project fall apart.
6.8 The Distractor
A student that distracts the team can be domineering and/or masking incompetence. Distraction can take many forms including:
I have seen a Distractor work with both consenting and semi-consenting peers. Distractions are easy even when there is not consistent instigator. Mitigating distraction is important, and limiting meeting durations through the use of meeting structure is critical. When an unrelated topic is introduced, stop and reprioritize the topics on the agenda and reorder the topics (you may also agree to move the topic to the end of the topic list or table it to a later meeting). If the Distractor's behavior is not addressed early and consistently, the effects on the project will accumulate over time and the behavior will be harder to control. The team needs to come to consensus as to how to address distraction. Don't rely on your instructor for this one.
I once had a team who saw that distraction was hurting their project and they had an interesting solution that worked for them. During team meetings, a person was designated as the Taskmaster. Everyone agreed that when discussion went off-task or discussion was going nowhere, the Taskmaster would interject and bring the team back on task (or move on to the next task, as relevant). This was a separate role than the Facilitator, but the Taskmaster could be associated with the Facilitator role. This arrangement worked very well for the team after the role was initiated.
When the Distractor brings in "props" that initiate and prolong distraction (e.g. alcohol and video games), consider the meeting over. Part of this can be traced to holding meetings in someone's apartment or at a bar. Once you bring in these props, you may be inadvertently giving permission for such distraction on a regular basis. You should take time for fun, but don't confuse it with time allocated for a meeting. You can have the meeting and then have fun afterward. I have an example of distraction, that may be familiar to you, in the Student Project Myths section.
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.