Group Project Management in the Classroom

We’re in the back half of my data for the rest of us course right now. I’ve already written a bit about the beginning of the course and how it was framed around a kind of data pipeline that aimed to give students a baseline level of data literacy. My goal for the course was always that the second half would work through the pipeline again, building towards small group work as students created datasets around their own particular interests. These final products were largely based on the model of Responsible Datasets in Context and the Post45 Data Collective. I wanted my students to work together to gather data based on their interests and produce an essay that situates that data in the larger context from which it came, demonstrates what kinds of questions you can ask of it, and makes the processed data available for other people to use in a legible manner.

The plan was always there. First half of the course: me teaching. Second half: all hands-on working. The problem I ran into was that I had more students sign up for the course than I expected. I’m used to running group work for graduate students where the entire group is working on the same project, but the number of participants is quite small: typically four to six. I framed the course with that scale in mind, and I was not ready mentally for a course where I would have 15 to 25 students. That’s what happens when you’ve taught only off the books for years! When it came time to plan how the course would actually look on a day-to-day basis once we got to the group work phase, I wasn’t actually certain what to do. What would it even look like for 15 students to work on the same thing? If I broke them into groups, how would the course’s pipeline model impact the students’ experience? With a single group over the course of a semester or a year, students will typically fall into different roles. You might have one person serve as a developer, another as a project manager, still another as a designer. But I worried after a conversation with Mackenzie Brooks that roles delineated in this way would mean one person waiting around for weeks for a partner to finish before they could even start.

What I finally landed upon was a plan to break the class into small groups of four to five students. Rather than explicitly assign clear roles, I wanted each person to contribute to every stage of the project. That way, each person would be able to demonstrate facility with each stage of the data production process as opposed to explicit mastery of any one phase. For each week, students had two assignments: a group deliverable as well as an individual reflection. One week the groups produced their metadata schema. For another, they turned in their raw data. And as they moved through these milestones, students also shared back individual reflections where they described their individual contributions to the work.

Beyond the assignments, I also needed to develop a new way for managing class work time for multiple groups. In my library fellowships, it’s very common for us to pivot at a certain time to pure group work for a number of sessions. The students decide what we need to do on a day-to-day basis, and conversation is limited to setting an agenda and then executing that plan. We’ll typically have several weeks of the calendar that are empty. In trying to adapt this structure to the undergraduate context, I’ve implemented a series of strategies from agile project development I learned from Ronda Grizzle, our expert project management and software training specialist in the Scholars’ Lab. This framework provides both a structure for each class meeting as well as a tangible experience the students can take away. We’re building every class around a series of scrums and debriefs.

If you’re not familiar, the term scrum comes from rugby, and it refers to the moment when all the players lock arms over the ball, try to gain possession of it, and attempt to move it forward across the field. It also is a term from the agile development framework that typically refers to a moderated set of practices used to facilitate project updates and agenda setting. Typically, as I’ve seen them, a scrum is a daily practice with specific time constraints and particular questions meant to be answered. At the beginning of a meeting, each person will get one minute of time to answer three questions about their work. The practice allows you to get stuff on the table for your group without spending a lot of time falling into the weeds such that you preserve actual work time. This practice is especially helpful with humanities scholars, as they can easily talk about questions so long that you run out of time before ever working. The first time you scrum, it’s almost always the case that people will run out of time, but it teaches you to move very quickly through updates. You get a quick sense of what the next state of work will be as well as what needs larger discussion.

I settled upon a modified scrumming practice for my class that incorporated both individual and group scrums. We had the same setup every day:

• Start of class scrums (5-10 minutes):
  • Within small groups, 1 minute for each person to answer three questions:
    • What have I done?
    • What is next for me?
    • What do I need from somebody else?
  • As a class, 1 minute for a representative from each group to give a project update:
    • Where is your group at?
    • What problems are you running into?
• Bulk of class time (approximately 60 minutes)
  • Work time within groups
    • I float to answer questions and help troubleshoot
• End of session debrief (5 minutes)
  • As a class, 1 minute for a representative from each group to share:
    • What did you do?
    • What is next for your group?

I brought scrums into my class as a way to provide structure to the work. They offered a way to bring people into the room and establish a ritual to mark the beginning of class as serious work—not time that could be blown off. The practice also helped students determine how they would use their time with each other. But I also wanted to use a modified scrum process to make sure the groups knew what other groups were doing. What lessons were they learning? What problems were they were running into? In this way, hopefully, the back half of the course would come to be about more than just their own group’s work but also about the larger journey the class as a whole was taking through the material. The kinds of projects that groups are working on vary broadly: video games, food and recipes, museum collections, and macroeconomic data. The groups are all dealing with similar kinds of challenges, though, and scrums have offered a good way to update each other and share advice. The practice has worked well for my purposes, and I will use it to help facilitate group work in the future.