THE SORTING HAT: A METHOD FOR ASSIGNING STUDENTS INTO GROUPS

This paper depicts the method applied to sort 120 undergraduate students into articulated groups for the 4 Week Challenge (4WC) in Computing at the University of Central Lancashire. The 4WC is the first module on the Computing course that is run in full-time burst mode in the first four weeks of the semester, with the rest of the modules following on after the first module finishes. It is designed to take students through a challenging (yet highly scaffolded) project to show them where their course could take them.

For the 4WC, the new students needed to be put into teams of 6. There were three options available for how teams were created. Option one was to allow the students to pick their own teams. This was discounted as it went against the teaching team’s desire to help students make friends and form social groups. Groups of ‘left-overs’ were to be avoided. Option two was to select teams based on degree course. This seemed attractive, as it would help the course groups to bond and form a strong identity. It was also a seemingly straightforward task that required little time and effort on behalf of the teaching team. On the other hand, it wouldn’t help students who were unsure about the course they had chosen (another of the reasons for doing the 4WC) and might lead to teams focussing on one aspect of the challenge to the exclusion of all else – reinforcing the ‘everything but X is irrelevant’ attitude we were keen to dissipate. Option three was to select teams that were inter-disciplinary. This was ultimately the preferred option as it was thought that with a “balanced” team, each member would be able to contribute something of their specialism at different points during the challenge – increasing the likelihood of success.
It was decided that Belbin’s team roles could be used for inspiration on helping to sort students into different group functions. Based on the descriptions of each of Belbin’s team roles (excluding the Specialist role), a list of 12 multiple-choice questions was devised, where each possible response indicated a preference for one or more of the roles.
The questions and responses were arranged so that each team role appeared the same number of times (10) across the entire question set.

A thirteenth question was added, with a scale of responses to measure how comfortable and experienced the student was with programming. This was designed to replace the role of the Specialist. From the response to this question, those who indicated an existing aptitude were marked as such. Coincidentally, there was the same number of self-diagnosed ‘expert programmers’ as teams. Had there been too few ‘programmers’, the plan was to look at the next response down on the survey.
The team roles were then examined, and one person was added into each team who could take on a leadership role (where one didn’t already exist), regardless of which course they came from. Fortunately, there were just enough “leaders” to go around. There were very few co-ordinators (natural leaders), so other roles had to be looked at for leadership quality.

The students were formed into teams the next morning and the Belbin roles explained to the students, as was the method by which the teams had been chosen – both of which provoked serious interest. It was considered that there was an advantage in the teams believing that they had been genetically engineered for success. Indeed, there were surprisingly few instances of serious friction within any teams.