Group Dynamics

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 posted to Piazza with the topic line ``Group n norms for project p''. 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 these were created by past class participants. Some of these norms 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.
• Hold ourselves and each other accountable for what we promise; let teammates know early if we need help.
• 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.
• Be open to constructive criticism; we learn by engaging with each other's ideas and trying to find complications.
• Break coding into clean sub tasks, but to the extent possible we should all understand how the whole program works and make an effort to explain our work to each other.
• Commit to keeping up with time other group members are putting in on a weekly basis; skipping a week and then trying to make up for it doesn't work.
• Meet to discuss ideas but code on our own to make implementation more efficient.
• Work for meetings, not during meetings; we reserve that time for discussion.
• Clearly write down and communicate what we will work on.