Image by @anniespratt, Unsplash
Team-based learning asks both teachers and learners to believe that practice with concepts (rather than memorization of or telling about them) in messy, uncertain application exercises is the key to actually being able to use such concepts in real life. (Haidet, Kubitz, and McCormack 2014)
Team-based learning (TBL) can boost subject understanding by focusing on practice and creating an environment for peer knowledge sharing, while simultaneously having teams reflect on their process and performance (Vance 2021; Haidet, Kubitz, and McCormack 2014; Johnson 1991). We are currently organising and delivering a team-based learning module for data science postgraduates, so it is useful to think about how to optimise the environment and constraints to help teams perform well and to help individuals grow both hard and soft skills.
This is a short review of some experience, evidence and open questions around performance and learning design for team-based learning. As much of the available evidence comes from TBL in software development or other kinds of technology project, it will be worth drawing out any differences specific to data science projects.
Team Formation and Composition
Team diversity has been studied in a number of ways and often positively correlated with team outcome, creativity, and satisfaction. Usher and Barak (2020) distinguish task diversity (team member discipline and expertise) from bio-geographic diversity (mother tongue, gender and age), and showed that for face-to-face environments at least, both higher task and bio-geographic diversity (largely mother tongue) led to more creative solutions in an engineering task.
For team creation, there is conflicting evidence on the benefits of self-selection versus tutor allocation - suggesting that either route can have positive outcomes (Gopinath and Saleem 2020). We have used both, but believe that self-selection is important for highly motivated students to find each other and perform to their full potential.
In general with other types of group working, for TBL team sizes of between 2 and 5 are commonly used, with larger teams increasing risk of freeloading and poor team cohesion (Gopinath and Saleem 2020) and smaller teams maintaining individual accountability (Johnson 1991) though less able to deliver a substantial project. We currently prefer teams of 4 as enough to get a significant project done without risking imbalance.
Project Identification
One common approach to TBL is to have all teams work on the same project, so that solutions may be compared (Haidet, Kubitz, and McCormack 2014). For data science, for instance, Vance et al (2021) use a series of team-based application exercises where all teams work on the same series of tasks, with a review period at the end of the timebox where they can review each others’ solutions.
This approach seems limiting for data science projects - the scoping, problem identification, design and data acquisition stages would all be more limited if teams were provided with a more rigidly specified task. The selection and specification of a project that can be delivered within a short period (one or two semesters) seems like a realistic challenge. With this flexibility, teams are also free to choose an application domain of interest.
Interdependence and Cooperation
Developing strong cooperation is clearly essential in this kind of learning setting. For teams to be fully cooperative they need these five features identified by Johnson:
- Positive interdependence
- Members to promote one anothers’ learning and success
- Members to hold each other accountable
- Members to use appropriate small group and interpersonal skills
- A built-in process to periodically review how effectively they are working together
In a time-constrained learning environment, teams need to develop ways of working that can accelerate artifact production. In a study of hackathon performance, Lifshitz-assaf and colleagues (2020) found that those teams with a tangible product at the end on the competition did not collaborate fully, but came together when specific adjustments and changes of direction were needed. Importantly, the visibility of each others’ workflow was essential in providing opportunities for these interactions:
adaptive coordination involved swift sensing and adjusting, quick interactions for providing sporadic updates and creating quick feedback loops that gradually increased alignment over time. - Lifshitz-assaf, Lebovitz, and Zalmanson (2020)
These findings are interesting in suggesting that forms of rigid, over-engineered cooperation can be an impediment to successful completion.
Project Management
With agile approaches, tools and methods now pervasive, it seems sensible to recommend that learning teams adopt agile principles during the development of their projects. Agile also dovetails well with the cooperative principles above. Data science projects do differ a little in that they may involve substantial preparatory work — data acquisition, data cleaning, modelling etc — that can’t really be product tested. But we can introduce end-product (e.g. UI) design early on. And much of the overarching agile philosophy as well as many of the practices certainly do apply.
Hulshult and Krehbiel (2019) report using 8 practices during and IT course, most of which apply to data science: Team charters, Standups, Kanban Boards, Story cards, MosCoW, Timeboxing, Showcases, and Retrospectives, all of which helped with team accountability and continuous monitoring and delivery.
Fernandes et al (2021) used scrum methods in a TBL module in engineering. Tutors acted as Product Owners and students with previous experience took the role of Scrum Masters. They reported that the method reduced team conflict and improved team and project management.
Assessment
We want team marks to reflect not only the end product, but also the way the team functioned and the extent of learning that occurred. To maintain accountability and fairness, it is often necessary to have both team and member assessment elements. Vance et al (2021), for instance, used a grading breakdown of 40% team performance, 40% individual performance and 20 “Peer evaluation and team maintenance”, the latter based on 3 opportunities in the semester, where students rated their peers out of 10 and provided qualitative comments alongside.
We are curently working with a similar breakdown of approximately 30% team process, 30% team outcome, 40% individual contribution. We are using peer evaluation and feedback, but not as part of the summative assessment scoring.
Conclusion
TBL seems to have a real place in data science education, providing as it does a stepping stone into real-world work environments. As some of our students have noted, it provides them the opportunity to unify and apply skills gained across different areas of study.
For data science, more research can help us to understand how to create the conditions for solid personal and team learning. The evidence above, and our experience to date, indicate that TBL and agile principles have aspects in common and can fit together effectively.