Is it possible to ensure division of labor on a group assignment?

Question

Let's say I've assigned my Intro to CS class their first group programming assignment. A common problem is that the most invested student in the group will end up doing the majority of the work. At grading time, there are techniques that can be used to determine how much work each individual did--I don't want to focus on that. Instead, I would like to hear if there are any ways to ensure that the group actually divides up tasks proportionately without planning their project for them.

Is this possible? If so, how? More importantly, is it possible to do this without external pressure? How can we give them the incentive and tools to really want to cooperate?

Assume that the class has been introduced to OOP and has completed a few assignments, but exposure to CS is minimal.

Bonus: Is it actually better for the students' education to ensure this or to leave them to their own devices?

Answer 1

Make each group member explicitly be 'responsible' for one aspect of the project.

Let's think about why group work is a useful tool in terms of teaching your students. I'd imagine one of the big reasons you would assign a group task is to prepare your students for a job, working with a team to build a product. In the workplace, you typically have a way of assigning individual roles and responsibilities; if you're building a website, you generally would have someone responsible for design, someone for the backend logic, etc.

You should do the same thing here. Specifically require that your students build a plan, with each member being given a role that they are individually responsible for, and before allowing them to proceed, make sure each role is relatively equal in scope. You wouldn't want Alice to have ten times the work of Bob in the plan—it won't give you the scope to analyse each bit of work individually.

Obviously, each piece of the project likely depends on another, so it's very difficult to isolate each person's contribution individually. That's why I'd suggest not weighting the group work too highly, because the difficulties of evaluating the outcome far outweigh the benefits of making the group work count for a high percentage of the grade.

Carnegie Mellon's Design & Teach a Course section has some useful tips:

In addition to evaluating the work of the group as a whole, ask individual group members to demonstrate their learning via quizzes, independent write-ups, weekly journal entries, etc. Not only does this help you monitor student learning, it helps to prevent the “free-rider” phenomenon. Students are considerably less likely to leave all the work to more responsible classmates if they know their individual performance will affect their grade.

To create individual accountability, some instructors combine a group project with an individual quiz on relevant material. Others base part of the total project grade on a group product (e.g., report, presentation, design, paper) and part on an individual submission.

You'll need to think about your aims. Do you want to test the group's ability to spot people not contributing as part of the teaching? If so, don't put in those safeguards, and see what happens. If you just want to test their CS knowledge, make sure that you can fairly evaluate individual contributions, as well as the overall result.

Answer 2

Break the project up into separate, independent components that must work together and assign each one to a different person or group. This simulates how software is written in the industry.

This could be one person doing a different layer of the stack (front end, middle tier, database), or it could be different stacks/services that must operate together (one to authenticate, one to place an order, one to fulfill an order, one to send a receipt, etc).

Using contract driven development, the project could start with a spec being defined for how the different parts of the system will operate with one another and then each developer or team would be responsible for their part and no other parts.

If you use version control such as git it is also a simple matter to see who checked in what code, and how often.

In my experience in over 25 years in the software industry, 80% of the work is usually done by 20% of the people, sometimes even more extreme (90/10 or 95/5). The best developers are not 10% or 20% more productive than the worst, but 10x or 20x. Too many people get good at asking other people to do their work for them rather than doing it themselves. I think it would be great to teach every student to pull their own weight.

Answer 3

Aurora's answer is excellent, but I do feel I have one thing to add that's very specific to CS: this is a wonderful opportunity to use (or abuse, depending on your perspective) version control.

There are a lot of great reasons to introduce your students to version control, most of which I will not mention because they not directly relevant to the OP's question. The one reason that is relevant: I've had students use GitHub, and as a result have been able to see exactly who was committing which bits of code and at what times. That solves your immediate problem of ensuring that everyone is contributing to the project, or at the very least, allowing you to identify those who didn't contribute their fair share/only made "easy" updates like code formatting or comment changes.

This also helped me to see who was having problems with the assignments in... not exactly real time, but definitely as the assignments were progressing, rather than after the due date (when it would have been too late to help) or 100% dependent on the students asking for help. I as a TA/recitation leader could then help people when things were more manageable and prevent problems from compounding or a chorus of last-day requests for emergency help and extensions from arising.

Now, I realize that this sounds more like "determine how much work each individual did" than "divides up tasks proportionately." However, experience has shown me that if you tell people about this system upfront, the students will in fact end up dividing the tasks up proportionately. Just having them know that they're being watched seems to be enough motivation to achieve your goal, in practice.

Answer 4

I have a very different perspective that the other suggestions made here. Others seem to say that a group assignment shouldn't really be about cooperation and working together, but about dividing it up - externally. I think that the concern is about easing the grading process, but I would rather be a teacher than a grader.

In the real world that students will later face, both in education and in the workplace, they will be asked to actually cooperate in the work, not just divide it up. When divided up and someone fails to fulfill his or her part, the project as a whole may fail even though most "did their part". This is unacceptable and will leave most of the "group's" members frustrated.

It is also easy to demand that everyone is individually responsible for everything, which sounds good, but is unrealistic. Often in such divide work situation, the other students don't realize, or have any reason to suspect, that they have additional, major, last minute tasks to do.

The first thing you need to remember is that students need to be taught the things you want them to learn when they don't already do it naturally. You need to use some class/lab time to actually demonstrate group work and work sharing. You also need to monitor it either directly or via some sort of feedback mechanism with counseling.

The next thing you need to realize is that in a group, not everyone needs to participate in the same way - coding, for example. Organization is important. Research may be important. Easing interpersonal conflicts may be extremely important.

Next it is necessary to know that not everyone participates the same amount in each small time period, but may do so over time. One of the big ideas in group work is pay it forward. Make a lot of contributions early on so that if you cannot do so later you have still done your share and others won't disparage your contributions.

And of course, not everyone participates equally over time, either, and it is difficult to make it so. Instead you can use some form of "safe" peer evaluation of the members of the group so that you get insight into who the main contributors are. But don't be naive in this either. If all of the questions on your peer evaluation form are about, say, coding, then you are devaluing other sorts of contributions. I prefer to ask students to name one (or a few) key contributors to the group and to say why they were chosen. I also ask each student to specify their own personal contribution. Someone who does all the work him/herself isn't a contributor.

Group work should be done by a group. Don't neglect the social aspect of it. Work within your class framework to bring people together so that they actually have positive feelings for one another.

In a classroom situation learning is the main goal, not the completed project. The project itself can fail if the learning is good. This is different from the real world, of course, but the classroom should be a safer place to make mistakes, provided that the important lessons are still learned.

Note also, especially for a programming course, that even if some student didn't do much of the coding, it is still possible to assure that each student understand the whole work, not just their part. This again, isn't "real world," but is necessary to the educational process. This assurance can be gained in interviews, presentations, or quizzes, for example. This is a variation on the "everyone is responsible" rule, in fact. Everyone is responsible for knowing.

---

Finally, let me note something from the real world. Many Agile Software Development groups have a rule that no code can be committed to the code base if it was written by an individual, rather than a pair. Some programming is done by individuals, but only for experimental purposes to test out an idea. If the idea proves fruitful, the experimenter works with a partner to create the committable code.

The reason for this important policy is that any team doing real work wants a large enough Bus Factor so that if one or a few key people leave they don't take all of the knowledge of the project with them. This actually applies also to student team projects as some students do, in fact, leave a course in the middle of a project. The others must be able to carry on.