Incentivizing healthy group dynamics in classes (2012)(blogs.oregonstate.edu)
blogs.oregonstate.edu
Incentivizing healthy group dynamics in classes (2012)
http://blogs.oregonstate.edu/glencora/2012/12/04/incentivizing-healthy-group-dynamics-in-classes/
16 comments
In college, the best time I had on group projects was when I could pick my group. I was in groups of people with a similar skill level and interest in the topic, and we worked together seamlessly. I learned the most because other group members had ideas that I didn't think of. Since we were all really interested in the subject, we would also go above and beyond the assignment guidelines and turn in work that had challenged us even more.
The worst groups had extreme skill and interest differences. It always took 10x the time to drag the lower-skill person through their part of the project than it took to do the work myself. In the beginning I would spend a lot of time helping the person, but in later projects I would just lay out some interfaces early on, leave the person to figure it out themselves, and reserve enough time before the due date for me to just do their part myself if necessary. I can't imagine that this was fun for them. I think they would have gotten much more out of being on a team with someone at a similar level of skill. They would have had someone to talk problems through with, and would have had some camaraderie around struggling their way through the course. I was never on a team with someone much-much better than me, but I don't think I would have found that fun either.
In the best teams, you are slightly better at some things and slightly worse at others. When these differences become too great, working in a group is no longer helpful. I also feel like the dynamics and incentives in a job differ from the dynamics and incentives of a college group project that you don't really learn any useful social skills either.
The worst groups had extreme skill and interest differences. It always took 10x the time to drag the lower-skill person through their part of the project than it took to do the work myself. In the beginning I would spend a lot of time helping the person, but in later projects I would just lay out some interfaces early on, leave the person to figure it out themselves, and reserve enough time before the due date for me to just do their part myself if necessary. I can't imagine that this was fun for them. I think they would have gotten much more out of being on a team with someone at a similar level of skill. They would have had someone to talk problems through with, and would have had some camaraderie around struggling their way through the course. I was never on a team with someone much-much better than me, but I don't think I would have found that fun either.
In the best teams, you are slightly better at some things and slightly worse at others. When these differences become too great, working in a group is no longer helpful. I also feel like the dynamics and incentives in a job differ from the dynamics and incentives of a college group project that you don't really learn any useful social skills either.
I got burned doing 80-90% of the four-person semester-long software engineering lab.
I think it boils down very simply: the intra-group dynamics can't be opaque to whatever mechanism regulates the group. Hence making the group dynamics unknown to the instructor but not providing group members some other mechanism does not work.
Letting students punish/fire each other would just open up lots of other ways of things being unfair that would need their own mitigations. (In the real world this takes the form, very imperfectly, of a boss' incentive alignment and employee exit.)
I think the only reasonable answer is to not make individual contribution opaque to the instructor. Git/etc (for code and documentation) may be your friend here.
I think it boils down very simply: the intra-group dynamics can't be opaque to whatever mechanism regulates the group. Hence making the group dynamics unknown to the instructor but not providing group members some other mechanism does not work.
Letting students punish/fire each other would just open up lots of other ways of things being unfair that would need their own mitigations. (In the real world this takes the form, very imperfectly, of a boss' incentive alignment and employee exit.)
I think the only reasonable answer is to not make individual contribution opaque to the instructor. Git/etc (for code and documentation) may be your friend here.
Based on my college experience, it feels like “divide a class into groups that won’t murder each other” might be the great unsolved problem of our era.
My time in college also taught me a lot on groups. It soon became clear that an A team is very volatile because of egos and motivators are hardly the same. Every time we had groups bigger than 2-3, there was drama and/or resentment. I wish I knew more about people and project management at that time but times were also different..
I'm currently studying a CS(-ish) bachelors degree (and I'm currently procrastinating on a group assignment) so I have some experience with this.
Our uni gives us quite a lot of group assignments. The university-wide solution to this problem is to include a mandatory section in each group assignment, where we are supposed describe the specific contributions of individual groupmembers. This is a neat idea in theory, but it doesn't really work. Because we've almost always lied in this section.
You'd think that the more productive student would want to claim their own work, but more often we've prioritized 'sticking together', and aimed for distributing the described workload as evenly as possible. The idea being that the highest grade wouldn't be higher anyway (the report doesn't magically become better), but it might give the grader incentive to give some group members a lower grade.
It's not a zero-sum game. So we might as well sacrifice some pride to keep the group dynamic strong, and to help out weaker students (regardless of whether it's a work-ethic or an intelligence problem).
That being said - we might be an unusual social group. We generally prioritize technical (and social) abilities way higher than grades (which aren't so important here anyway). We've all stuck together since the start of our studies, despite being a very wide span of academic ability - so theres a lot of teaching and learning within the group.
A survey of our uni recently ranked our line of study #1 for "How motivating the social life is to performing academically". So it seems that our approach is working.
EDIT: I should mention that it's by no means the case that the actual workloads are distributed evenly. They are of course very skewed, and often a single group member will do almost no work.
Our uni gives us quite a lot of group assignments. The university-wide solution to this problem is to include a mandatory section in each group assignment, where we are supposed describe the specific contributions of individual groupmembers. This is a neat idea in theory, but it doesn't really work. Because we've almost always lied in this section.
You'd think that the more productive student would want to claim their own work, but more often we've prioritized 'sticking together', and aimed for distributing the described workload as evenly as possible. The idea being that the highest grade wouldn't be higher anyway (the report doesn't magically become better), but it might give the grader incentive to give some group members a lower grade.
It's not a zero-sum game. So we might as well sacrifice some pride to keep the group dynamic strong, and to help out weaker students (regardless of whether it's a work-ethic or an intelligence problem).
That being said - we might be an unusual social group. We generally prioritize technical (and social) abilities way higher than grades (which aren't so important here anyway). We've all stuck together since the start of our studies, despite being a very wide span of academic ability - so theres a lot of teaching and learning within the group.
A survey of our uni recently ranked our line of study #1 for "How motivating the social life is to performing academically". So it seems that our approach is working.
EDIT: I should mention that it's by no means the case that the actual workloads are distributed evenly. They are of course very skewed, and often a single group member will do almost no work.
You know that the higher achieving person could have told the truth, but didn't. This might change the situation from a smug feeling of having cheated the hard worker into a feeling of gratitude that they protected you. The power they wield is the difference between a philantrope and a sucker.
Just a thought.
Just a thought.
I like the point where the slackers would be forced to work with other slackers because for some of them, this is the only way to motivate them to build a sense of responsibility and urgency.
If they can't, then they fail and this will be a learning experience that would be very valuable for them.
If they can't, then they fail and this will be a learning experience that would be very valuable for them.
Back when I was in college in a database class, they professor asked us to divide into groups of 2-3. Many people didn't know each other so it was hit or miss. Inevitably one person in the group carried the weight of projects but everyone in the team got the same score. At the finals there was a twist because the exam questions were derived from details in the the team projects. If you actually worked on the project, that was easy to recall. Everyone else had a pretty hard time.
I like this article from Barbara Oakley:
Group Hitchhikers & couch Potatoes - https://www.cs.cornell.edu/courses/cs3110/2018fa/teams/hitch...
Group Hitchhikers & couch Potatoes - https://www.cs.cornell.edu/courses/cs3110/2018fa/teams/hitch...
I never understood why some colleges set group work, it seems like such an obviously terrible way to evaluate people. Good students will end up doing all the work, and if you try to change that, the good students will lie about it to appease you.
You can just set individual projects, it's not that hard.
You can just set individual projects, it's not that hard.
Putting students into groups reduces the marking load by the number of students in the group. I teach a course with >100 students - grading 25 reports is manageable, where as grading 100 is not.
There are some good pedagogic reasons for group work too - most people do end up working with others, so getting some practice makes sense.
There are some good pedagogic reasons for group work too - most people do end up working with others, so getting some practice makes sense.
I have never in my career been set into a group of people with semi-random distributions of skill in the relevant task, totally unknown to me at the outset, with no management structure either in place, or available, where we are all nominally peers responsible for equal portions of the task, with the knowledge that the group has no future and its only deliverable (ultimately) is a grade.
The resulting experiences were not all that helpful.
I've worked in almost every conceivable structure since then; with people more skilled than me in some things, less skilled in some things, above me in the org chart, below me, way off to the side, in other companies entirely, in small groups, in large groups, startups, established corporations, heterogeneous skills and fairly homogeneous (as much so as it ever gets, of course). In all those situations, I would have to say for all their pathologies and successes, none of them have ever even slightly resembled my college experience with "group work".
In engineering we are not in the habit of taking 4 people fresh from a job interview, putting them all in a cubicle, providing them no distinction amoungst themselves in responsibility, and handing them a collective task. Any manager worth their salt would take one look at such a "management" structure and instantly tell you how there's virtually no chance of success there. It is so obviously flawed that I really don't see the point of doing it for the purpose of "working in groups". I don't know if "working in groups" is even possible to really test for in the college situation, but it certainly is going to take more work than drawing names from a hat and calling it a day.
I can't think of a way to avoid the fact that there's no way to resolve conflicts because the situation is just too darned symmetric. I don't even mean acrimonious conflicts necessarily, but any difference of opinion no matter how emotional or not. It's not even about simple "authority"; in a real work environment, someone may be the one who is going to own the support, or has years of experience with the relevant systems, or may be junior in other ways but has a ton of experience in this particular thing... in the real world there's almost always some way to resolve these things long before it gets to any sort of real conflict. These artificial groups don't have anything, though. They're set up to explode in exactly the way that so many of us, including me, experienced.
The only symmetry-breaker is "who cares most about the grade" and the totally rational game-theoretic solution is "let them do the work then". What else is there in the general case?
The resulting experiences were not all that helpful.
I've worked in almost every conceivable structure since then; with people more skilled than me in some things, less skilled in some things, above me in the org chart, below me, way off to the side, in other companies entirely, in small groups, in large groups, startups, established corporations, heterogeneous skills and fairly homogeneous (as much so as it ever gets, of course). In all those situations, I would have to say for all their pathologies and successes, none of them have ever even slightly resembled my college experience with "group work".
In engineering we are not in the habit of taking 4 people fresh from a job interview, putting them all in a cubicle, providing them no distinction amoungst themselves in responsibility, and handing them a collective task. Any manager worth their salt would take one look at such a "management" structure and instantly tell you how there's virtually no chance of success there. It is so obviously flawed that I really don't see the point of doing it for the purpose of "working in groups". I don't know if "working in groups" is even possible to really test for in the college situation, but it certainly is going to take more work than drawing names from a hat and calling it a day.
I can't think of a way to avoid the fact that there's no way to resolve conflicts because the situation is just too darned symmetric. I don't even mean acrimonious conflicts necessarily, but any difference of opinion no matter how emotional or not. It's not even about simple "authority"; in a real work environment, someone may be the one who is going to own the support, or has years of experience with the relevant systems, or may be junior in other ways but has a ton of experience in this particular thing... in the real world there's almost always some way to resolve these things long before it gets to any sort of real conflict. These artificial groups don't have anything, though. They're set up to explode in exactly the way that so many of us, including me, experienced.
The only symmetry-breaker is "who cares most about the grade" and the totally rational game-theoretic solution is "let them do the work then". What else is there in the general case?
It's almost like working with other people is important, and the ability to do so is probably the strongest indicator of future success.
That doesn't mean the way universities are doing it is good or productive, but the solution is to fix the way universities are doing it, not to abandon the need to figure out how to work with other people.
That doesn't mean the way universities are doing it is good or productive, but the solution is to fix the way universities are doing it, not to abandon the need to figure out how to work with other people.
Are you evaluating people or are you evaluating people's ability to work in groups?
Very rarely/almost never in a career in software will you be allowed to go off and do "your own thing", and if that opportunity arises, decline strongly. Don't be "the guy in the room".
https://blog.codinghorror.com/the-ten-commandments-of-egoles...
Very rarely/almost never in a career in software will you be allowed to go off and do "your own thing", and if that opportunity arises, decline strongly. Don't be "the guy in the room".
https://blog.codinghorror.com/the-ten-commandments-of-egoles...
The Software/Data Carpentries focus intensely on these matters, and their founder Greg Wilson continues to work on them:
https://carpentries.org
http://third-bit.com
https://carpentries.org
http://third-bit.com
I spoke to someone who's been doing group work for a while and she gave the following more useful advice: if you have a class with say 10% women, pick the groups yourself as instructor, never let the students do it all on their own. You want to avoid both "the women's group" (they all self-sort into one group) and "the one woman in the group, who is instantly elected group secretary".
I'd be interested to hear people's perspectives on this.
Regarding the "slackers" issue, there's a whole "methodology" called Team-Based Learning (https://cft.vanderbilt.edu/guides-sub-pages/team-based-learn...) that has thoughts on how to address this. In their opinion, as far as I understand it, you make mixed-ability groups but you also test people individually. One way is to give all group members an individual multiple-choice test on the pre-reading that you set, at the start of the session, and then collect the results and have a look through them while the groups work on their first task.