Group Working

Jon Reades & Leah Lovett - j.reades@ucl.ac.uk

22nd October 2026

Why?

(Are you here?)

At the end of the day you could learn all this online, why are you here? We can teach you a lot more, but you will have to interact and apply yourself. We want to teach you the connection between the code you write and the thinking you do.

Why?

(Is it group work?)

The majority of work that you will do over the rest of your life is likely to be team- and project-based: you will be assigned to a small team to complete a project. This is true whether you are in academia or industry, government or NGO.

Forming project-based teams is what, for instance, management consultancies do. They have developed systems, like the McKinsey Way, to help both staff and clients understand what is expected of them depending on the role they occupy.

Learning how to quickly form an effective team is a critical employability skill, but nothing causes tension in an undergraduate or graduate module like group work. It’s widely seen that there is a big ‘free rider’ problem, though I’ve actually lost track of the number of times members of same group have approached me to complain about each other’s contributions.

In other words, everyone thinks they are working hard on the group project but, often, that almost no one else is!

I am drawing very heavily here on a talk that Leah will do later in the year to CE students as they prepare for their group projects. She does this much better than I can because she has direct experience of how this works. So any shortcomings in the rest of this talk are mine alone.

Many Models…

• Artist Collectives — shared responsibilities for ideas and outputs; a lot of freedom and fuzziness in roles, but propensity for struggles over direction and power.
• Theatre — every member has a specific role; there is freedom within the role and clear lines of responsibility for delivery, but can blow up spectacularly.
• Co-Creation — emphasis on participation and recognition of diverse strengths; problem- and communication-focused; lots of effort and uncertainty, but results can be much more meaningful and durable.
• …

The arts world is particularly innovative when it comes to project work because teams are always being formed and reformed around individual outputs (a play, an artistic collaboration, a theatre production)…

Fields such as consultancy and software development have their own norms, but they are for the most part less experimental in their structure.

However, the point is that there is no one-size-fits-all pattern for a successful piece of group work.

Challenges

• We make superficial assessments of the flaws/strengths of others.
• We make a range of assumptions about the motivations of others.
• We make a range of assumptions about the situations of others.
• We respond differently to stimuli and stresses.
• We have a hard time talking about any of this.

These are just some of the challenges to setting up your group.

In particular, when we meet a new group, it’s often easy to be impressed by someone who is self-confident and well-spoken: they must know what they’re doing! Group dynamics can be like a popularity contest in which the person who is easy-going or ‘fun’ is making a wonderful contribution, while the one who asks difficult questions is ‘not constructive’ and ‘not contributing’. And someone who is ‘quiet’ doesn’t seem to have much to say…

Talk about my experience as a school governor.

Identifying Your Strengths

Dominance

• Results-oriented
• Innovative
• Competitive
• Direct

Influence

• People-oriented
• Enthusiastic
• Optimistic
• Creative

Steadiness

• Sincere
• Dependable
• Patient
• Modest

Conscientiousness

• Accurate
• Cautious
• Precise
• Analytical

Here is one way of moving beyond the stereotype that the person doing the talking is also doing the thinking. The DISC model is apparently connected back to Wonder Woman by her creator W.M Marston. Like Wonder Woman, this is a model that reflects its cultural context: it was created for American teams and if you aren’t American then you might find that these four personality types don’t ‘fit’ very well. But it’s still a good place to start talking about preferences, behaviours, and the way they impact others.

Too Much of a Good Thing

Dominance

• Fails to involve others
• Impatient
• Offensive

Influence

• Too social
• Easily distracted
• Overly optimistic

Steadiness

• Indirect
• Avoids conflict
• Delays difficult decisions

Conscientiousness

• Perfectionist
• Avoids unsystematic people
• Delays decisions over risks

Anything that is a strength in one context can become a weakness in another.

For instance, a dominant personality might assume that the fact no one else is objecting means that there is support for their proposal; however, it could just be that the rest of the group wants to avoid conflict even though they think there are significant risks.

Or someone who is motivated by the social component might spend so long bringing people together to talk about directions (and constantly adding new ideas to the mix) that very little progress is made on the actual project!

Your Turn

With the person next to you (3 minutes):

1. Which of the four is closest to you?
2. What does too much of it look like when you’re under pressure?

Keep it to 3 minutes. The point isn’t the DISC labels: it’s practising saying this out loud to people you don’t know yet, which is the conversation every group needs to have and almost none do.

It also doubles as a chance to meet possible group-mates. Don’t ask for a plenary: just ask for a show of hands for each of the four, which usually shows the room isn’t all ‘Dominance’, whatever it sounds like.

Consequences¹

1. Source

Every Good Plan¹…

1. Source: Zentao

Nothing Ever Goes to Plan

From relational to practical…

• Agile¹: deliver something that works early, then improve it; respond to change.
• Scrum²: short stand-ups, sprints, reviews, and retrospectives.
• Kanban: sticky notes in columns (to do, doing, done).
• XP: one person codes while a partner checks and feeds back.

One challenge that teams face in the world of software is failure due to complexity and change.

You may have seen ‘Waterfall charts’ of the sort produced by project management software where one task cascades into the next until the project is delivered at the end. This is recipe for failure. The Mythical Man Month comprehensively debunked this approach in 1975.

The general conclusion was that “Adding more people to a project that is late makes it later.” The reason this happens is that you cannot break a complex task into discrete parts, send someone away to work on it in isolation, and then have them report back at the end with a finished product. I have seen this happen in previous years’ group work too: one person did a lit review while someone else was writing code but they didn’t line up at the end!

I saw this in graphic design too: a client writes a brief for exactly what they want. You deliver something exactly like what they asked for. And they say that’s not what they meant.

The Agile philosophy emerged in response to these kinds of failures, with the approach that the product should be finished as quickly as possible, but as provisionally as possible. So you always have a working application, even if it only does a fraction of what you intend for it to do in the long run.

This has been elevated by companies like Facebook to slogans along the lines of ‘Fail Fast’, but the point is to recognise as quickly as possible when something isn’t working or isn’t headed in the direction you planned.

For the group work at the heart of this module, the point of starting early and working iteratively is to help you develop competency in using the tools required to make your submission, to start you thinking along the lines that are required for the more complex questions, and to tease out points of failure in the group’s ability to work together long before you are under the tight deadline at the end of term!

1. Source: SimpleLearn

2. Source: Northeastern University

To Do: discuss how your team can work together effectively.¹

So you’ll want to revisit this lecture once the group assignments are finalised. But it seems sensible to talk about it now rather than wait until you’re already trying, and potentially failing, to work together.

1. Once you’ve formed your team, obvs!

In FSDS

• Groups of no more than five.
• Sign-up opens Monday 26 October and closes Monday 2 November.
• Not in a group by then? We’ll match you to a group with space by the practical on Thursday 5 November.
• Sequencing:
  • Reading Week: literature scan.
  • Week 6: questions about lit you found.
  • Weeks 7–9: draft answers + getting to know Quarto.
• Peer evaluation is due Tuesday, 15 December 2026, the day before the submission (Wednesday, 16 December 2026).
• Your GitHub commit history is our evidence of who did what.

Written so that anyone covering week 4 can answer questions.

Why groups at all: most work after the MSc is small-team and project-based, and forming an effective team quickly is a skill. The project is meant to feel like that: a team thrown together at short notice that has to work out how to work together and produce something they’re all confident in (see the Group Work assessment page).

Why sign-up opens on Monday, not today: so that students talk about being in a group (this deck, and the conversations it starts) before they rush into forming one. Many will ignore that, which is fine.

Matching: anyone not in a group when the form closes on 2 November is matched, by capacity, to a group with space before the Thursday practical (5 November).

Timeline: the literature scan can start over Reading Week. Don’t start on analysis until pandas in week 6. You can ‘play’ with Quarto from Week 6 or 7, but don’t start to use it intensively until week 8 (see the Group Work page).

Peer evaluation the day before: that’s deliberate. Everyone should have been contributing well before the final push, and it avoids the exam period. It’s done through IPAC on Moodle and uses the strengths/‘too much’/dysfunctions slides in this deck as its guidance.

GitHub: if a group can’t settle a dispute, we use the commit history to decide individual contributions. So everyone commits their own work, and a history where one person commits everything is no help to anyone.

Go Groups!

Group Signup Form

 

Opens Monday 26 October @ 11:00.

Additional Resources

• Bartlett Guide to Group Work

Thank You

References

Brooks, F. P. 1975. The Mythical Man-Month. Addison-Wesley.

Lencioni, Patrick M. 2002. The Five Dysfunctions of a Team: A Leadership Fable. John Wiley & Sons.