Abstract
Scrum is an increasingly important project management framework that has had limited study in technical communication (TC) and TC classrooms. While research has found student collaborations to be both frustrating and challenging, it has found Scrum to be a scaffolding framework that can improve student interactions and outcomes. Therefore, to determine whether Scrum affects the peer assessments of collaborative teams as well as project grades, this quasi-experimental classroom study compares the midproject and postproject peer assessments and grades of advanced TC students who used Scrum as a framework for collaboration against those students who did not use Scrum in their collaborations. The study found that students who used Scrum rated their team members significantly higher on some peer assessment measures and earned significantly higher grades than did those students who did not use Scrum. Additionally, students in the Scrum protocol reported satisfaction with their group experience broadly but did not report satisfaction with Scrum itself.
For decades, collaboration has been noted as a critical component of successful technical communication (TC) in the workplace (Boettger & Friess, 2016; Burnett, 1991; Burnett & Duin, 1993; Jones, 2005; Rainey et al., 2005; Renguette, 2016; Thompson, 2001). To try to prepare students for success in the workplace and smooth the rocky interactions that can sometimes occur in artificial settings, TC educators and researchers have explored the successes and struggles of collaboration in their classrooms (Barton & Heiman, 2012; Campbell & Lam, 2019; Kastman Breuch et al., 2001; Paretti et al., 2007; Scott, 1995). Among the many suggestions for improving these collaboration efforts has been to implement a project management process known as Scrum (Beale, 2016; Pope-Ruark, 2015).
Broadly speaking, Scrum is a project management “framework that helps people, teams, and organizations generate value through adaptative solutions for complex problems” (Schwaber & Sutherland, 2017, p. 2). More specifically, Scrum is an agile process that requires specific types of meetings (i.e., planning meetings, review meetings, retrospectives, and daily Scrums) that occur at specific junctures (i.e., first day of sprint, last day of sprint, daily) that are organized by people who have specific job roles (i.e., ScrumMaster, Product Owner, Team Member) and use a specific vocabulary (e.g., user story, definition of done, planning poker, burn down chart, velocity) to create ongoing incremental changes to product development. Scrum is typically used in software development and technological fields, so it has become increasingly important to technical communicators (Friess, 2018; Johnson, 1990; Johnson, 2014; Johnson, 2017a, 2017b; Kimball, 2015; Lanier, 2018; Whittemore, 2012).
While it has been posited that Scrum, with its highly structured process and emphasis on cooperation, could be an effective tool for improving collaborations in TC classrooms (Pope-Ruark, 2012, 2015; Pope-Ruark et al., 2011), few studies have attempted to ascertain what effect Scrum might have on these groups. Thus, I conducted a classroom-based, quasi-experimental study of students completing collaborative group work in advanced TC classes. But first, I will overview the Scrum process, review the relevant literature related to this topic, and outline my research questions and methods for exploring them. I discuss the results of this study here and provide conclusions and pathways for future research.
Overview of Scrum
Scrum, with its multidisciplinary teams, time-boxed sprints, structured meetings, assigned job roles, and specific vocabulary, is a complex and nuanced approach to project management that enables a distinct path for deriving solutions to complex and nuanced problems. While Scrum has its roots in software development, Scrum itself is not a piece of technology. Scrum is a process and, at its core, is defined by particular personnel doing particular tasks through particular meetings. Scrum takes place in successive short segments known as sprints, which typically last 2 to 5 weeks (Rubin, 2012, p. 20). Table 1 describes the job titles, types of Scrum meetings, and tasks that take place during a typical sprint.
Descriptions of Job Titles and Types of Scrum Meetings and Tasks in a Typical Sprint.
In practice, Scrum is a structured accountability process that helps team members efficiently and successfully meet their sprint goals. While Scrum might seem prescriptive, several studies suggest that organizations lean into the inherent flexibility of the process in order to establish a particular process that is effective for their needs (Eloranta et al., 2016; Friess, 2018; Hassani-Alaoui et al., 2020). Organizations adopt Scrum because Scrum-enabled teams have been found to better meet the product needs and time demands of their clients (Schwaber & Sutherland, 2017). Further, it has been found to internally produce effective collaborations and maintain team member morale (Gupta & Manikreddy, 2015; Overhage et al., 2011; Sutherland et al., 2014). With these benefits, Scrum is no longer limited to software development and is now used in countless industries (Mariyappan et al., 2018; Oprins et al., 2019; State of Scrum 2017–2018, 2017). It is increasingly a framework with which technical communicators need at least passing familiarity (Friess, 2018, 2019; Johnson, 2014; Johnson, 2017a, 2017b).
Thus, Scrum is a complex and detailed framework; I encourage those who want to know more about its nuances to reference the many outstanding books and guides available (Rubin, 2012; Schwaber & Sutherland, 2017; Sutherland et al., 2007).
Literature Review
This literature review describes previous research on challenges within student collaboration and on Scrum in TC classrooms.
Challenges Within Student Collaboration
The ability to collaborate in the workplace is a well-noted desirable skill for technical communicators (Boettger & Friess, 2016; Kimball, 2015; Rainey et al., 2005). Yet many (if not most) students continue to disfavor group work (Allan, 2016; Burke, 2011; Isaac, 2012; Stamp et al., 2020). One of the most prominent reasons why students dislike group work has to do with the perception that some students will do “little work [but] benefit from the efforts of highly motivated students,” a phenomenon that has been described as social loafing, slacking, or free riding (LaBeouf et al., 2016, p. 18). The notion of social loafing has been well researched and found to be a challenge for both student group work and workplace collaborations (Karau & Williams, 1993; Meyer et al., 2016; Mihelič & Culiberg, 2019; Popov et al., 2012; Rajaguru et al., 2020). Studies exploring how to mitigate social loafing have found that public posting of team member performance (Lount & Wilk, 2014), academic alignment (Pieterse & Thompson, 2010), communication quality (Lam, 2015), team size (Aggarwal & O’Brien, 2008; Maiden & Perry, 2011; Pieterse & Thompson, 2010), and project scope (Aggarwal & O’Brien, 2008) affect the perceptions of social loafing by teammates.
A second noted, but less studied, struggle for students in group work occurs when a “domineering” or “bossy” team member refuses to delegate tasks and takes full control of the product creation and submission (An et al., 2008; Galbraith & Webb, 2013). A domineering student is one who has “a clear and inflexible plan for how the task should be completed” and “behaves as if believing that the only way to ensure a quality output is to dictate all aspects of the task or to complete it him or herself” (Peterson & Peterson, 2011, p. 2). One study of MBA students found that a third of teams who had to deal with conflict on teams dealt with domineering group members (Behfar et al., 2008, p. 179). Further, a survey of design students found that 11% of students routinely dealt with dominating team members in their group sessions (Tucker & Abbasi, 2016, p. 8).
Other challenges to group work involve instructor involvement (Lane, 2008), cultural expectations (Mittelmeier et al., 2018; Popov et al., 2012), communication modality (Lam, 2013; Ruppel et al., 2013), and intragroup dynamics (Haller et al., 2000; Theobald et al., 2017). While it is not always clear why particular groups struggle, it is clear that group work is often a challenging, stressful endeavor for students. Therefore, the introduction of a new project management framework is worth investigating in order to identify how to improve students’ group-work experiences.
Scrum in Classrooms
Given Scrum's prominence in industries that employ technical communicators, a project using a Scrum framework for group collaboration could position students well for the collaborative processes they may encounter in their career (Friess, 2018, 2019; Johnson, 2014; Johnson, 2017a, 2017b; Kimball, 2015). But relatively little research has explored the effects of a Scrum framework on the projects of TC students.
Pope-Ruark (2012) found that 93% of students who used Scrum in a variety of TC and writing classes found Scrum to be valuable although some noted that it was “difficult” and “time consuming.” Overall, however, students found that Scrum enabled them to “negotiate through open communication in project work,” “understand group dynamics,” and remain accountable to each other (p. 167). A recent study by Friess and Lam (2021), which used a portion of the data set used for this study, found that groups who used Scrum employed more empathetic markers in their interactions with their teammates than did groups who did not use Scrum.
Studies outside of TC provide further information about Scrum's pedagogical potential. Linden (2018) found that students in an introductory programming class preferred Scrum approaches to group work over non-Scrum approaches but found no evidence that a Scrum approach improved a student's grade in the course. Mahnic (2011) found that students taking a capstone course in their final year of a software engineering program reported positive reactions to Scrum in terms of usefulness and relevance to their future careers. And in another study of a capstone software engineering course, Paasivaara et al. (2017) found no difference between high- and low-performing teams in how often they used Scrum hallmarks, but in their follow-up interviews with students, they found that students on high-performing teams tended to use Scrum in more traditional formats. Finally, in a study of chemistry instructors, Vogelzang et al. (2019) found that instructors who implemented Scrum in their courses enabled improved scaffolding and the mastery of learning concepts.
Ultimately, while there are countless explanations on how to implement Scrum into a variety of classrooms (e.g., Baham, 2019; Duvall et al., 2018; May et al., 2019; Paul & Behjat, 2019; Pope-Ruark, 2015; Valle & O’Mara, 2015), few studies have explored whether implementing Scrum improves students’ group-work experiences or their grades. This study explores whether Scrum's nuanced approach provides collaborative improvements to make instructor investment in the project management approach a worthy endeavor. Scrum's framework would seem to make group work happen in a structured and scaffolded manner. This study explores those possibilities.
Research Questions and Method
Given the ongoing struggles within student collaboration and the prominence of Scrum across many industries, I asked the following questions: Research Question 1: Does Scrum affect the peer assessments reported by student members of TC collaborative teams?
Research Question 2: What do students who use Scrum think about the framework?
Research Question 3: Does the use of Scrum or students’ attitudes toward Scrum affect their final project grades?
To learn how implementing Scrum processes might affect the outcomes and assessments of student group work, I conducted a quasi-experimental, classroom-based study at a public university with over 35,000 students in the southern United States. The university's Institutional Review Board approved the study (IRB#18-661).
I selected for this study four sections of identical advanced TC classes. The sections met face-to-face twice a week. Two instructors who both had extensive experience teaching this particular course each taught two sections. This class was open to any student who had previously passed an introductory TC course. A principal investigator (PI) or coprincipal investigator (co-PI) who was not the instructor of the course explained the study to students in each section and obtained their consent. For the group project, the instructors used the same assignments, project requirements, evaluative rubrics, and timeline to eliminate as much variability as possible in the quasi-experimental study. The 7-week group project was divided into two phases: Phase 1, in which students developed and launched a survey using Qualtrics, and Phase 2, in which students analyzed the data they collected and wrote a report about their findings.
Students in all sections completed a Team-Maker survey by CATME.org, a survey that aims to form better functioning teams by assessing students’ demographics, college experiences, schedules, teamwork preferences, and perceived skills (Loughry et al., 2014). Students in all sections were put into groups based on the Team-Maker suggestions.
One of the two classes taught by each instructor was randomly selected to receive the Scrum intervention; the other two classes acted as the control group. All classes received a 30-minute lecture and then participated in a 30-minute exercise illustrating the best practices of team communication. All teams developed a team charter that established their communicative practices for the project. While teams were asked to use the Slack workplace communication program as their group's communication hub, students were encouraged to use SMS, email, voice, and other media as needed. Both instructors were members of the Slack channels and monitored student engagement in these channels. Students in the Scrum intervention were then given a 30-minute lecture followed by a 30-minute activity that presented how to implement a lightweight version of Scrum in a group project (The Impact of Agile, 2017). Each Scrum team was given time to hold a planning meeting in which they selected a ScrumMaster, developed user stories and definitions of done, and set up a Scrum board on Slack. The No Scrum teams were given time to “get started” but were not told explicitly what to do during that time.
Additionally, Scrum teams held daily stand-ups virtually and maintained their Scrum board on Slack. Daily stand-ups are opportunities for team members to report (a) what they have done since the previous stand-up, (b) what they will do before the next stand-up, and (c) the obstacles they face as they work, which are the standard reported aspects of a daily stand-up (Rubin, 2012, p. 264). The daily stand-ups were held asynchronously on Slack; the ScrumMaster determined the deadline for the daily stand-up. Traditionally, face-to-face, synchronous stand-ups have been the norm, yet stand-ups in distributed groups held asynchronously have become more common in recent years, with COVID-19 making this alternate stand-up delivery more prevalent (Ageling, 2020; Ahmad et al., 2018; Brower, 2020; Ganis et al., 2009; Khmelevsky et al., 2017; Pries-Heje & Pries-Heje, 2011).
Since the project lacked true clients, the demo consisted of students giving brief presentations on their results and definitions of done to the other students in the class. At the end of the Phase 1, the teams also held a retrospective meeting, in which they explored what worked well and what did not work well from a collaborative standpoint (Rubin, 2012, p. 377). The instructor served as the Product Owner, who is responsible for presenting the tasks for each sprint and making decisions that enable the team to create functional, high-quality products (Rubin, 2012, p. 172).
Data Collection
The data for this study was collected at two points in the project. First, at the halfway point of the project, after students had constructed and launched a Qualtrics survey, students in all sections completed a peer assessment on each of their teammates and one on themselves (see Appendix A). This 5-minute per teammate survey was based on Brooks and Ammons's (2003) peer assessment instrument, with some modifications based on Ohland et al. (2012). Students were given a link to a survey and were to complete the peer assessments outside of class. Using the Piped Text option in Qualtrics, the specific teammate's name appeared, making the assessment more tightly tied to each particular teammate. For example, when the student indicated that they were evaluating “Alice,” the student saw “Alice met deadlines.” They were then given the opportunity to elaborate on any aspects of the project or their teammate via a Text Entry response.
Second, after completing the project, analyzing the data collected from their survey, and writing a report on the findings, students in all sections again evaluated their teammates using the identical instrument they used at the halfway point (see Appendix A). Again, students were given a link to a survey and completed the peer assessments outside of class.
Students in the Scrum sections were also asked up to 10 Scrum-specific questions as part of a larger survey (see Appendix B). Students who were not in the Scrum sections were asked to complete a similar large survey that omitted the questions about Scrum. They were given class time in a computer lab to complete this survey. Their instructor was not present when they completed the survey. The PI or co-PI stayed in the room to handle any potential technological issues. Students were seated away from their teammates so that it was difficult, though not impossible, to view the screens of other students. Students who completed this final survey in its entirety had a 1:10 chance to win a gift card.
Finally, I collected the students’ grades for Phase 2 of the project. To ensure grading consistency, prior to grading the students’ submissions, the two instructors conducted norming sessions using work submitted in previous semesters. During the norming sessions, each instructor independently evaluated a sample submission, and the norming session concluded when a sample was graded within 3 points (out of a possible 100) by both instructors. I also organized a specialized grade-book function in the learning management system that allowed all students in both sections of the instructors’ courses to be listed in one place, the students’ names to be anonymized during grading, and the order of grading to be randomized to reduce observer biases.
Descriptive Statistics of the Sample
In the four sections of the upper division undergraduate course, 80 students elected to participate in the study. While a handful of these students were technical communication (TC) majors (n = 6), a plurality of them were computer science (n = 24), biology (n = 21), and English (n = 12) majors, as well as students from various other majors (n = 17). The median age of the students was 21.4 years, and 2.5% of the students were freshman and non–degree seeking students, 15.6% were sophomores, 32.5% were juniors, and 49.4% were seniors. Of the 80 students, 77 completed the final survey in its entirety. The No Scrum classes consisted of 31 students organized into 8 teams. The classes with the Scrum intervention consisted of 49 students organized into 13 teams. Each team consisted of 3 or 4 members.
Results
Here, I report my findings regarding the three research questions.
Research Question 1: Does Scrum Affect the Peer Assessments Reported by Student Members of TC Collaborative Teams?
For this question, I compared the results of the peer assessments completed by students who used Scrum to those of students who did not use Scrum at the end of Phases 1 and 2 of the project. I used an independent samples t-test to determine whether the difference in peer assessments between the groups was statistically significant. The findings show a significant difference (t = -1.68, p = .047) in whether the students found teammates to be an asset during the Phase 2 assessment (see Table 2). There was also a significant difference in whether students would want to work with their teammate again at the end of both Phase 1 (t = 2.0, p = .024) and Phase 2 (t = 5.06, p < .001) of the project.
A Comparison of t and p Values of the Peer Evaluation Statements at the End of Phase 1 and Phase 2 of the Project.
Research Question 2: What Do Students Who Use Scrum Think About the Framework?
To learn more about students’ perceptions of Scrum, I looked at students’ responses in the end-of-project survey. Prior to taking the advanced TC class, only 10% of the students in the Scrum sections had heard of Scrum, and only one student had ever used Scrum in a class.
Students reported what aspect of the Scrum framework was the most helpful and the least helpful. The results show that the daily stand-up was identified as both the most helpful and the least helpful aspect of Scrum (see Table 3).
Most Helpful and Least Helpful Aspects of Scrum as Reported by Students who Used Scrum in Their Projects.
The students were also given an opportunity to answer two questions via Text Entry. The first question asked, “What else would you like us to know about your experience with Scrum?” Of the 37 responses given, 26 included some kind of negative statement in regard to Scrum. These responses reflected the following sentiments:
There was “too much busy work.” There were “too many hoops to jump thru for no reason.” Daily stand-ups were a “waste of everyone's time.” Scrum was a “total pain,” and it “didn't accomplish anything.”
One student even responded, “Im [sic] gonna tell it to you straight, I hated everything about Scrum.”
The second Text Entry question asked, “Is there anything else you would like us to know about your experiences with group work this semester?” Of the 30 responses given to this question, 21 noted positive experiences with the group work for the semester, such as these:
“I absolutely LOVED working on this team.” “This was one of the best group experiences I have had in both my college life and my professional career.” “The group work I’ve done in this class has been far better than that of any group work I’ve ever done in any other class.” “This was the most effective group project I’ve worked on in my education.”
Of the 21 responses that indicated a positive group-work experience for the semester, 18 were given by students who also gave a negative statement about the implementation of Scrum.
Research Question 3: Does the Use of Scrum or Students’ Attitudes Toward Scrum Affect Their Project Grades?
First, I evaluated whether the use of Scrum affected students’ project grades. I used an independent samples t-test to determine whether the difference in the Phase 2 grades between the groups was statistically significant. I found that the difference between the final grades of the students who used Scrum (M = 91.4) and those who did not use Scrum (M = 87.1) was statistically significant (t = -3.7, p < .001).
I also evaluated whether any significant difference existed between grades earned by the students in the Scrum intervention who rated the daily stand-up as the most helpful aspect of Scrum versus those earned by students who rated the daily stand-up as the least helpful aspect of Scrum. I found that the difference in the final grades of the students who considered the daily stand-up to be the most helpful aspect of Scrum (M = 92.7) and those of the students who found the daily stand-up to be the least helpful aspect of Scrum (M = 88.9) was statistically significant (t = -2.6, p < .01).
Discussion
This quasi-experimental, classroom-based study has yielded several useful findings, especially in light of the relative lack of empirical assessments of Scrum use in collaborative teams of TC students. I address three of those findings here.
Scrum Positively Affected Some Peer-Assessment Measures and Student Grades
Research Question 1 asked whether the introduction of Scrum might affect peer assessments. This study found that introducing Scrum did not affect student perceptions of the specific behaviors of their teammates, such as their ability to meet deadlines and respond to criticism. But a statistically significant difference did exist when students evaluated their teammates holistically. In both phases of the project, there was a statistically significant difference between the Scrum teams and the No Scrum teams in the students’ willingness to work with a team member again, with students on a Scrum team being more inclined to work with their team members again than were students on a No Scrum team.
Along the same lines, there was a statistically significant difference between the Scrum students’ and the No Scrum students’ assessments of team members being assets to the team during Phase 2 of the project, with students on a Scrum team being more inclined to view team members as assets to the team than were students on a No Scrum team. There was no significant difference between the same measure during Phase 1 of the project. Perhaps Phase 1 had too short of a timeframe (3 weeks) for students to fully internalize and appreciate the Scrum framework. Pope-Ruark (2015) “caution[ed] against using the Scrum framework on very short projects” and recommended saving Scrum for “complex collaborative projects that allow teams to dig into the strategies more authentically” (p. 129). This finding supports this notion that Scrum more fully affects collaborative processes after a longer period of investment.
Additionally, this finding seems to support the notion that the Scrum protocol better enables students to view their team members as humans with challenges, struggles, and emotions. Prior research has noted that Scrum seems to promote empathetic markers in the language exchanges of Scrum-based students (Friess & Lam, 2021), but additional research is needed to know more about what aspects of Scrum, such as the daily stand-up or the retrospective meeting, lend themselves to this increased empathetic understanding of team members.
Research Question 3 asked whether the use of Scrum would affect students’ grades, and this study found that students who used Scrum earned grades that were significantly higher than those of students who did not use Scrum. This finding suggests that the implementation of Scrum not only improves the interactions of students on Scrum teams but also scaffolds students in a way that enables them to produce higher quality work than that of students who are not on Scrum teams. This result supports prior research findings regarding Scrum's scaffolding abilities in classrooms (Vogelzang et al., 2019). Additional research is needed to determine if certain aspects of Scrum could independently improve scaffolding and outcomes.
Ultimately, this research suggests that the inclusion of Scrum within the collaborative teams of these advanced TC courses positively affected both the students’ grades and their perceptions of their team members.
Students Did Not Like Scrum, but They Liked This Group Work
While Scrum improved students’ grades and perceptions of their team members, the students were not universally in favor of Scrum. A majority of students who used Scrum indicated that they would not use it for a future project unless it was required. Also, a majority of students who completed a free-response question about their experiences with Scrum during the semester indicated that they had a negative experience with Scrum, and many of these responses echoed the student sentiments reported by Pope-Ruark (2012). These results seem fairly straightforward: The students did not like Scrum.
But these negative reactions are made murkier by the replies the Scrum students gave to a free-response question asking about their experiences with group work for the semester. A majority of students indicated that they had a positive group-work experience during the semester, and some students gave superlatives indicating that this group experience was among the best that they had ever participated in. Further, 86% of the students who indicated that they had a positive overall group-work experience also indicated that they had a negative experience using Scrum.
These seemingly paradoxical results are difficult to reconcile, opening them up to a variety of interpretations. But it is easy to understand why Scrum would not necessarily be overwhelmingly popular. Scrum can be tedious. While lightweight Scrum is relatively pared down, it was likely a far more structured group-work process than what these students had encountered in previous group-work experiences. Just as I dislike exercise but enjoy getting stronger, these students might dislike Scrum but like their improved group-work experience. Perhaps when introducing Scrum, instructors need to spend more time previewing both the difficulties and the benefits that students might encounter with the framework. Such forecasting may make students more receptive to Scrum. Overall, more research is needed to ascertain why students report disliking Scrum and to see if other factors may have contributed to Scrum students having enjoyable group-work experiences while also having unenjoyable experiences using Scrum.
Students Had Divergent Perspectives on the Daily Stand-Up
Perhaps part of the reason that students disliked Scrum was tied to the daily stand-up. Students had highly divergent opinions of the daily stand-up, which was held every day (including on days when class was not held) asynchronously on Slack and typically took students 2 to 3 minutes to complete. Only 45% of the students indicated that the daily stand-up was the most helpful part of Scrum. When asked why it was the most helpful part of Scrum, students provided responses such as these:
“It helped us stay on top of things and ultimately became a thing we did unconsciously, regardless of it being a requirement. Good communication helped us work quickly and effectively, particularly when working outside of class.” “It was easier and faster to keep each group member accountable for what they needed to complete. It was good to know if some people were going to be sick or were unable to work on the project until the weekend. It kept everyone up-to-date.” “Because we could see what our teammates were doing even if it wasn't related to the class, and we can understand what they’re dealing with.” “At first, I didn't like it because it was just another thing to do, but then I realized that this kept me accountable and on track.” “I mean it doesn't matter what they did on there [sic] time off as long as we get it done together in class. We made sure that we worked hard in class so that we didnt [sic] have to spend to [sic] much time outside of class.” “We did not need to talk daily about this project.” “It was a pain and it didnt [sic] accomplish anything.” “I don't want busywork and that's all this was. The assignment was cool and I just wanted to do the work the way that my team wanted to not the way you told us to.”
Nearly as many students (42.5%) indicated that the daily stand-up was the least helpful part of Scrum. When asked why the daily stand-up was the least helpful part of Scrum, students gave responses such as these:
Some students who found the daily stand-up to be the most helpful part of Scrum also noted their struggles with the stand-up (e.g., “at first I didn't like it,” “it took a lot of work”). But students who found the most helpful part of Scrum to be the daily stand-up ultimately had higher project grades than did those students who found the daily stand-up to be the least helpful part of Scrum. This study, then, suggests that more research on how to improve students’ attitudes toward the daily stand-up is warranted. Perhaps simply previewing the potential tediousness of the stand-ups while also presenting their potential upsides would encourage students to put aside their objections to daily virtual contributions at the outset of the project and enable a pathway toward improved outcomes.
Limitations, Future Research, and Conclusions
The results of this study suggest that a lightweight version of Scrum is a valid framework to implement in TC group-work projects. To successfully deploy this Scrum framework, instructors should
overview the best communicative practices for group work overview the lightweight Scrum framework with the elements outlined in Table 1 make explicit that lightweight Scrum, and especially the daily stand-ups, can be a pain, but it can improve outcomes remind students that Scrum is a common framework and that anyone going into a software, technology, business, or TC field will benefit from at least a passing knowledge of Scrum
This study is limited by four factors. First, it explored the effects of Scrum on students at one university. Future research could extend this project to see if the results are similar in various populations. Second, due to its quasi-experimental nature, the study cannot definitively exclude other factors (e.g., time of day the course was taught, environmental elements within the classroom, and the team members’ course load–work load) from affecting the outcomes. Again, expanding the study to additional sites could address this limitation. Third, although students communicated in asynchronous virtual environments, they also met in face-to-face classes. In light of COVID-19, additional research is needed to see how Scrum works with student groups who never have the opportunity to meet face-to-face. And fourth, this study only explored the effects of one framework, the lightweight version of Scrum. Future research could see how alternatives to this approach, such as full Scrum, Kanban, and Scrumban, might affect student interactions and outcomes.
Ultimately, this study has empirically shown that Scrum can be a valuable framework in student group work, as evidenced by the higher teammate assessments and project grades of students in the Scrum intervention as compared to students who are not in the Scrum intervention. But this study has also revealed that Scrum may need to be tweaked to make the Scrum experience more palatable to students. Thus, additional empirical assessments of Scrum in student group work are warranted to locate further pathways toward improved group-work experiences.
Footnotes
Acknowledgments
I am grateful for the assistance of Meesha Thomas and Chris Lam in the data collection of this study.
Declaration of Conflicting Interests
The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author received no financial support for the research, authorship, and/or publication of this article
Appendix A Teammate and Self-Assessment Instruments
Teammate Assessment
Strongly Agree
Agree
Neither Agree nor Disagree
Disagree
Strongly Disagree
[My teammate] met deadlines.
[My teammate] responded well to criticism.
[My teammate] produced high-quality work.
[My teammate] was an asset to the team.
I would want to work on a team with [my teammate] again.
Self-Assessment
Strongly Agree
Agree
Neither Agree nor Disagree
Disagree
Strongly Disagree
I met deadlines.
I responded well to criticism.
I produced high quality work.
I was an asset to the team.
I am proud of the final product our group produced.