Forming Teams
Most people learn better together than they do on their own [Michaelson2004]. As long as their teams work well they achieve higher grades, retain information longer, are less likely to drop out of school, and graduate with better communication skills and a better understanding of what will be expected of them in their subsequent careers.
But that “as long as” is important. A badly-run team is worse than no team at all, since people will waste hours or days arguing with one another, duplicating or undoing each other’s work, and wishing that they had gone into gardening instead. These conflicts are more wearying than any number of buffer overruns or accidentally erased files, which is why most computer science courses stick to individual assignments. It doesn’t take much to make a team work smoothly, though. The rules for running meetings posted earlier are a good start; this post looks at a few other things you can do, and [Parker2019] goes into more detail.
Team size
I once heard an anthropologist ask, “How big is a sports team?” When people said it depends on the sport, she explained that in fact they all have about half a dozen members. Anything larger than that splits into smaller groups: the forwards and backs in rugby, the infield and outfield in baseball, and so on. She went on to explain that hunting parties in non-agricultural societies are usually that size as well, as are basic military units around the world (a platoon is two squads of six people). Since we can only keep a handful of things in our short-term memory at once, that’s as big as a team can practically be.
The same rule applies to software development. Three or four people can work tightly on a single piece of code, but when there are more they define some interfaces and develop in parallel. Tools like GitHub help groups coordinate more effectively, but the groups themselves stay the same size.
Teams of three to five provide a good balance between skills and accountability. A team of two may not have enough breadth and background to tackle a large piece of work; more importantly, one or the other person is likely to take a dominant role. If you put six or eight people in a team, on the other hand, you may not be able to divide up the work in a way that will keep everyone engaged and busy. Teams that size or larger also make scheduling meetings much more difficult and increase the odds that at least one member will be a hitchhiker.
Many students prefer to select their teammates, and students with high grades tend to want teammates with a similar profile. [Post2020] found that matching students by grade led to a small improvement in outcomes, with a larger impact on team grades than on individual ones. he same study found that members of self-selected teams were more likely to already have friends on their team, but that this was negatively correlated with outcomes (possibly because people are less willing to hold friends accountable for missed work).
One surprising finding is that having students with a range of grades in the same team either has no effect or improves outcomes for everyone [Donovan2018,Farland2019,Auvinen2020]. It’s easy to see how this benefits teams of weak students: they are likely to get coaching from their stronger teammates. One theory for why it also helps stronger students is that the best way to learn something is to explain it to someone else; bringing a weaker teammate up to speed will usually do more for your grade than spending those same hours hacking or reading.
In my experience, teams of strong students are also more likely to use a divide and conquer strategy, effectively reducing the project to a set of parallel sub-projects handled by one person each. This may feel more efficient, but most of the benefits of working in a team are lost: there’s less back-and-forth discussion of design issues and little improvement in communication skills. Those may not be important to you at first, but if there is a final exam in your course with questions about the project work, your mark on it may depend on how much you know about your teammates’ work.
The most powerful argument for instructors selecting teams, though, is that’s how it works in the real world. You probably won’t get to pick your colleagues if you join a company or an academic research group. Instead, you’ll be put on a project and expected to work well with whoever else is on it. Your performance will depend as much on your ability to get along with others as it will on your raw technical ability, so you might as well start practicing those skills now.
If instructors create teams, they should avoid isolating at-risk students. Women and members of racial minority groups are more likely to drop out of computer science than other students, particularly in first and second year, and one of the main reasons is feeling isolated or out of place. Research has shown that putting at-risk students together in the first couple of years can mitigate this problem [Margolis2002]. t is less necessary in upper years, since by then students have a stronger commitment to whatever program they’re in, but it still helps to prevent some of the problems discussed in the next section.
The biggest headache when instructors select teams is scheduling. COVID-19 has made distributed work more normal, but the University of Toronto has three campuses spread across a large metropolitan area, which means some students commute an hour and a half each way to get to classes. Instructors should therefore take students’ schedules into account when forming teams. If the class is small, the simplest way is to get each student to fill in a weekly timesheet showing when they’re available and then group people who have large blocks of overlap. If the class is larger, a web-based calendaring tool may be easier. Instructors can even try to use whatever software the university uses to figure out course timetables, although that usually doesn’t scale down to in-class scheduling.
Another factor to take into account is that some people are naturally early birds while others are night owls. Putting the two on the same team pretty much guarantees that someone will miss meetings or sleep through them no matter when they’re held. Simply asking people, “Do you prefer to work in the morning, or the evening?” can be surprisingly effective [Zavgorodniaia2021].
However people are put together, each team should have at least one block of two hours to work together each week outside of class. Teams should also try to find a second block that’s half an hour long for a weekly meeting. Try to keep the two blocks separate so that it’s clear to everyone when they’re supposed to be talking about the project and when they’re supposed to be doing design, writing code, testing, and so on. If the two are scheduled back-to-back, the meeting will drag on into working time or vice versa.