Groups and Group Work, Notes from the Collaborative Classroom pt 2

Groups and Group Work

Group work is difficult no matter the technology or students. On the first day of class, I spend the bulk of the time explaining how and why the class will operate collaboratively for the entire semester. Each semester, there is usually one or two students who decide to drop the class because of this. I freely admit to my classes that in high school, or as an undergraduate in college, I did not enjoy working in groups–mainly, because there was always at least one person who would not participate for one reason or another, thereby making the rest of the group do all the work. Or worse still, I sometimes ended up doing the entire assignment myself with everyone else receiving equal credit. There always seems to be students who, no matter what, won’t participate. And that is a problem with group work.


In an effort to minimize this tendency (lack of participation), I try to push the issue back onto the groups, giving them the authority to “vote a member off the island;” that is, deny a particular group member points on a project for which they did not actually do anything (or only minor things). And the groups’ decision is final; I cannot overrule them. However, before they enact such measures, I do have a few rules in place, such as notifying me about the problem well ahead of time, so that I can give them feedback on how they might resolve such issues. Groups have used this option only a couple of times—the students in question mostly did not object or appeal because they knew they had contributed little or nothing at all. In that case, the “big stick” of grading had very little effect. However, I have noticed that from their evaluations of each others’ group participation, like professors, students have a difficult time, even when upset about the lack of effort from some members, of penalizing a classmate. The typical reason was that they didn’t want to be the “bad guy.”


It may not be obvious, but assigning groups is not as simple as it sounds.

The first few times that I assigned group projects, I let the students decide among themselves in which groups they wanted to be, believing that by being democratic, the students would feel empowered and therefore would be more engaged. I was wrong. Although there were some people who did gain a measure of inspiration by being self-directed, most students’ selection was based on friendships, race, popularity, attractiveness, or just whoever hadn’t yet found a place within a group. This would result in some bonding but more often created a sense of exclusion among members–before projects even started.

To avoid this, I started assigning people to groups myself. At first, I tried the counting off or drawing names methods, but to do this strictly by hand was time-consuming, and really not as random as I would like (for example, seat placement and attendance issues would bias the randomness). So instead, I used Moodle’s Random function within group creation (you can create groups based on on the total number of groups desired or on the number of members desired per group). Since I was often still grading projects after assigning new projects, this meant that within Moodle, people were assigned to multiple groups which also meant I had to use different naming conventions to keep from confusing myself as well as my students. But Moodle’s automated group creation only allows for numeric or alphabetic naming conventions (“Group 01” or “Group A”)–which made it difficult to keep track of when we got beyond the first two projects. I could have recycled those groups by deleting them and then recreating them but I like having the history.

Here’s a snapshot of the number of groups listed towards the end of the semester:

Groupings Overview


The problem with Groups within Moodle is that it creates them at the class level rather than at the assignment level. It would be handy, if on the assignment creation page, there were an option to create groups on that level. This would alleviate the need to use different naming conventions; that is, I could just stick with “Group 01”, etc. But the different conventions proved an adequate workaround.

So instead of recycling (deleting and recreating) the group names, I began using Moodle’s random group creation as a starting point only, so as to get a rough draft assignment for everyone. I would then copy and paste those groups and members into a spreadsheet and then manually adjust the assignments. I then went back to Moodle to manually create the groups using such group naming conventions as animal names or comic book titles (Alpacas, The Defenders, etc.), making the assignments based on my spreadsheet. It took time to ensure that group members hadn’t previously worked together (though this was almost impossible by the last couple of projects). This mixed solution had the added benefit of helping me sometimes find “better” fits for some group members whom I thought would benefit more by working with other students in particular.

Overall, I thought working with new people mimicked how real world jobs work. We typically don’t get to choose who our team members are and so learning how to navigate such group politics and issues while working towards a common goal is invaluable. Also, it continually helped teach the valuing of assessing people’s skills and knowledge at the outset and applying that information to the project at hand. And perhaps more importantly in terms of college, it helped connect people who otherwise may have never had the opportunity of meeting one another. One of the most rewarding things about such a class is receiving an email from a former student who happens to mention still being in contact with former group-mates.


So what makes a good group size? I’ve tried from 2 to 6 members early on. 2 member groups are too small–if one person was sick or decided to drop the course or just plain wasn’t working, that meant that the other person had to bear the responsibility for the entire project alone. 5 and 6 member groups are too large–mainly from a logistic perspective; that is, although I made some class time available for the groups to work on their projects, the majority of the work was done outside the classroom; accomodating that many different class and work schedules can be very difficult. I found that 3-4 people sized groups is the sweet spot (though depending on the project, even 4 can be a little too much to divide the  responsibilities). This allowed groups to recover from for the absence of a member, added the brainstorming power of divergent perspectives, and perhaps more importantly, an provided the opportunity for an equitable division of labor.


As I mentioned, most group work was done outside of the classroom. To get groups to thinking about potential challenges, we discussed the pros and cons of face-to-face meetings as well as synchronous and asynchronous technological tools (email, texting, video conferencing, phone calls, etc). Some groups always met face-to-face (like at the library), and some groups tried using only email. The most seemingly productive groups tended to use a combination of face-to-face meetings and distance communication tools. These groups typically began with a face-t0-face meeting, brainstorming on a project goal and developing a temporary plan and schedule. They would use this plan to set up dates/times and methods of communication. I also I created Moodle forums for each group that were only visible to their members. However, almost no groups ever used them (and even then, only initially), though this did vary from semester to semester.


For assignments, I required that in addition to one hard-copy being turned in, each group member uploaded digital files to Moodle.  They had to turn in the same copy; I had each member turn in a separate copy for accounting reasons. Although Moodle lets you filter the class by groups on its grading page, I want to be sure I was working with the correct people–and, it also was another way to encourage member participation by making their accountability very visible (if they were not doing the work, it would be highly unlikely that the other members would share their files).

About those “Digital files”:  since Microsoft Office was freely available on campus computers in the library and various labs, and since I also have my own copy of that produce, I stipulated that the file formats had to be in one of the Office file formats (such as .docx) or .rtf (rich text format). But I did not want to limit students to a particular software package, so I also allowed for any program that could save or print to a .pdf file. And in the case where some projects were more of a physical nature (the Packaging project, for example), they could take digital pictures and upload those to Moodle. Typically, most projects were created digitally, but I also felt it was helpful to see hard copy manifestations of it (again, such as the Packaging Project).  This also meant that I did not teach any particular program, although I would demonstrate useful tips and tricks within Word or other tools. I posted links to different applications as I came across them on the web (such as I also encouraged students to share their discoveries with the class as well. One such application that a group used one semester was–a Photoshop-like web application. Although I did not teach any particular application, students were free to ask me for help and we would learn together. I enjoyed those moments because it demonstrated that you don’t have to be a “guru” to learn a new tool–just a willingness to play.

One issue where technology was a problem for the groups was with operating system/software compatibility. Usually, this was in the form of some members using Apple laptops while others used Windows. Most of the time, they could save to one another’s format (i.e. Office for Mac) but even then, there were minor changes in formatting that would occur. This was a problem usually for the presentation part of the project (I had a projector but no Mac adapter)–and those formatting issues could really hurt evaluations (so we had to be sure to acknowledge those issues during the presentations).

In the next post, I’ll discuss the evaluation (grading) and mechanics of the projects:  Pt 3.


Comments (1)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: