In my class, Introduction to Data Analytics, we use project-based learning to teach students fundamental skills needed to perform a data analysis and understand what a data analyst does – from grappling with data, and performing analysis, to communicating insights. At the heart of the weekly projects, lies practice in the “soft” (but oh-so-important) skills of being a team contributor. I believe in the value and necessity of group work and group learning, particularly in our new interdisciplinary major, but I am also well aware that many students, and sometimes faculty, dislike group work and the inevitable conflicts and frustrations that arise.
When I began planning for my course, I thought carefully about how I would motivate group work to my students, before beginning our first projects. Initially, my thought process was based mostly on explaining why group work is important, and on experiences I have had in participating in classroom group assignments.
- Battling common misconceptions – “You will not be a lone genius solving problems. Most data analysts [in any field] work in teams.”
- Practical career preparation – “Even if you are the only data analyst in your workplace, you will need to communicate with others, like the person who provided you with data, or your boss who only wants you to communicate the executive summary.”
- Encourage lateral learning – “Each group member has different strengths and perspectives. Use group work as a learning opportunity, to ask your peers to help teach you things you are struggling with, or to help explain a complicated idea to your peers. In the end, both the person who feels behind and the one who feels ahead gets a better learning opportunity for the knowledge to ‘stick’”.
- Personal anecdotes – “In my work as a data scientist, I’ve led teams of 20+ scientists in data collection, data analysis, and communicating final results. Group work is hard even when you like and know your other team members well, but you need to learn and practice how to do it now.”
- Accountability – “You will have the opportunity to rate yourself and your classmates participation, and cases of extreme ‘free riding’ will be handled on a case-by-case basis.”
- Teacher knows best – “This is the way the class projects work. You need to participate.”
So I included some aspect of all of these on my syllabus and in the initial explanation of the first two group projects. For the first project, I randomly assigned students into groups, explaining that in your future careers, you don’t always get to choose who you work with, and this was a good opportunity to get to know others in the class and to learn new perspectives and approaches. For the second project, I allowed students to work in groups of 2-3 of their own choosing. In both instances, I was surprised at how well most of the groups seemed to work, and the quality of the final assignment. But in both instances, even the case where students were able to work with their friends, there were several groups that did not go well.
I was worried that if students continued to have “bad” group work experiences, they would come to resent the group work and use their mental energy to stress about who they would be working with instead of on learning and practicing the material. I asked several faculty members from different universities about how they handled specific “bad” group situations, at what points they decided to intervene, and if they had strategies for minimizing “bad” groups. In my totally unofficial, biased sample survey, I heard several answers mostly clustered around some version of “suck it up, group work is required”, “your grade will be affected”, spending time to carefully engineer which students should work in which groups together, or always letting students choose to work with their friends. At this point, I realized that although I consider group work to be a core skill of being a data analyst (and really, it’s crucial for almost any career path), how can I expect them to embrace and work effectively as a team, and learn strategies to minimize failure and frustration, if I don’t teach them how to work as a team?
I started asking other colleagues of mine who work as scientists in large teams – when did you actually learn how to work and contribute as a team member in a data analysis? And mostly got answers like: “A few years into my graduate degree” or “After I started my postdoc” or “After I started my first job and learned what a cross-functional team was”… Clearly, there was a lot of trial, error, and frustration behind these stories, and not much directed advice or learning in how to be an effective team member.
So the next week, instead of dealing with a few students one-on-one that I thought had been “poor” group members, and instead of standing up in front of the class and once again explaining why I thought group work was important, I tried something different. We used the first five minutes of class to do an anonymous free-writing exercise, where I asked the students to reflect and think honestly about how they felt the past two projects had gone. I explained to them that I didn’t really know how each of their experiences was and that we needed to take some time to think and learn about strategies that make successful teams. I asked the students three questions:
In the two projects that we have done so far:
- What strategies have you found to be successful in your groups so far?
- What strategies did you find did not work in your groups so far?
- What do you think are a few “rules” for being a good group contributor?
At this point, I also made a conscious effort to only refer to “Team” projects as opposed to “Group” work. The connotation is different, as team explicitly signals cooperation, whereas a group membership could be completely passive, or even negative. I collected their anonymous answers and summarized them into several categories reflecting good strategies for teamwork, and things to avoid. The strategies the students wrote were then put into a document based on an example from Agile Teams in the business world, to create a Team Social Contract. The following week, we discussed the team social contract together and left it open or anonymous editing or comments for about 3 days. Then, everyone physically signed the contract. As a living document, we’ve been able to revisit the team social contract frequently, discuss teamwork as a learning objective, and use it as a starting point for broader conversations about careers, inclusion, and ethics in data analysis.
I feel really good about this approach so far, because I think that it allowed students to feel ownership and a sense of control over the team projects, which is often a key reason students dislike or resent group work. It also helped to have students approach group work from a more meta-cognitive perspective, rather than “we have to do this because the professor said so”, which again helps with buy-in, but also, I think, improves actual learning and retention of good teamwork strategies that they can use in the future. In my unofficial midterm survey, I actually had several students say that they really enjoy the teamwork, some of them even explicitly said they enjoyed being put into random teams! I won’t be able to say with certainty that it was successful until I get more data – finishing the class, further student surveys, and teaching with this strategy again. But it’s a more satisfying approach to me from a pedagogical perspective, from a workload perspective (I’ve mediated almost no conflicts since then), and from a student motivation and enthusiasm perspective.
By Sarah Supp, Assistant Professor of Data Analytics