Working in Teams

Having written about student projects it's natural to talk about working in teams because that's how much of our project work is done - students like it that way, and the lessons learnt are useful beyond software-writing - beyond academia too. Again, I'll start with a checklist

• Team size - We use 2, 3, or 6 (the 6 being split into 3 pairs)
• Who chooses teams? - We sometimes impose and sometimes let the students choose. Both options have pros and cons. With a yearly intake of 300+, letting students choose their own teams can be time-consuming, and self-selected teams might be rather unbalanced. There may be non-academic reasons for controlling team-selection (a mixed of genders and background, for example)
• Within a team, who does what? - Sometimes there are clear roles within a project. Sometimes the tasks are much less clearly delineated. For marking purposes staff need to know who did what.
• Is there a team leader? - Specifying that there should be one enforces a structure onto the team
• Planning overhead - What team-related milestones and deliverables are requested? An initial presentation? Gantt charts? Milestones? Some individuals who wouldn't plan a private project can see the point of planning when part of a team.

I like the idea of psychologically-profiling team-members at the start with a quick quiz, to see if the results are predictors of team dynamics. We don't do that, but one project does ask teams to complete a form at the end showing what percentage of the total workload each member did.

The same project also attempts to assess the time taken on the project and how much staff time was used (staff time is estimated to cost up to 250 pounds/hour)

Though students in general like working in teams, it can be a wounding experience. If team-members clash, how interventionist should staff be? Some staff involve themselves closely with teams and pro-actively influence dynamics. People at other sites sometimes offer mediation services. If staff leave groups to sink or swim, some will sink, and some innocent passengers will go down with the ship. We've had some generally popular team-based courses scoring un-exceptionally on end-of-year surveys because a few disgruntled individuals giving courses a zero rating. Reports include comments like "It quickly became apparent XXX did not have the self-discipline or dedication to be an effective team manager ... His tendency to speak to others in an authoritative manner despite the lack of useful input/output from himself created dissatisfaction amongst other team members."

By the end of a project, team dynamics can get out of hand. After 4 weeks, a team member was late for a final session. One of his team members growled "[He] does less damage when he's not here. I don't want him touching the code ever again."

Teams can also have problems if one person is repeatedly absent. For this reason we're tough on attendance.

We use online forums to encourage teamwork (and to give us a chance to identify teamwork problems)

According to "Pair Programming Illuminated" by Williams, L. and Kessler, R. (Addison-Wesley) students who work in pairs enjoy the work more, are more confident, and get better grades. Students typically ask half as many questions. Pair-programming helps female computer science students suggests that pairing is particularly beneficial for women. On the other hand there are courses (e.g. at the University of Washington) that have given up pair programming and have found that students get better grades (though the improvements may not be attributable to the teamwork decision).

In "Journal of Computing Sciences in Colleges" (Volume 28 Issue 2, December 2012) Tom Rishel describes a course where 5 teams simultaneously did some projects that had 5 development stages, each team working on a different project for each stage.