Group Dynamics

This year, for the second time, we're going to try to explicitly address the question of how to create good group dynamics. For background, all students should read the NY Times article on how Google studied the effectiveness of groups. This reading must be completed before your first group meeting.

Once the groups are selected for each project, you should schedule a one hour group meeting right away with the following agenda:

• The first 30 minutes should be spent introducing yourselves, and sharing something about yourself with the group.
• The remaining 30 minutes should be devoted to explicitly identifying group norms. The most important norms should be written down (maximum of 5, each one sentence) at the end of the meeting and sent to the professor by email. Hopefully you can agree on such norms; if you can't, include norms together with annotations of who is in favor and who is opposed.

The purpose of explicitly identifying these norms up front is to create shared expectations among group members. Here are some sample norms, which may or may not match the inclination of your group. Some of them are mutually inconsistent, so be selective about what your group chooses as its norms. The list below is merely illustrative, and far from comprehensive, so you should not feel limited by this list. Also feel free to try different styles for different projects, e.g., individual coding for one project and team coding for another. These norms should not be seen as restrictive: if the group decides to adjust its norms part way through, that's ok.

• Discussions work best in a free-for-all environment where interruption is considered OK, as long as it is done politely.
• Discussions work best when we each take turns speaking and don't cut each other off.
• In situations where the group expertise on a subtopic is uneven, team progress is best assured by the experienced member(s) bringing the other members up to speed, and delegating work.
• In situations where the group expertise on a subtopic is uneven, team progress is best assured by the experienced member(s) working independently, and allowing the other member(s) to focus on a different aspect of the project.
• In situations where the group expertise on a subtopic is uneven, team progress is best assured by collaborative efforts such as pair programming. (Tip: if you do choose to go with pair programming in this situation, the less experienced person should be at the keyboard.)
• Regular sharing of how each group member feels about the project's progress is good because it makes sure group members are happy and it allows conflicts to be resolved early.
• Concrete contributions of code/experiments/designs/ideas is how an individual's participation should be measured.
• Regular face-to-face meetings are essential.
• Regular non-interactive communication (e.g., email, Google docs, code repositories) will allow the group to be productive despite having different availabilities.
• When implementing code, we expect to set internal deadlines for subtasks and to stick to those deadlines as much as possible.
• When implementing code, we expect to approach the problem organically, working and brainstorming without setting arbitrary deadlines.
• We expect to work collaboratively most of the time, brainstorming and coding together.
• We expect to work individually most of the time, brainstorming and coding separately, then sharing ideas/code with each other.
• Criticism of another group member's idea is encouraged so that good ideas can be refined and separated from not-so-good ideas, as long as the criticism is respectful and not personal.
• Group members should have an equal say in choosing the direction that the group takes.
• Group members are comfortable taking leadership/subordinate roles if mutually agreed.