17-313: Foundations of Software Engineering

Recitation 4: Team Dysfunction

Overview

This recitation will give you the opportunity to practice and reflect on the roles you play within a team. We’ll be going over common team dysfunction issues and discuss mitigation strategies.

Context

All teams are inherently dysfunctional in some sense. This is inevitable as they are made up of fallible, imperfect human beings, each with different goals and intentions. Thankfully, the causes of dysfunction are both identifiable and curable, but definitely not easy to resolve. Making a team functional and cohesive requires courage, good communication, and a strong resolve to making the team better.

Part 0: Preparation

Use a random number generator to get a random number from 1-7. Next, check Appendix A for a detailed description of the role associated with your generated number.

Keep your role secret from the other people in your group!

Part 1: Trade-off and Task Planning Meeting (15 min)

Congratulations! Your team has been hired as software developers to work on CMU’s graduate school application system. For your first assignment, you’ve been asked to develop a better system for handling online payments made by graduate students for their applications.

Task: As a team, research and find tools that can be used to improve the payment system. This can be anything from supporting better payment methods, storing payment information, etc. Compare the strengths and weaknesses of the tools. At the end of this activity, your group should have agreed on a tool to use.

Be sure to also assign each member a task in order to integrate the tool into the payment system.

Activity Notes: Each team member should keep their role secret and try to act accordingly during the meeting. Try to identify the roles played by your team members and, if possible, fix the dysfunction.

Part 2: Group Discussion (10 min)

As a group, discuss the following questions:

What dysfunctional characteristic did your teammates display?
How would you handle those dysfunctional characteristics in future situations?

Then, as a group, prepare some responses to the questions in Part 3.

Part 3: Class Discussion (10 min)

As a class, discuss the following questions:

Was the meeting effective? Why or why not?
What team dysfunctions did you observe during the meeting?
Were there any instances where your role directly clashed with someone else in your group?
Were you able to identify the roles played by the other members? What problems were caused by their behavior?
Can you think of mitigation strategies and solutions to avoid these problems?

Appendix A: Role Descriptions

Below a description of the roles for each number 1-7 and the behavior of each one:

The Contributor: You are aiming for general team success. Ask for your team members’ opinions often, actively discuss solutions with your team, and demonstrate engagement throughout the activity.
The Know-It-All: You think you are extremely experienced and know how to solve all problems on your own. Act like you don’t need any help and just tell your team to watch while you search for the tool. Be pushy in telling other members how to search for information about the tool and shoot other members’ ideas down.
The Silent One: You assume your team members know everything and don’t feel you need to say much. Pay attention to the meeting, but simply do not suggest anything. Remain passive but friendly.
The Agreer: You are afraid of raising conflicts and hence decided to just go along with whatever your team decides. Agree with everything during the activity and do not question the decisions of your team.
The Hitchhiker: Your goal is to do as little work as possible. Be friendly but not productive. Try to end the meeting as quickly as possible so you can slack off. Get other people to step in for you and take over your tasks. Make fake attempts to make it look like you tried to figure out the task, then pass off the work to someone else.
The Flaker: You’re interested in the project, but don’t want to contribute more time than necessary. Actively contribute to group discussions until tasks are being assigned, then begin giving reasons why you can’t contribute more (i.e. busy with interview prep, midterm, or other assignments). If asked to do something else, continue finding other excuses on why you can’t contribute.
The Perfectionist: You want this project to be absolutely perfect in even the most minor details. To you, it’s most important that the tool’s source code is fully readable, perfectly documented, has a large test suite, and is aesthetically pleasing, and you will argue for or against the tool based on these minor details.