Group work in Computer Science

Richard Mitchell and Pat Parslow, Department of Computer Science                                r.j.mitchell@reading.ac.uk     p.parslow@reading.ac.uk

The Department of Computer Science held a workshop recently to consider our use of Group Work. This was facilitated by Pete Inness, School Deputy DTL, and Pete Andrews (CQSD), who gave a useful overview of some of the challenges and potential benefits of group work, and included a talk from Annabel Avery (DAS) on issues associated with students with Special Needs.

Group work is an important aspect of the Computer Science degree, as generally in industry graduates work with others on various projects, and so it is important to be part of a team.

The aim of the workshop was to discuss issues and to highlight some areas of good practice which could be used elsewhere in the Department, School and further afield. This blog discusses our experiences in the Group work we set, in the Part 1 Software Engineering module, the Part 3 social, legal and ethical aspects of computer science module and the Part 3 Virtual Reality module.

Richard’s Virtual Reality Groupwork

The coursework for the Virtual Reality module is to produce a virtual world. Initially all students produce a simple world, using the Unity game engine, and this is worth a quarter of the coursework mark. The rest of the coursework is to produce a more complicated world, in a particular theme. As this generally requires the use of various software packages, and I feel it unreasonable for every student to learn each package, this is done in groups of typically around six people. This allows a specialist in say SketchUp to use it, a specialist in Blender to use it, someone good at scripts in Unity to do that, etc. Each group submits their finished product and each member submits a report on their individual contribution.

As it is a final year assignment, I am not interested in team dynamics, rather (as per a project in industry), I am interested in the final product. Hence the virtual world is visited, assessed against criteria and a mark generated. Everyone gets the same mark, unless it is clear they have done nothing (including not submitting an individual report).

Again, as it is in the final year, I find it easier for students to organise their own groups. Whilst this may go against some advice re special needs students, I can comment that I was advised this year by their (ever helpful) DAS supporter that a student was anxious about the group work until they knew they could choose their own group.

I do however ask that each group notifies me early on as to the members of their group and the tasks that have been allocated to each individual. This has worked, though on the odd occasion when some students are not in a group, I help them set one up. Annabel noted that this was good practice worth disseminating.

Also we feel it is good practice to include both individual and group assessed work.

Students have produced a variety of excellent worlds, showing great creativity and have feedback that they appreciate the opportunity provided. In this year’s ‘impossible world’ theme, highlights include a surreal Dali-Escher-Caroll-esque world, some haunted houses and a virtual brain. Last year’s ‘educational’ themed projects included various museums, including one where each member built a separate room illustrating say computers, Ancient Egypt and (of course) dinosaurs. In this last example, the students could support each other in the use of the different packages.

Pat’s Experiences

The focus on product is common across most Computer Science group work, although it is coupled with assessment for learning.  It is actually important to distinguish between group, and team, assignments.  One of the goals I have is to help students learn the benefits of working as a team rather than as a group – having a common drive, working interdependently, and producing products collectively rather than a set of individual outputs “smooshed” together to produce the course work submission.  Typically, students are resistant to this process!

In Software Engineering, a first year module for which Pat has recently taken on full responsibility, there are a mix of group and individual course work assessments.  Two of them are group work, with more of a focus on “team” in the second one.  Unlike other group assessments, the members of the groups are assigned by the lecturer.  For the first iteration, they are randomly assigned, taking note of any special circumstances such as social anxiety or other mitigating factors.  This assessment has a very low overall weighting (5% of the module) and is designed so that it allows individual efforts, which can then be combined, but which benefit from group discussion to provide different viewpoints.

The second set of teams are determined based on the marks the students have gained in their first individual course work.  For the first time this year, I assigned the teams based on ability bands, rather than deliberately building in diversity to the groups.  This was felt to be something of a risk, but the expectation was that the groups who had scored lower in their individual work would start to realise that they could not just rely on other team members to do the work for them – an issue students frequently comment on whether they select their own teams or have them chosen for them.  This assessment is designed to rely more heavily on team discussion, with less leeway for dividing the tasks up in a “one per student” manner, and requiring inputs from a range of skills to complete properly.

This aspect worked well – the groups consisting of those who scored less well in individual work improved their marks, and there were very few students who failed to contribute.  Less expected, although with hindsight, possibly obvious, was that the teams of high scoring individuals did less well, and feedback from a sample suggests that this was because they tended to be quite individualistic, and not particularly well adapted to working in teams with others with similar traits.  This was felt to be a useful lesson for both the students, and the instructor.

The marking scheme for the first year work is weighted towards them demonstrating that they have taken the correct approaches, rather than having any arbitrary view of “right or wrong” – the subject area and choice of assessment facilitates this.   Part of our knowledge domain requires attention to detail and following specifications, and these pieces of work also contain assessments of the students’ ability to do this – correctly interpreting the specification, following style rules, and producing a high quality piece of proof-read work can go a long way.

In the third year social, legal and ethical aspects of computer science module, the groups are devised to maximise diversity.  The finalists tend to prefer the idea of forming their own teams, but when asked, they almost all say that even when they have free choice, they regret choosing the teams they did after an assessment.  Typically, it appears that forming teams of, say, 7 students is a challenge for them as well – frequently Pat has to point out that 8 is greater than 7.  The teams are balanced by gender (as far as is possible in our subject area), domestic or overseas, with or without industrial experience, and with students with declared disabilities distributed as evenly as possible.  The rationale is that the subject matter itself benefits greatly from having as much diversity as possible.

The task, in this instance, is to watch and critically analyse a “near future science fiction film or TV series”, drawing out similarities with the real world and looking at how the ideas in the show relate to our existing ethical, legal and social realities.  The strong advice given it to discuss the topics together as a team, and it is clear from the resulting product (a report) which teams use this approach.

In addition to the actual group/team work, in each instance the students have an assessed reflective piece of work to complete, in which they are invited to reflect not only on their own learning approaches and how they might improve them, but also on how well the team worked.  They are given a basic structure for this reflection, and encouraged to expand on it using sources from literature.  Those that make the best use of the scaffolding and of the existing literature also produce the deepest insights.

Reflecting on these assessments this year, I am pleased with the variety of experience they give the students.  The problems set are themselves close to real life scenarios, or are real life activities, and have the benefit of not being “Googleable”, but judicious design also leaves them relatively easy to mark, which is a consideration with the size of the cohorts.   One key feature introduced this year has been the use of “CSGitLab”, a version control platform and collaboration tool, which has the benefit of being the type of tool used in industry, but also allowing individual contributions to be identified even in those instances where the team has done a good job of producing a single integrated product.  Although variations on marks within the team are kept to a minimum, there are cases where one member clearly has not made any significant contribution, and it is important to recognise this in the assignment of marks.

Discussion

One of the benefits of Group Work Pete Andrews highlighted was the development of workplace skills including critical reflection, creativity, communication, problem-solving, organisation and teamwork (see the UoR Graduate Attributes). He also quoted Barrows, 2000: “An education process that requires learners to go through the same activities… that are valued in the real world”.

The examples discussed here are very much consistent with these benefits.

We also wish to highlight our experiences re group selection, the importance of identifying as soon as possible any issues with groups, the inclusion of both group and individual work, to note the distinctions between group and team, and assessing the product and team working. We will explore more the use of collaborative tools in future years. As ever, we believe it important to manage expectations, making it clear why group work is used and the benefits. We much appreciate the support from the Petes, Annabel and our colleagues for the workshop and the discussions.

References

Barrows, H. (2000). Problem-based Learning applied to medical education. Southern Illinois University, School of Medicine.

https://www.reading.ac.uk/internal/curriculum-framework/cf-graduate-attributes.aspx

This entry was posted in Computer Science, Curriculum Framework, Student Group Work, Teaching & Learning and tagged , , , . Bookmark the permalink.