Michelle Trame
As we were gradually scaling from cohorts of 24 students to cohorts of 40 students, addressing the interpersonal conflicts in group project work grew from being a minor stressor on students to a major source of frustration and resentment.
We didn't collect data on rates of students crying in the hallways, but if we had, I'm sure it would have shown huge growth during this period.
At the same time what had been a back burner concern for staff grew to be an outsized strain on the time that technical staff had to spend mentoring students. While learning to manage conflict in groups is an important skill, the amount of conflict was distracting students from our primary purpose, learning to code.
We realized we needed to be collecting different data from students to better understand the causes of the problem.
We determined that we needed:
As we spoke with students, we came to realize that as much as they were stressed about their situation, the opaque process was responsible for the way that they were interpreting the cause of their stress. We believed that if we could open up the process and give students greater insight into our process they would be compelled to take ownership of the dynamics of their groups.
Previously, data about who had a low preference ranking was obscured because it was not fully actionable. We usually didn't know if low scores were attributable to interpersonal deficits, technical deficits or both. By collecting better data we were able to support struggling students better through developing specialized study plans for them or even having them work independently so that their full focus could be on technical growth, not project management or collaboration.
With our improved data, we also wanted to systematize the process and make it obvious that the outcome was a result of us trying to accomodate preferences across the cohort, rather than optimizing for some other outcomes.
We started by inviting the students into our process to see how we were currently working to assign project groups. We were transparent about the fact that we were actively iterating on the process and shared how we had already changed the way we were collecting data.
We announced a mini hackathon and invited students to help us write code to solve the problem. We gave them a quick briefing about why we were collecting preference data differently, the output that we wanted from their solution (maximized happiness for the whole cohort, not at the expense of any sacrificial groups), and gave them anonymized datasets to work with.
While forming ten perfectly cohesive four-person teams might not be feasible, we wanted to reframe the group-making process as a collaboration, not a edict. Inviting students into the problem solving also gave them an opportunity to empathize with how complex this seeming simple task actually is.
I also joined the hackathon as a participant. While I was not as savvy as many of them with complex coding solutions, I leveraged my familiarity with the problem to create a spreadsheet-based solution. Working with students enabled me to better understand their perspectives as I saw their prioritization and problem-solving strategies and they saw my investment in working on the problem alongside them.
To form highly compatible groups, I wrote a very lightweight algorithm that rank sorted students into teams by using our new preference data to create a scoring system and then matching low-scorers to high-scorers that had indicated preference for a low-scorer. This was a strategy I had used with some success in the past when making groups with the old data.
Although initially the focus had been on improving the outcome (good groups), through research and co-design we learned that the biggest pain point was the process.
Opening up our process to students had a huge impact. It changed the way they understood their responsibility toward managing team dynamics and ended the conspiratorial theorizing about the social engineering we might have been doing behind their backs.
The hackathon generated a python script that we mashed up with my simple algorithm to create a rough but workable and efficient process for forming project groups.
The success of this initiative at targeting resources to students who were struggling to work effectively in teams led us to expand our collection of interpersonal data into the first half of the course when students are pair programming.
Some support strategies initially developed for students that were struggling in the second half of the course were expanded into feedback and reflection processes that all students participated in during the first half of the course.
