Reading Time: 10 minutes

Hi. I’m Chelsea Troy. I’m a computer science educator at the University of Chicago. I’m writing about the techniques I use to teach my distributed course, Mobile Software Development. You can see all the posts in the “Designing a Course” series right here!

This post is the third in a three-part miniseries about group work.

1. What I use group work for in the first place
2. How I divide students into groups
3. How I plan group activities

Group work carries a risk of caucal collaborative degeneracy.

We talked about this risk some in the last post, because my strategy for dividing students into groups is designed to mitigate that risk. Here’s the summary:

1. People with high caucus scores tend to have an easy time talking in unstructured discussions, so they think those discussions work great. This tends to include people with decision-making power, which is why caucuses are so common even though they’re not nearly as productive as these people think they are.
2. People with low caucus scores tend to have a hard time contributing to unstructured discussions. They find those discussions stressful and unproductive.
3. Unstructured discussions are stellar ways to lose the contributions of participants with low caucus scores through caucal collaborative degeneracy: when people never receive the opportunity to share critical information or insights at their disposal because other people talked over them.

There are two flavors of caucal collaborative degeneracy:

1. People don’t get to share insights because they never get the chance to speak. This is usually the one that we think of: we imagine someone getting talked over, or hesitating just long enough for someone else to jump in.
2. People don’t get to share insights because others never get the chance to listen. This is the insidious one where the caucus subverts ideas even when the meeting looks like it went well. Why does this happen? Because in a caucus, you get the chance to speak by jumping in. Jumping in requires precise timing: your utterance must be the first utterance after someone finishes speaking without interrupting that speaker. This means that everybody who wants to talk must devote their attention to identifying the precise moment to jump in. As a result, they’re not able to actually listen to what the previous speaker was saying.

I specifically design my group activities to mitigate the risk of caucal collaborative degeneracy—and especially, to protect students’ opportunity to listen by reducing the scarcity of their opportunities to add their own thoughts.

In the previous post, we talked about two ways I do that:

1. I limit the groups to 4
2. I put students in groups with like caucus scores

So how do I do that with the activities themselves? I have three kinds of activities:

Type 1: Analytical Tasks

In these activities, students receive an artifact to support their critique or brainstorming, like a user experience diagram, a class model, or a pull request.

Here’s an example: I wanted to teach my students about accessibility. So I told them a story about an app that I worked on once upon a time: an app for scanning baggage, mail, pets, and hazardous materials into the holds of aircraft. The work is done outdoors, on tarmacs, in the blinding sunlight and the dead of night and through snow and sleet and driving rain. It is done in goggles, or sunglasses, and ear protectors, and thick leather gloves. It is done, chiefly, by men in their forties, fifties, and sixties—folks with disabilities like vision impairment, hearing impairment, and limited range of motion. And of course, it is done underneath the screaming engines of commercial aircraft. So, plenty of accessibility challenges here.

Each student group received their own Google slide containing a user experience diagram of the app, with several accessibility problems strategically thrown in. All of the students in the group could simultaneously edit the document to comment on the issues that they noticed, and what should be done instead. Here, you can see one of the student groups in action working on their slide:

Why a Google slide? Because it eliminates the turn-based nature of group contributions that we see in most discussions and board games. This way, no one has to wait on anybody else to be able to write things down.

This slide aids the conversation in two ways:

1. It creates a focal point. Students have something to look at and describe, which is an easier way to start a conversation than an abstract idea with no visual aids.
2. It eliminates the scarcity of opportunities to “talk.” Any student can add to this document at any time, anywhere, even if somebody else is talking. This video does not include the students’ conversation because I don’t have informed consent waivers for them, but the presence of a slide noticeably reduces stress on students in group conversation, especially among students who have the lowest or second lowest caucus score in their group. They speak more in this kind of activity than in a turn-based activity like a discussion.

Another benefit of a document like this is that I can gauge participation in real time. Are the cursors active, or are they stationary? Stationary cursors can give me an early signal that students are confused, or alert me if they’re done with the activity and would like to be taken out of group. I don’t have to guess how long to run activities for—in fact, I rarely have to ask. That’s nice because asking can make the students feel pressure to be finished, abandoning in the process the exact half-baked ideas that I want them to follow through on in group-based challenges.

Type 2: Creative or Sharing Tasks

These are cases where the students do not have an existing artifact to analyze. Instead, they receive a prompt and are encouraged to devise artifacts on their own.

For example, in one task I assign students before class to read some materials about engineering ethics and draft a code of ethics for themselves. Then, in their groups, they talk to each other about their ethical boundaries. I provide them with, again, a Google slide on which they can take notes. Here’s an example:

Then, we do some scenario training. I ask the students to consider what they would do to protect those boundaries at a job, or while interviewing, with a company that violated them:

I use these discussions to help students practice their consultative decision-making, especially with folks who they view as peers who might not agree with them.

Type 3: Group Programming

In software engineering, we spend the majority of our time reading, understanding, and modifying existing code rather than writing new code. To prepare my students for this, I write some software for them. Then I have them explore and modify the code. To guide this effort, I create an exploration packet with specific questions for them to answer and specific modifications for them to make. Some examples:

• Here are five exploration packets that each cover a tab in this iOS application. Here is what some of the slides from one of those guides look like:
• Here is an introductory exploration packet and a chart-specific exploration packet to help students learn about this Android application. Once again, here’s a look at some of the slides from the first guide:

For this activity, each group has their own, editable copy of the exploration packet. They can take notes on it and refer back to it as needed.

This activity does differ from the others in that usually, one student shares their screen with their code editor pulled up. So rather than everybody independently modifying the same code base, in this activity three of the students are following along and making suggestions to the one student who is sharing the screen, and whose code modifications represent the collective work of the group. (This is exactly why I keep my group activities in class and don’t grade them). Should a student really feel the need to explore on their own, the code repository is public and they can pull it down on their own machine.*

*I’ll also briefly mention that, in addition to group programming challenges, I do have students write code individually both inside and outside class. However, those activities look very different from this one and serve a different purpose. We’ll talk about that in another post.

Sometimes, I will split the groups of four into groups of two and have students modify an app in pairs. Here is an example of an activity that I assign to pairs:

For broad, exploratory tasks or ambitious modifications with a high (>30%) probability of failure, I assign it to the group of four. These activities involve more reading code relative to writing code, so students aren’t missing out on opportunities to do lots of typing. Additionally, a group of four raises the number of suggestions per group of how to proceed, which is important when the task is especially challenging or new to them.

The pairs setup is more realistic to a workplace and gives more people an opportunity to type, so it’s a better fit for extremely targeted, narrowly-scoped programming tasks where the students already have some experience and will be doing more typing code relative to reading code.

Once again, due to the fact that the modifications only exist in one person’s version of the app, I do not grade paired activities.

Conclusion

I do three types of group activities in my classes:

1. Analytical tasks
2. Creative or sharing tasks
3. Group programming

For each task, I provide environments for students to asynchronously share their thoughts. When students can submit their ideas asynchronously like this, they have an option for sharing besides “stop listening to the person currently talking in order to identify the right time to jump in.”

As with all of the class activities, before I create a group activity, I think hard about my goals for what the students will get out of the exercise and use that as my guiding light in designing it, optimizing for students who want to learn.

That wraps it up for this mini-series. You can see all my posts about teaching by visiting the teaching category right here. You’ll find pieces about designing a syllabus, choosing topics to cover in a session, and selecting session activities.

If you liked this piece, you might also like:

The ongoing Advanced Debugging with XCode and LLDB Series

The Leveling Up Series (a perpetual favorite for gearheads like yourself)

The Books Category, to which I’m slowly adding all the blog posts where I reflected on a book