18 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO.

1, FEBRUARY 2022

Improving Teamwork in Agile Software

Engineering Education: The
ASEST+ Framework
Daymy Tamayo Avila , Wim Van Petegem , Member, IEEE, and Monique Snoeck , Member, IEEE

Abstract—Contribution: This article presents agile software framework were discussed in [2]. ASEST aims to develop
engineers stick together (ASEST+), an improved version of and enhance the cohesion of agile teams to improve team
a framework called ASEST that aims to develop team cohesion, learning and performance. Team cohesion is related to the
leading to better team learning and software engineering student
teams. team’s social attachment and its connection to the project
Background: Effective teamwork is crucial for agile soft- itself, both at the individual and team levels [3]. Team learn-
ware development’s success and is, therefore, a key topic of ing is “activities carried out by team members through which
current software engineering education. In the previous work, a team obtains and processes data allowing it to adapt and
a preliminary proposal for ASEST+ was presented. Here, an improve” [4], while team performance is the “degree to which
improved version, more suitable for agile practice education and
considering cohesion antecedents, is described. the team satisfies client needs and expectations” [4]. This
Intended Outcome: A teaching-learning framework to support framework’s fundamentals were established by identifying
teamwork in agile software education. teamwork trends in software engineering education (SEE),
Application Design: ASEST+ is built around Scrum teams for example, collaborative learning, games, and gamification,
and combines learning strategies to train students in collabo- among others [2]. The first version of ASEST (hereafter,
rative and technical agile practices. ASEST+ establishes policies
for role allocation and team rule agreements to regulate com- referred to as ASEST0) was developed following an input-
munication and address conflict management agile practices. mediator-outcome (IMO) research model [5] adapted to SEE.
ASEST+ addresses personality traits, conflict resolution, and This model is widely used to study the factors affecting team-
task interdependence as the antecedents identified as the most work effectiveness [5]: the inputs are antecedents enabling
important. and constraining team member interactions. The mediators
Findings: A quasiexperiment showed that the use of ASEST+
significantly increases the students’ positive perceptions on team are emergent states influencing input–output relationships and
cohesion, team performance, and team learning compared with the outputs of the team activity’s results and byproducts.
the control group. Guided by this model, ASEST0 was established. In ASEST0,
Index Terms—Agile software development (ASD), software team rules are the input, improved by self and peer assess-
engineering education (SEE), team-based learning, team cohe- ments of team member contributions. Team cohesion is the
sion, team development, team dynamics, team learning, team mediator, and team learning and performance are the out-
performance, teamwork training. puts. Establishing and agreeing upon team rules was found in
a metaanalysis among the most important antecedents for well-
functioning student teams in higher education [6]. ASEST0,
I. I NTRODUCTION however, did not include the antecedents of team cohesion.
HE EDUCATION of software engineers to effectively
T operate in agile teams is extremely important given
the popularity of agile methods in the software industry [1].
The core of ASEST0 is establishing agreed-upon rules
related to communication and conflict resolution to regulate
team behavior. ASEST0 was tested using two studies [7] [2].
Agile software development (ASD) bases its success on self- The work in [7] reports on the results of a pilot study of
managed teams able to prioritize and quickly respond to ASEST0 involving three teams of undergraduate students with
changes and satisfy customers and users through early and the ultimate goal of observing ASEST0 with teams perform-
continuous quality software delivery. The construction and val- ing in a company setting. The study showed the levels of team
idation of the agile software engineers stick together (ASEST) cohesion, team learning, and team performance increased after
the intervention. The work in [2] reported on a study at the
Manuscript received June 6, 2020; revised February 8, 2021, April 19, 2021,
and May 20, 2021; accepted May 24, 2021. Date of publication June 9, 2021; graduate level of a group of students applying ASEST0. It
date of current version February 3, 2022. (Corresponding author: Daymy indicated that team cohesion, team performance, and team
Tamayo Avila.) learning significantly increased compared with the students’
Daymy Tamayo Avila is with the Informatics Engineering Department,
University of Holguin, 80 100 Holguín, Cuba (e-mail: [email protected]). perceptions in a group that did not receive this intervention.
Wim Van Petegem is with the Department of Electrical Engineering (ESAT), Despite their limitations, these studies showed ASEST0 to be
KU Leuven, 3000 Leuven, Belgium. effective. However, they also contributed to identifying diffi-
Monique Snoeck is with the Research Center for Information Systems
Engineering (LIRIS), KU Leuven, 3000 Leuven, Belgium. culties with the approach. The research in this article reports
Digital Object Identifier 10.1109/TE.2021.3084095 on an improved version of the ASEST0 framework: ASEST+.
0018-9359 
c 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 19

The ASEST+ framework addresses the previously identified

difficulties and the lack of cohesion antecedents.
The remainder of this article is structured as follows.
Section II briefly describes the ASEST0 framework and
explains the identified difficulties. Section III discusses the
methodology followed in this work. Sections IV and V report
on the studies conducted to identify improvements. Section VI
describes how these studies’ findings were incorporated into
ASEST+. Section VII reports on a new quasiexperiment per-
formed to validate ASEST+. Section VIII discusses some
limitations of this research. Finally, Section IV concludes this
article and points to future work. Fig. 1. Research process.

II. ASEST0 F RAMEWORK of participants was conducted. As detailed in [2], participants

The ASEST0 framework combines team-based learning, expressed appreciation for ASEST0 but also pointed to some
project-problem-based learning, and role-playing game learn- areas that required improvement. The students’ most important
ing strategies in three phases and eight steps (a more detailed requests concerned the need for more guidance in reaching
description of ASEST0 can be found in [2]). Its components and tracking the rules agreements and having the rules be
and activities are also included in Appendix A of this arti- more focused on project tasks. Indeed, despite the use of team
cle, i.e., all items NOT underlined. The first phase aims to rules agreements that supported self-organization (an impor-
establish a learning environment based on agile teamwork and tant characteristic of agile teams [12]), the rules agreements
project-problem resolution. Teams are formed, and capstone in ASEST0 focused on teamwork rather than agile practices.
projects are assigned. The students identify by themselves Students recognized that even though not all members engaged
which roles they want to assume, and they self-coordinate with the agreements from the beginning, after evaluation of
task assignments. The students diagnose their teamwork skills team members’ contributions, teammates compromised and
(step 2) with the team knowledge test (TKT) questionnaire [8]. participated more. However, the assessment was considered
Next, training (step 3) based on a role-playing game and by at least one student to be at times unfair, and, further,
focused on communication and conflict resolution aims to participants proposed evaluating contributions several times to
improve their teamwork skills. Conflicting situations are sim- overcome this sort of criticism. ASEST+ aims to solve these
ulated, and the students are asked to solve them cooperatively difficulties, as will be described in the following sections.
by playing different software engineering roles in the team.
Belbin’s team roles [9] are used as well. III. M ETHODOLOGY
The core of the framework is the second phase, i.e., the
The methodology followed in this work is presented in
implementation phase. After evaluation of team functioning
Table I and Fig. 1. Table I summarizes the research ques-
(step 4) via the team process check (TPC) questionnaire [10],
tions, design, and techniques used in this work. Fig. 1 shows
an agreement on team rules that support communication and
the research process.
conflict management (step 5) attempts to further improve
The identification of improvements for ASEST+ proceeded
the team’s collaboration. The team functioning diagnosis
in two directions. The first stream of improvements aims to
and the individual diagnoses (step 2) and lessons learned
solve the difficulties identified from the studies [2], [7] and
from the teamwork training (step 3) assist students in writ-
make ASEST+ more suitable for agile practice education. In
ing the agreements. Step 6 aims at the establishment of these
doing so, ASEST0’s learning strategies were further evaluated
agreements.
via a literature review. The IMO model guides the second
The third phase focuses on adjusting the agreement. A self
stream with the aim of identifying antecedents not yet con-
and peer evaluation of team member contributions via the
sidered in ASEST0. Two literature reviews and a correlational
comprehensive assessment of team member effectiveness
study were conducted. ASEST+ was then examined by means
(CATME-B) questionnaire [11] (step 7) serves as feedback for
of a new quasiexperiment.
updating the agreements (step 8). This evaluation on mem-
ber contributions aims to make students aware of the team’s
successes or failures with regard to collaboration and avoid IV. AGILE L EARNING S TRATEGIES
conflicts that can arise from social loafing, that is, team mem- This section identifies approaches regarding agile teamwork
bers not carrying their weight in the work effort. According in SEE that enhance ASEST+ learning strategies, offering
to high, medium, and low levels of team performance behav- improvement over the strategies of ASEST0 (summarized in
iors, team member contributions are evaluated in five areas, as Table II).
proposed by [11]. The original literature review reported in [2] has been
In order to get a better understanding of the perceptions expanded and focused on Scrum. The original review showed
of the students who participated in the studies that were con- Scrum to be the most widespread methodology used to teach
ducted to test ASEST0 [2], [7], a survey with a random sample ASD, concurring with the review in [22]. An industrial report

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
20 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO. 1, FEBRUARY 2022

TABLE I TABLE II
R ESEARCH Q UESTIONS , R ESEARCH D ESIGN , AND DATA S ELECTED S TUDIES AND I MPROVEMENTS ON L EARNING S TRATEGIES
A NALYSIS T ECHNIQUES U SED IN T HIS W ORK

on the latest state of ASD shows the use of Scrum is a trend

for companies as well [1].
The expanded literature review includes studies on team-
work in SEE focused on Scrum and published after the date
of the original review. A search for publications containing the
terms “Scrum,” “SEE,” and “team” in their title, abstract, or
keywords and were published in 2017 yielded three additional
studies [16], [20], [21]. In all, 15 studies focused on Scrum
were (re)analyzed, 12 of which were included in the origi-
nal literature review. Table II summarizes the selected studies’
main contribution to improving ASEST+, the criteria leading discussion of this literature review based on a Web of Science
to their selection, and how the identified improvements are database search can be found in [23]. That study was expanded
included in ASEST+. Section VI further explains how these by adding Scopus as a research database using the same query
approaches were combined. terms as in [23]: TOPIC: [cohesion and team* and (software
Overall, the team-based strategy in ASEST+ is focused on engineering or software development)]. This led to the analysis
using Scrum teams to collaborate in an agile environment. of 23 additional papers.
A project-based learning strategy is sustained throughout the A total of ten antecedents were found to be studied for stu-
capstone course on Scrum and agile practices for developing dent teams: 1) software engineering methodology [24], [25];
real-world projects. Also, a role-playing strategy is employed 2) personality [25]–[27]; 3) conflicts [26], [28]; 4) task
based on the use of Lego games. interdependence [26], [27]; 5) task autonomy [26], [27];
6) feedback [29]; 7) communication [30]; 8) meeting-
V. T EAM C OHESION A NTECEDENTS flow [31]; 9) diversity [32]; and 10) team formation [33] (the
last two antecedents were found through the expanded review).
This section contains two literature reviews and reports on Six antecedents were finally selected to be studied: 1) soft-
a correlational study, all of which were conducted to identify ware engineering methodology; 2) team formation; 3) per-
further directions for improvement of ASEST+ regarding team sonality; 4) conflicts; 5) task interdependence; and 6) task
cohesion antecedents. autonomy. While some of the others may be relevant, they
were not included because they pertain to virtual teams,
A. Team Cohesion Antecedents in SEE whereas agile methods were originally developed for collo-
The first literature review is focused on identifying cohe- cated teams [12]. While agile development is not restricted to
sion antecedents for collocated teams in SEE. A preliminary collocated teams, studies have demonstrated the effectiveness

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 21

TABLE III
DATA S TATISTICS , C ORRELATIONS , AND R EGRESSION W EIGHTS autonomy was not found to be a good predictor (p > 0.05);
therefore, it could be removed from the regression model. As
a result, personality, task interdependence, and conflicts were
the most relevant antecedents to improve the framework.

C. Relevant Antecedents Approaches in ASD

The second literature review focused on how the relevant
antecedents of task interdependence, conflicts, and personality
were addressed for agile development. Searches in the Scopus
and Web of Science databases were performed. The search
string was (“software development” or “software engineer-
ing”) AND agile AND (“task interdependence” or personality
or conflict). In order to assess the quality of the query, the
of agile methods in collocated environments [34], showing
researchers verified that studies they knew to be relevant for
better results in crucial issues such as productivity [35]. The
this search (e.g., [37]) appeared in the results. The search string
antecedents “diversity” and “meeting flow” had been stud-
was (software development or software engineering) AND
ied for collocated teams in educational settings but were not
agile AND (“task interdependence” or personality or conflict).
included for the following reasons: the study in [32] found
In order to assess the quality of the query, the researchers
that diversity was more significant for teams supported by
verified that studies they knew to be relevant for this search
collaborative technologies; meeting flow was removed from
(e.g., [37]) appeared in the results. The query resulted in a col-
the list because it does not refer to a specific construct but
lection of 147 papers published before July 2017. The papers
rather to a whole framework, including several concepts and
for which the full text was not available were excluded, as
approaches.
were proceedings or papers that mentioned these aspects from
a too narrow or irrelevant perspective for our study. A total of
B. Relevant Antecedents for Agile Student Teams 52 papers were retained.
A survey addressing these six antecedents individually and Personality has been studied concerning its influ-
team cohesion as a whole was presented to a sample of ence on job satisfaction and product quality [26], [27],
61 software engineering students working in 17 agile teams. productivity [38], team performance [39], preference for
The students were performing in bachelor and master pro- agile methods [40], the outcome of Scrum teams [41],
grams from the Faculty of Informatics and Mathematics at and pair programming [38], [42]. Individuals’ personality
the University of Holguin. The data were collected between traits, characteristics, and temperaments have been consid-
April and May 2017. The criteria to measure the variables ered for the formation of agile teams [43]–[45] and team
can be found in Appendix B. Using SPSS version 25, relation- structures [46], to predict whether people are suited for
ships between each antecedent and team cohesion were tested. agile methodologies [47], to effectively allocate and rotate
No significant associations were found for the two nonnu- developers in pairs [42], [48], for group development and
merical variables: the analysis of variance (one-way ANOVA) maturity [34] and for Scrum roles [37].
indicated η2 = 0.05, F[(58, 2) = 1.37, p = 0.26] for soft- Two papers about aspects influencing conflicts in ASD
ware engineering methodologies and η2 = 0.06, [F(56, 4) = were found: 1) they discussed socio-cultural differences [49]
9.46, p = 0.44] for team formation. and 2) emotional contagion [50]. Conflicting priorities were
Table III summarizes the data statistics, correlations, and identified as obstacles for decision making in ASD [51].
the results of a regression analysis performed to test rela- Another study showed that conflicts among team members
tionships between the other four antecedents and team cohe- influence the development of real projects in an agile
sion. Pearson correlation confirms a significant correlation academic environment [16]. It was shown in[52] that task
between team cohesion and personality (r = 0.44; p < 0.01), conflicts impact the collaborative software development
task interdependence (r = 0.34; p < 0.01), and conflicts processes and related outcomes. Other studies addressed
(r = −0.46; p < 0.01). There was no significant correlation project management conflicts [53], [54], conflicts in funding
between task autonomy and cohesion (p = 0.02, n.s). processes [55], conflicts between long-term quality and
Multiple regression analysis was conducted to test if short-term progress [52], conflicts between project and
these aspects significantly predicted cohesion. This technique departmental tasks [56], conflicting project prioritization [56],
enables determining a correlation between a criterion variable planning, monitoring, and control conflicts [57], commu-
(cohesion, in this case) and the best combination of several nication conflicts [57], information sharing conflicts [58],
predictor variables [36]. The coefficient of determination indi- results and scheduling conflicts [59], and conflicts between
cated that 40% of the variance in cohesion was explained by organizational control and flexibility [60]. Conflicts
the identified predictors (R2 = 0.40, F(4, 56) = 9.42, p < between stakeholders [51], [61]–[63] and requirements
0.01). Personality was found to significantly predict cohe- conflicts [64]–[66] were the most addressed issues.
sion (β = .38, p < 0.01), as did task interdependence (β = While personality and conflict aspects were found to
0.23, p < 0.05) and conflicts (β = −0.36, p < 0.01). Task be widely addressed in ASD, only two papers about task

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
22 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO. 1, FEBRUARY 2022

TABLE IV
S ELECTED S TUDIES AND I MPROVEMENTS ON C OHESION A NTECEDENTS short quizzes after lectures or before the laboratories allow
the students to expand their knowledge and reinforce their
understanding. Scrum templates and a template to record con-
flicts arising in the project are necessary inputs for project
development.
The course curriculum guidelines (shown in Table V)
include the content to be taught, intended learning outcomes,
teaching and learning activities, and assessment tasks. The
topics can be adapted to introduce new concepts, practices,
and tools. In addition to Scrum and ASD introductions,
as proposed in [17], technical and collaboration practices
are included based on the proposal in [15]. Technical prac-
tices concern testing, continuous integration, and clean code.
Collaboration practices refer to communication (i.e., commu-
nication with customers in order to have a good understanding
of the requirements and intensive and open communica-
tion among all stakeholders). Teamworking skills for conflict
resolution are included as well. Scrum is taught through
a workshop based on [21] and [18]. The teachers have to
ensure that each sprint (a short period during which the Scrum
team works to complete a specific work product) of the cap-
stone project is doable in two to three weeks and provides
interdependence were found. One study focused on the rela-
coaching sessions. Finally, the outputs relate to the developed
tionships between task interdependence and teamwork quality,
project and the learning gained during the course. Therefore,
and project performance [67]. The other speaks of the poten-
in addition to the real-world project and experience applying
tial effects of trust on interdependence [68]. No strategies
Scrum [16], this course’s output includes skills in teamwork
addressing task interdependence for agile teams were found.
and agile practices.
Table IV shows the selected studies’ main contribution toward
Role Allocation: During team formation, role allocation is
improving ASEST+ concerning cohesion antecedents, the
based on personality traits. To that end, the criteria set out
criteria leading to these selections, and how the identified
in [37] are used. Their findings state that agreeableness is
improvements are included in ASEST+. Section VI further
relevant for filling the roles of product owner and devel-
explains how these approaches were combined.
oper, while conscientiousness is important for the role of
Scrum Master. These authors define agreeableness as the
VI. ASEST+ I MPROVEMENTS individual’s extent of friendliness and the degree of trust-
This section describes the improvements of ASEST+ worthiness. Conscientiousness is related to the extent of
regarding four aspects: 1) course design; 2) role allocation; organization, commitment, and persistence. Agreeableness is
3) a win-win Lego game; and 4) team rules agreements. manifested in qualities, such as trust, altruism, and compliance,
Course Design: The course aims to apply Scrum along with while dutifulness, self-discipline, and striving for achievement
agile practices to develop real projects while students learn are related to conscientiousness [72]. In ASEST+, the NEO
how to work as a team. Scrum puts more emphasis on project Personality Inventory [69] is used to assess the presence and
management and does not specifically address technical details extent of these traits (see Appendix B). To assign the roles
for building software, allowing teams to use it together with individuals will play on the team, for each team member, the
other agile methodologies [71]. Therefore, Scrum is used as highest scoring traits are considered in the following order: the
a management framework and some development practices Scrum Masters are assigned first, followed by product owners,
from extreme programming (XP) are included. and then developers.
The students need programming and modeling skills as Win–Win Lego Game: In the one day of Scrum workshop
prerequisites. The course design is based on an educational training, the teams have to build Lego city projects incre-
framework that contains inputs, guidelines, and outputs [17], mentally following the Scrum process. The Lego game flow
based on and adapted from proposals in [21], [15], and [18]. described in [73] was adopted, as can be seen in Fig. 2.
The inputs refer to the resources needed for developing the One teacher conducts the workshop while other teachers
activities. In contrast to the proposal in [17], the software play the role of product owners. As product owners, they
tools here are open to be selected by the teachers. In addition answer questions about the product but do not intervene in
to the teaching materials these authors propose (e.g., slides, the project work. The game includes a conflict resolution pro-
websites and books), Lego blocks are used in the Scrum work- cess based on [61]. The release planning process incorporates
shop and didactic guides are needed to direct students with the proposal of [21]. The teachers explain the prepared back-
respect to assignments. In addition, video tutorials are used log of work in descending order of priority. One planning
to prepare students for solving practical exercises during the poker round with randomly selected participants is conducted
hands-on laboratories. Reading and watching assignments and while the others observe. One user story is chosen, and the

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 23

TABLE V
C OURSE C URRICULUM G UIDELINES

6) customer access; 7) retrospectives; and 8) collocation. An

example conflict resolution item in the TPC questionnaire is
“My team may agree on a solution even though not every
member “buys into” that solution.” A rule to address this
could be “All concerns from team members about reaching
the iteration goals are considered,” addressing the area of
“iteration planning.” Another rule could be “When the scope
cannot be implemented due to constraints, the team holds
active discussions with the customer on reprioritization and
Fig. 2. Training flow.
what to finish within the iteration,” addressing the “iterative
development” area.
As mentioned earlier, such evaluation was mentioned in the
students offer their estimation and explain their reasoning. survey of students using the ASEST0 framework as sometimes
Teachers introduce conflict situations during the sprint plan- being unfair. The particular student who made such mention
ning phase in their role as product owners, and the teams have did not explain the causes of this comment. However, factors,
to collaborate in order to resolve conflicts. The teachers intro- such as interpersonal conflicts or poor teamwork participa-
duce conflicts regarding requirements priorities, introducing tion, might have led to less truthful judgments in the peer
new requirements conflicting with the sprint backlog as well. evaluation.
By means of a win–win negotiation process, team mem- As it is expected that teamwork improves with time,
bers conduct a negotiation by identifying the win conditions repeated opportunities to assess members’ contributions could
from the perspectives of all roles involved. They develop a set lead to fairer feedback and continuous improvement of the
of options, evaluate them, iterate on some, reject others, and agreements. Therefore, the last two phases in ASEST+ should
finally, converge to a mutually satisfactory agreement. During be repeated in cycles (coinciding with the project sprints) in
the review meeting, the product owner again introduces some order to repeatedly evaluate the effectiveness of rules and
conflicts by rejecting some requirements and asking to change team members’ contributions. Occasionally, some regression
others. This leads to requirements conflicts that the team has to phase 1 might be useful, for example, when a student is
to resolve during the next sprint planning phase. late in joining the course/team. In this case, time constraints
Team Rules Agreements: To facilitate reaching agreement, should be carefully considered. Appendix A shows the final
an evaluation of how the teams communicate and resolve con- version of ASEST+ with the new activities underlined.
flicts is conducted through the TPC questionnaire [10]. The
teams have to agree on rules to improve the problems identi-
fied through this evaluation by addressing agile practices. A set VII. ASEST+ VALIDATION
of agile practices is provided based on the proposal in [74] This section reports a quasiexperiment conducted to observe
to assist students. These authors propose a representative set the effects of ASEST+ on students’ perceptions of team
of agile practices for eight common areas: 1) iteration plan- cohesion, team performance, and team learning. A different
ning; 2) iterative development; 3) continuous integration and sample than that used in the correlational study was observed.
testing; 4) stand-up meetings; 5) customer acceptance tests; Table VI describes the composition and demographics per

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
24 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO. 1, FEBRUARY 2022

TABLE VI TABLE VII

G ROUP C OMPOSITION AND D EMOGRAPHICS C OURSE S CHEDULES AND I NTERVENTIONS

subgroup for both the experimental and control groups. The

experimental group was observed over eight weeks in the
period September to November, 2017. A control group from
the same program was observed in the period of September to
November, 2019. The students were enrolled in the Informatics
Engineering program at the University of Holguin in Cuba.
Convenience sampling was used. All the students in the third
and fourth year of the program at that time were included.
The participants were students enrolled in two courses
(Software Engineering II for subgroups 1, and Software
Engineering III for subgroups 2), working in teams of three
to five members. The researcher acted as the main teacher
for both courses, and assistant teachers were coaches. In the
experimental group, the teachers assigned real projects to the
teams, whereas the students presented their own proposals
in the control group. The projects were modules of larger using the instruments proposed by [4]. These instruments were
projects in progress (new for the experimental group students). translated into Spanish by a language specialist, followed by
The experimental group students followed Scrum with some a wording revision of the questions. In addition to two soft-
minor changes because students could not work on the project ware engineering teachers, a psychologist and a sociologist
every day due to other responsibilities. The control group conducted the revision. Just few minor changes regarding cul-
students used Scrum and Iconix, another ASD methodology, tural issues were suggested to adjust the translation for all
as they were already following these methodologies in these instruments. The full adapted questionnaires are included in
projects. The teachers did not interfere in the distribution of Appendix C.
tasks among team members in any group. Table VII shows In order to test the reliability of the instruments, Cronbach’s
the course activities per week for the experimental and control Alpha tests were run. For the three instruments, the Cronbach’s
groups linked to the intervention activities (ASEST+ steps). Alpha values were above the cut-off point (0.7), indicating
Both the experimental and control group students in good internal consistency (0.892 for team cohesion, 0.807 for
Software Engineering II learned about integration and accep- team performance, and 0.886 for team learning). As the stu-
tance tests, while in Software Engineering III, the students dents had already worked together in the same teams in
learned about clean code and unit test practices. In the exper- previous courses, the cohesion of the teams before using
imental group, phases 2 and 3 were deployed two times, ASEST+ could serve as a baseline. Thus, both groups’ vari-
concurring with two project sprints. The study only covered ables were measured during the first week and right after the
eight weeks of the 16-week course to not interfere with the last session.
overall course organization. The courses for the experimen- A Shapiro–Wilk test (recommended as the best choice for
tal and control groups had different designs. For both groups, testing the normality of data [75]) was conducted on the stu-
the students learned the same agile practices; however, the dents’ perceptions for the experimental and control group at
teaching and learning activities were different. In the control the end of the intervention period. It showed p values larger
group, the teaching materials were basically slides and books. than 0.05, indicating that there is no evidence that the val-
Their assessment tasks included just practical exercises in the ues correspond to a normal distribution for team cohesion,
classroom in addition to the capstone project activities. The team learning, and team performance. To check the signifi-
teaching in the control group did not include any teamwork cance of increased team cohesion, performance and learning,
activity beyond the capstone project development itself. These the nonparametric Mann–Whitney U test was used. This test
students were not coached. showed a significant difference between the students’ percep-
The group environment questionnaire (GEQ) [3], adapted to tions regarding team cohesion (p = 0.002), team performance
software engineering teams, was used to measure team cohe- (p = 0.002), and team learning (p = 0.003) in the experi-
sion. Team performance and team learning were measured mental group compared to the perceptions of students in the

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 25

TABLE VIII
M EANS AND D IFFERENCES FOR T EAM COHESION , an influence too. However, the intervention of teachers was
T EAM PERFORMANCE , AND T EAM LEARNING necessary as the students had to develop additional new fea-
tures for an existing modular project. To extend these projects,
they had to delve into existing code, which increased the diffi-
culty level of their tasks. Thus, the teachers had to intervene to
guarantee the assigned work was feasible in the allotted time.
Another factor to consider is the students’ varying levels of
expertise in the software methodologies used. While the con-
trol group students already knew Scrum and Iconix because
they were already applying these methodologies in projects
before the study, the experimental group students had to learn
control group. Table VIII shows the means for the pre/post Scrum before starting the project. This favored the control
measurements of team cohesion, team performance, and team group students.
learning and their deltas.
For both the experimental and control groups, team cohe-
IX. C ONCLUSION AND F UTURE W ORK
sion, team performance, and team learning were not signifi-
cantly different for the measurement during the first week. By This article reports on improvements to the ASEST0 frame-
the last week, the means increased for both groups. However, work to derive the new ASEST+ framework, a proposal
the increments were only significant for the experimental to improve teamwork in terms of team learning and team
group. The Mann–Whitney U tests showed the initial means performance, and the framework’s validation. The improve-
were not significantly different between the two groups, p val- ments focus on four aspects: 1) course design; 2) role alloca-
ues > 0.05, 2-tailed (p = 0.12 for team cohesion, p = 0.64 for tion; 3) a Win-Win Lego game; and 4) team rules agreements.
team performance, and p = 0.70 for team learning). In addi- ASEST+ focuses on Scrum teams. Approaches to team-based
tion, Hedges’ g values showed large effect sizes (5.70 for team learning, project-problem-based learning and role-play gaming
cohesion, 2.21 for team performance, and 3.05 for team learn- were combined in ASEST+ to train the teams in collabora-
ing). These results suggest that the increase can be attributed to tive and technical practices. In addition, ASEST+ establishes
the treatment, although some limitations should be considered. policies for role allocation within Scrum teams by consider-
Section VIII discusses the most important limitations. ing the team members’ personality traits. The rules agreements
have a dynamic nature and are established regarding commu-
nication and conflict management linked to agile practices.
VIII. D ISCUSSION ON VALIDITY The results of a study of two groups of students applying
This section discusses the most important limitations of the ASEST+ indicated that their perceptions of team cohesion,
validity of this work. First, the literature reviews are limited by team performance, and team learning significantly increased
the fact that unavailable papers were excluded; thus, relevant compared with the perceptions of students in the groups that
articles may have been missed. Furthermore, the quasiexper- did not receive this intervention.
iment’s most important limitations are the sample size and Although this study’s findings have limitations in terms of
not having a random sample. In order to deal with the small generalization to other populations, the ASEST+ framework
sample size, however, the statistical analysis included boot- might benefit students in other software engineering programs.
strapping techniques. According to [76], population validity In order to apply ASEST+, time constraints, resources avail-
is problematic in nearly all educational studies as the majority ability, and participants’ characteristics should be carefully
of researchers are forced to select a sample from the acces- taken into account, including their fit with limitations dic-
sible population, and random samples are difficult to obtain. tated by the program/course schedules. The availability of real
Next, while according to some authors, the correlational study clients and projects and commitment by all parties to partic-
sample size used here is appropriate, for others, this could be ipate should be guaranteed beforehand. Cultural issues that
considered a limitation. It has been suggested that a sample might influence students’ willingness to use team rules should
size of at least 200 is required [77]. However, [36] states that be investigated as well. Keeping in mind these matters and
the minimum acceptable sample size for a correlational study the potential limitations discussed, it would be interesting to
for most research is 30. In this case, the study is somewhere study the effects of ASEST+ in other situations.
in between. ASEST+ might also help to improve similar learning envi-
The quasiexperiment was also limited by the location in ronments though knowledge transfer of educational content
which the investigation took place. The local conditions and and case studies derived from its application. In addition,
the socio-economic status and cultural background of the par- the information gathered could contribute to better under-
ticipants might have influenced the study. As the researcher stand software engineering students’ teams in order to further
acted as the main teacher, researcher bias (e.g., personality improve agile teamwork in SEE. Future work will further
traits or preconceived beliefs of the researcher) might have explore the validity of the ASEST+ framework and focus
had some impact as well. Teachers were assigning projects to on new and larger samples. In addition, further research will
the students in the experimental group while the students in the explore the mediational role of team cohesion between the
control group presented their own proposals might have had antecedents and the outputs.

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
26 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO. 1, FEBRUARY 2022

A PPENDIX A Team assignment)

(ASEST+ F RAMEWORK W ITH THE N EW I SSUES Team project. User Stories are written and estimated. First version of Product
Backlog is written. Sprint and Release Planning is done (5 h, Team assign-
U NDERLINED )1 ment)
Phase 1 Preparation: Setting of the elearning environment, teams, projects, Output: Team rules agreement, Product Backlog, Sprint, and Release Planning,
and introduction activities Conflicts record
Step 1. Setting the scene. Introduction to ASD Step 6. Team agreement establishment. Agile practices application
Input: Lesson contents, Assignment guides, Project descriptions, NEO Input: Team rules agreement, Assignment guide, Lesson contents, Scrum
Personality Inventory (PI) questionnaire, Short quizzes artifacts, Automated build and test environments, Computers and collocated
Overview explanation of the framework (10 min) environment, Scrum templates, Conflicts template
Formation of 3-7 member teams (10 min) Assessment of team rules in order to track their effectiveness and improve
Personality traits identification through the NEO PI questionnaire (30 min) upon agreements (15 min, Individual assignment)
Assignation of roles based on personality traits (15 min) Discussion in teams about rules implementation (30 min, Team assignment).
Assignation of projects to the teams (5 min) Reading/watching assignment (60 min)
Lesson on introduction to ASD and agile teamwork (60 min) Hands-on laboratory on agile practices (45 min)
Reading/watching assignments (Individual assignments)(30 min) Team project. Development of the project. (5 h)
Short quizzes on ASD and agile teamwork(20 min) Output: Team agreement assessment report, Practical exercises solved,
Output: Team structure; Assignments completed Product increment, Unit/Integration/Acceptance tests, Conflicts record, Scrum
Step 2. Diagnosis of teamwork skills and conflict-handling styles artifacts
Input: TKT and Thomas-Kilman Instrument (TKI), also known as Thomas-
Kilmann Conflict Mode Inventory, questionnaires, Assignment guides Phase 3 Adjustment: Agreements adjustment and sprint /project conclusion
Diagnosis of teamwork knowledge via the TKT questionnaire (30 min,
Individual assignment) Step 7. Feedback
Analysis of the TKT questionnaire results (15 min, Team assignment) Input: CATME-B questionnaire, Assignment guides, Lesson contents, Scrum
Diagnosis of conflict-handling style through the TKI questionnaire. (20 min, artifacts, Automated build, and test environments, Computers and collocated
Individual assignment) environment, Scrum templates, Conflicts template
Analysis of team weaknesses and strengths with respect to handling conflicts Self and peer evaluations of team member contributions. Completing the
considering individual styles.(20 min, Team assignment) CATME-B questionnaire. (20 min, Individual assignment)
Output: Individual diagnosis and team lessons learned, Team member conflict- Elaboration of the joint perception matrix including the individual average
handling styles; Team conflict-handling styles analysis scores of each member’s contribution assessment (15 min, Team assignment)
Step 3. Training on Scrum and teamworking skills. Introduction to agile Discussion in teams of the matrix scores in order to identify problems.
practices (30 min, Team assignment)
Input: Lesson contents, Assignment guides, Short quizzes, Lego blocks, Team project. Development tasks. Sprint Review & Retrospective (5 h)
Planning poker cards, Lego project backlog, conflicting situations descrip- Reading/watching assignments (60 min)
tion, Belbin’s roles questionnaire Hands-on laboratory on agile practices (45 min)
Reading/watching assignments on Scrum (60 min, Individual assignment) Output: Team member contributions matrix, Practical exercises solved, Scrum
Short quiz on Scrum (20 min, Individual assignment) artifacts, Unit/Integration/Acceptance tests,Sprint lessons learned, Conflicts
Explanation of the training (10 min) record
Identification of Belbin’s roles (optional, 20 min, Individual assignment) Step 8. Team agreement update
Scrum process simulation via Lego projects. Resolution of conflicting situa- Input: Team member contributions matrix, team rules agreement, Scrum arti-
tions (120 min) facts, and reports
Analysis of the teamwork demonstrated in the game (20 min, Team assign- Identification of new team rules (30 min)
ment) Updating the rules agreements (15 min)
Lesson on introduction on agile practices (60 min) Presentation of the project (2 h)
Reading/watching assignment (30 min, Individual assignment) Output: Team agreement updated, Project solution
Short quiz on agile practices (20 min, Individual assignment)
Output: Lego projects developed; Report on the game; Quizzes answered

Phase 2 Implementation: Team rules agreement establishment, sprint project

deployment, and agile practices application
A PPENDIX B
Step 4. Team functioning diagnosis. Introduction to automated build and
test environments (C RITERIA TO M EASURE VARIABLES IN THE
Input: TPC questionnaire, Lesson contents, Assignment guides, Software C ORRELATIONAL S TUDY )
tools, Computers, and collocated environment
Diagnosis of team functioning via the TPC questionnaire (10 min, Individual
assignment)
Elaboration of the joint perception matrix for team functioning. (15 min, Team
assignment) Variables Instrument or criteria Values
Reading/watching assignment (60 min) Software Software engineering Iconix, Scrum, XP
Hands-on laboratory on automated build and test environments (90 min) engineering methodology used
Team project. Set up/update the automated build and test environment (3 h, methodology
Team assignment) Team formation Criteria of [78] self-selection;
Output: Joint perception matrix on team functioning; Practical exercises random; by command
solved; Automated environment setup/updated Personality NEO Personality openness to experi-
Inventory, Spanish ence, conscientious-
Step 5. Team rules agreement. Team project beginning version [69] ness, extraversion,
Input: Joint perception matrix on team functioning, Automated build and agreeableness,
test environment, Computers and collocated environment, Scrum templates, neuroticism
Conflicts template, List of systematic agile practices, Assignment guides Conflicts Survey of [79] Likert scale
Setting up the agreements. Identification of team rules regarding communi- Task autonomy Survey of [80] Likert scale
cation and conflict resolution linked to systematic agile practices. (30 min, Task interdepen- Survey of [81] Likert scale
dence
1 The ASEST0 framework can be derived by eliminating the underlined Team cohesion GEQ Likert scale
issues. questionnaire [3]

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 27

A PPENDIX C [3] A. V. Carron, W. N. Widmeyer, and L. R. Brawley, “The development of

(F ULL Q UESTIONNAIRES *) an instrument to assess cohesion in sport teams: The group environment
questionnaire,” J. Sport Exercise Psychol., vol. 7, no. 3, pp. 244–266,
Team learning (5 point scale from never to always) 1985, doi: 10.1123/jsp.7.3.244.
We regularly take time to figure out ways to improve our teamwork processes [4] A. Edmonson, “Psychological safety and learning behavior in work
This team tends to handle differences of opinion privately or off-line, rather teams,” Admin. Sci. Quart., vol. 44, no. 2, pp. 350–383, 1999.
than addressing them directly as a group** [5] J. Mathieu, M. T. Maynard, T. Rapp, and L. Gilson, “Team effec-
The members of this team seek all possible information they need for project tiveness 1997-2007: A review of recent advancements and a glimpse
development from other sources outside the team such as customers or other into the future,” J. Manage., vol. 34, no. 3, pp. 410–476, 2008,
stakeholders, or domain experts doi: 10.1177/0149206308316061.
This team frequently seeks new information that leads us to make important [6] M. Zarraga-Rodriguez, C. Jaca, and E. Viles, “Enablers of team effec-
changes tiveness in higher education: Lecturers’ and students’ perceptions at
In this team, someone always makes sure that we stop to reflect on the team- an engineering school,” Team Perform. Manage., vol. 21, nos. 5–6,
work process pp. 274–292, 2015.
The members of this team always express a frank opinion about the issues [7] D. T. Avila and W. Van Petegem, “An experience using team rules for
under discussion improving team work in software engineering undergraduate education,”
We invite people from outside the team to present information or have in Proc. Int. Conf. Educ. New Learn. Technol. (EDULEARN), 2017,
discussions with us pp. 2685–2690.
Team performance (5 point scale from very inaccurate to very accurate) [8] J. E. Sims-Knight, R. L. Upchurch, T. A. Powers, S. Haden, and
Recently, this team seems to be slipping a bit in its level of performance and R. Topciu, “Teams in software engineering education,” in Proc. 32nd
accomplishments ** Front. Edu Conf., Boston, MA, USA, 2002, pp. 17–22.
Those who receive or use the work of this team often have complaints about [9] J. B. Kidd and R. M. Belbin, “Management teams—Why they suc-
our work ** ceed or fail,” J. Oper. Res. Soc., vol. 33, no. 4, pp. 392–393, 2006,
The quality of work provided by this team is improving over time doi: 10.2307/2581652.
Critical quality errors occur frequently in this team** [10] T. A. Powers, J. Sims-Knight, R. A. Topciu, and S. C. Haden, “Assessing
Others around us who interact with this team frequently complain about how team functioning in engineering education,” in Proc. Amer. Soc. Eng.
it functions** Educ. Annu. Conf. Exposit., 2002, pp. 199–216.
Team cohesion (5 point scale from strongly disagree to strongly agree)
[11] M. W. Ohland et al., “The comprehensive assessment of team member
I do not enjoy being a part of the social activities of this team** effectiveness: Development of a behaviorally anchored rating scale for
I’m not happy with my participation in the project** self and peer evaluation,” Acad. Manage. Learn. Educ., vol. 11, no. 4,
I am not going to miss the members of this team when the project ends** pp. 609–631, 2012, doi: 10.5465/amle.2010.0177.
I’m unhappy with my team’s level of desire to successfully end the project** [12] K. Beck et al.. (2001). Manifesto for Agile Software Development.
Some of my best friends are on this team [Online]. Available: http://www.agilemanifesto.org
This team does not give me enough opportunities to improve my personal
[13] J. Popay et al., Guidance on the Conduct of Narrative Synthesis
performance**
in Systematic Reviews: A Product From the ESRC Methods
I enjoy other parties rather than team parties**
Programme, Lancaster University, Lancaster, U.K., 2006,
I do not like the style of work on this team**
doi: 10.13140/2.1.1018.4643.
For me, this team is one of the most important social groups to which I belong
Our team is united in trying to reach its project goals [14] S. L. Weinberg and S. K. Abramowitz, Statistics Using SPSS: An
Members of our team would rather go out on their own than get together as Integrative Approach, 2nd ed. Cambridge, U.K.: Cambridge Univ. Press,
a team** 2008.
We all take responsibility for any failure or poor performance by our team [15] M. Kropp, A. Meier, and G. Perellano, “Experience report of
Our team members rarely party together ** teaching agile collaboration and values: Agile software develop-
Our team members have conflicting aspirations for the team’s performance** ment in large student teams,” in Proc. IEEE 29th Int. Conf. Softw.
Our team would like to meet sometime after the project is completed Eng. Educ. Train. (CSEET), Dallas, TX, USA, 2016, pp. 76–80,
If members of our team have problems, everyone wants to help them so we doi: 10.1109/CSEET.2016.30.
can get back together again [16] M. Villavicencio, E. Narváez, E. Izquierdo, and J. Pincay, “Learning
Team members do not like to meet after work on the project** Scrum by doing real-life projects,” in Proc. IEEE Global Eng.
Our team members do not express themselves honestly about each other’s Educ. Conf. (EDUCON), Athens, Greece, Apr. 2017, pp. 1450–1456,
responsibilities in completing the project** doi: 10.1109/EDUCON.2017.7943039.
*Adapted from [3] [4], **Reverse scored [17] M. Villavicencio, “Development of a framework for the education of
software measurement in software engineering undergraduate programs,”
M.S. Thesis, Dept. Doctor Philos., École De Technologie Supérieure
Université Du Québec, Montreal, QC, Canada, 2014.
ACKNOWLEDGMENT [18] M. Paasivaara, V. Heikkilä, C. Lassenius, and T. Toivola, “Teaching
students Scrum using LEGO blocks,” in Proc. 36th Int. Conf. Softw.
The authors would like to thank the participants in these Eng., 2014, pp. 382–391, doi: 10.1145/2591062.2591169.
studies, especially the assistant teachers Ivet Challenger Pérez [19] T. D. Lynch et al., “An agile boot camp: Using a LEGO -based
R active
and Antonio López Zaragoza, to Professors Jenny Ruiz de game to ground agile development,” in Proc. Front. Educ. Conf., Rapid
City, SD, USA, 2011, pp. 1–6.
la Peña and Marcia E. Noda Hernández, as well as the edi- [20] M. Paasivaara, J. Vanhanen, V. T. Heikkilä, C. Lassenius, J. Itkonen, and
tor and reviewers of this journal for their valuable feedback. E. Laukkanen, “Do high and low performing student teams use Scrum
They would also like to thank Enago (www.enago.com) for differently in capstone projects?” in Proc. IEEE/ACM 39th Int. Conf.
Softw. Eng. Softw. Eng. Educ. Train. Track (ICSE-SEET), Buenos Aires,
the English language review. Argentina, 2017, pp. 146–149, doi: 10.1109/ICSE-SEET.2017.22.
[21] J.-P. Steghöfer, H. Burden, H. Alahyari, and D. Haneberg, “No
silver brick: Opportunities and limitations of teaching Scrum with
R EFERENCES Lego workshops,” J. Syst. Softw., vol. 131, pp. 230–247, Sep. 2017,
doi: 10.1016/j.jss.2017.06.019.
[1] 14th Annual State of Agile Report, VersionOne, Alpharetta, GA, USA, [22] V. Mahnič, “Scrum in software engineering courses: An outline of the
2020. literature,” Global J. Eng. Educ., vol. 17, no. 2, pp. 77–83, 2015.
[2] D. T. Avila, W. Van Petegem, and A. Libotton, “ASEST framework: [23] D. Tamayo, W. Van Petegem, Y. C. Ochoa, and M. N. Hernández, “A
A proposal for improving teamwork by making cohesive software correlational study on factors that influence the cohesion of software
engineering student teams,” Eur. J. Eng. Educ., pp. 1–15, Dec. 2020, engineering students teams,” in Proc. Int. Technol. Educ. Develop. Conf.
doi: 10.1080/03043797.2020.1863339. (INTED), 2018, pp. 5697–5702, doi: 10.21125/inted.2018.1354.

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
28 IEEE TRANSACTIONS ON EDUCATION, VOL. 65, NO. 1, FEBRUARY 2022

[24] C. A. Wellington, T. Briggs, and C. D. Girard, “Comparison of stu- [45] E. Papatheocharous, M. Belk, J. Nyfjord, P. Germanakos, and
dent experiences with plan-driven and agile methodologies,” in Proc. G. Samaras, “Personalised continuous software engineering,” in Proc.
35th Front. Educ. Conf., Indianopolis, IN, USA, 2005, pp. 18–23, 1st Int. Workshop Rapid Continuous Softw. Eng. (RCoSE), 2014,
doi: 10.1109/FIE.2005.1611951. pp. 57–62, doi: 10.1145/2593812.2593815.
[25] J. S. Karn, S. Syed-Abdullah, A. J. Cowling, and M. Holcombe, “A [46] M. Yilmaz, R. V. O’Connor, R. Colomo-Palacios, and P. Clarke, “An
study into the effects of personality type and methodology on cohesion examination of personality traits and how they impact on software devel-
in software engineering teams,” Behav. Inf. Technol., vol. 26, no. 2, opment teams,” Inf. Softw. Technol., vol. 86, pp. 101–122, Jun. 2017,
pp. 99–111, Mar. 2007, doi: 10.1080/01449290500102110. doi: 10.1016/j.infsof.2017.01.005.
[26] S. T. Acuña, M. Gómez, and N. Juristo, “How do personality, team [47] R. Bhannarai and C. Doungsa-Ard, “Agile person identification through
processes and task characteristics relate to job satisfaction and soft- personality test and kNN classification technique,” in Proc. 2nd Int.
ware quality?” Inf. Softw. Technol., vol. 51, no. 3, pp. 627–639, 2009, Conf. Sci. Inf. Technol. (ICSITech), Balikpapan, Indonesia, 2017,
doi: 10.1016/j.infsof.2008.08.006. pp. 215–219, doi: 10.1109/ICSITech.2016.7852636.
[27] S. T. Acuña, M. N. Gómez, and J. de Lara, “Empirical study of how per- [48] V. Venkatesan and A. Sankar, “Investigation of student’s personal-
sonality, team processes and task characteristics relate to satisfaction and ity on pair programming to enhance the learning activity in the
software quality,” in Proc. 2nd ACM-IEEE Int. Symp. Empir. Softw. Eng. academia,” J. Comput. Sci., vol. 10, no. 10, pp. 2020–2028, 2014,
Meas. (ESEM), 2008, pp. 291–293, doi: 10.1145/1414004.1414056. doi: 10.3844/jcssp.2014.2020.2028.
[28] M. Gómez and S. T. Acuña, “Study of the relationships between person- [49] H. Ozawa and L. Zhang, “Adapting agile methodology to overcome
ality, satisfaction and product quality in software development teams,” social differences in project members,” in Proc. Agile Conf., 2013,
in Proc. 19th Int. Conf. Softw. Eng. Knowl. Eng., 2007, pp. 292–295. pp. 82–87, doi: 10.1109/AGILE.2013.13.
[29] A. Castro-Hernández, K. Swigger, and M. Ponce-Flores, “Effects [50] A. Alhubaishy and L. Benedicenti, “Toward a model of emotional con-
of cohesion-based feedback on the collaborations in global tagion influence on agile development for mission critical systems,”
software development teams,” in Proc. 10th IEEE Int. Conf. in Proc. Int. Conf. High Perform. Comput. Simulat. (HPCS), 2017,
Collab. Comput. Netw. Appl. Worksharing, 2014, pp. 74–83, pp. 541–544, doi: 10.1109/HPCS.2017.86.
doi: 10.4108/icst.collaboratecom.2014.257332. [51] M. Drury, K. Conboy, and K. Power, “Obstacles to decision making
[30] A. Castro-Hernández, K. Swigger, M. P. Ponce-Flores, and J. D. Terán- in Agile software development teams,” J. Syst. Softw., vol. 85, no. 6,
Villanueva, “Measures for predicting task cohesion in a global pp. 1239–1254, 2012, doi: 10.1016/j.jss.2012.01.058.
collaborative learning environment,” in Proc. IEEE 11th Int. [52] N. B. Moe, “Key challenges of improving agile teamwork,” in Agile
Conf. Global Softw. Eng. Workshops (ICGSEW), 2016, pp. 31–36, Processes in Software Engineering and Extreme Programming (Lecture
doi: 10.1109/ICGSEW.2016.23. Notes in Business Information Processing), vol. 149. Berlin, Germany:
[31] C.-Y. Chen, Y.-C. Hong, and P.-C. Chen, “Effects of the meetings- Springer, 2013, pp. 76–90, doi: 10.1007/978-3-642-38314-4_6
flow approach on quality teamwork in the training of software capstone [53] J. Noll, M. A. Razzak, J. M. Bass, and S. Beecham, “A study of the
projects,” IEEE Trans. Educ., vol. 57, no. 3, pp. 201–208, Aug. 2014, scrum master’s role,” in Product-Focused Software Process Improvement
doi: 10.1109/TE.2014.2305918. (Lecture Notes in Computer Science). Cham, Switzerland: Springer,
[32] L. Chidambaram and T. Carte, “Diversity: Is there more than meets the 2017, pp. 307–323, doi: 10.1007/978-3-319-69926-4_22.
eye? a longitudinal study of the impact of technology support on teams [54] K. J. Taylor, “Adopting Agile software development: The project man-
with differing diversity,” in Proc. 38th Annu. Hawaii Int. Conf. Syst. ager experience,” Inf. Technol. People, vol. 29, no. 4, pp. 670–687, 2016,
Sci., 2005, p. 48a. doi: 10.1108/ITP-02-2014-0031.
[33] M. K. Shaikh, A. Raza, and K. Ahsan, “Software project management [55] L. Cao, K. Mohan, B. Ramesh, and S. Sarkar, “Adapting funding
as team building intervention,” J. Basic Appl. Sci., vol. 12, pp. 365–373, processes for agile IT projects: An empirical investigation,” Eur. J. Inf.
Aug. 2016, doi: 10.6000/1927-5129.2016.12.56. Syst., vol. 22, no. 2, pp. 191–205, 2013, doi: 10.1057/ejis.2012.9.
[34] L. Gren, R. Torkar, and R. Feldt, “Group development and group [56] H. Salameh and L. Alnaji, “Challenges leading to projects struggle in IT
maturity when building agile teams: A qualitative and quantitative inves- project management office,” WSEAS Trans. Bus. Econ., vol. 11, no. 1,
tigation at eight large companies,” J. Syst. Softw., vol. 124, pp. 104–119, pp. 262–271, 2014.
Feb. 2017, doi: 10.1016/j.jss.2016.11.024. [57] J. Pechau, “Rafting the Agile waterfall: Value based conflicts of agile
[35] S. D. Teasley, L. A. Covi, M. S. Krishnan, and J. S. Olson, “Rapid software development,” in Proc. 16th Eur. Conf. Pattern Lang. Programs
software development through team collocation,” IEEE Trans. Softw. (EuroPLoP), 2012, pp. 1–15, doi: 10.1145/2396716.2396731.
Eng., vol. 28, no. 7, pp. 671–683, Jul. 2002. [58] J. Pechau, “Conflicting value systems in agile software development
[36] J. R. Fraenkel and N. E. Wallen, How to Design and Evaluate Research projects,” in Proc. 18th Conf. Pattern Lang. Programs, 2011, pp. 1–7,
in Education, 7th ed. New York, NY, USA: McGraw-Hill, 2009. doi: 10.1145/2578903.2579160.
[37] R. Baumgart, M. Hummel, and R. Holten, “Personality traits of Scrum [59] R. Rodin, J. Leet, M. Azua, and D. Bygrave, “A pattern language for
roles in agile software development teams—A qualitative analysis,” in release and deployment management,” in Proc. 18th Conf. Pattern Lang.
Proc. Eur. Conf. Inf. Syst. (ECIS), 2015, pp. 1–15. Programs, 2011, pp. 1–11, doi: 10.1145/2578903.2579147.
[38] K. S. Choi, F. P. Deek, and I. Im, “Exploring the underlying aspects [60] J. E. Hannay and H. C. Benestad, “Perceived productivity
of pair programming: The impact of personality,” Inf. Softw. Technol., threats in large agile development projects,” in Proc. ACM-IEEE
vol. 50, no. 11, pp. 1114–1126, 2008, doi: 10.1016/j.infsof.2007.11.002. Int. Symp. Empir. Softw. Eng. Meas. (ESEM), 2010, pp. 1–10,
[39] M. Omar and S.-L. Syed-Abdullah, “Identifying effective software doi: 10.1145/1852786.1852806.
engineering (SE) team personality types composition using rough set [61] U. Z. Khan, F. Wahab, and S. Saeed, “Integration of Scrum with win-
approach,” in Proc. Int. Symp. Inf. Technol., Kuala Lumpur, Malaysia, win requirements negotiation model,” Middle East J. Sci. Res., vol. 19,
2010, pp. 1499–1503. no. 1, pp. 101–104, 2014, doi: 10.5829/idosi.mejsr.2014.19.1.11770.
[40] D. Bishop and A. Deokar, “Toward an understanding of preference for [62] J. Abdelnour-Nocera and H. Sharp, “Understanding conflicts in Agile
agile software development methods from a personality theory per- adoption through technological frames,” Int. J. Sociotechnol. Knowl.
spective,” in Proc. Int. Conf. Syst. Sci., Waikoloa, HI, USA, 2014, Develop., vol. 4, no. 2, pp. 29–45, 2012, doi: 10.4018/jskd.2012040104.
pp. 4749–4758, doi: 10.1109/HICSS.2014.583. [63] R. V. Anand and M. Dinakaran, “Handling stakeholder
[41] D. T. M. C. Branco, R. Prikladnicki, and T. Conte, “A preliminary study conflict by agile requirement prioritization using Apriori tech-
on personality types in teams Scrum,” in Proc. Conf. Softw. Eng. Steering nique,” Comput. Elect. Eng., vol. 61, pp. 126–136, Jul. 2017,
Committee (CIbSE), 2012. doi: 10.1016/j.compeleceng.2017.06.022.
[42] P. Sfetsos and I. Stamelos, “Improving quality by exploit- [64] V. Sachdeva and L. Chung, “Handling non-functional requirements for
ing human dynamics in agile methods,” in Agile Software big data and IOT projects in Scrum,” in Proc. 7th Int. Conf. Cloud
Development Quality Assurance, Idea Group, 2011, pp. 154–170, Comput. Data Sci. Eng. Confluence, Noida, India, 2017, pp. 216–221,
doi: 10.4018/978-1-59904-216-9.ch008. doi: 10.1109/CONFLUENCE.2017.7943152.
[43] S. Licorish, A. Philpott, and S. G. MacDonell, “Supporting [65] P. Busetta, “Addressing team awareness by means of a requirement pri-
agile team composition: A prototype tool for identify- oritization tool,” in Proc. 22nd Int. Conf. Requirements Eng. Found.
ing personality (in)compatibilities,” in Proc. ICSE Workshop Softw. Qual., 2017.
Cooper. Hum. Aspects Softw. Eng. (CHASE), 2009, pp. 66–73, [66] P. Chetankumar and M. Ramachandran, “Story card maturity model
doi: 10.1109/CHASE.2009.5071413. (SMM): A process improvement framework for agile requirements
[44] M. Omar and N. L. A. Khasasi, “Designing an Agile Scrum team engineering practices,” J. Softw., vol. 4, no. 5, pp. 422–435, 2009,
formation model,” in Proc. Conf. Inf. Syst., 2017, pp. 145–154. doi: 10.4304/jsw.4.5.422-435.

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.
TAMAYO AVILA et al.: IMPROVING TEAMWORK IN AGILE SEE: ASEST+ FRAMEWORK 29

[67] K. F. Kuthyola, J. Y.-C. Liu, and G. Klein, “Influence of Task Daymy Tamayo Avila received the B.S. degree in software engineering from
Interdependence on Teamwork Quality and Project Performance,” in the University of Holguin, Holguín, Cuba, in 2005, and the M.Sc. degree
Business Information Systems (Lecture Notes in Bussiness Information in applied informatics from the University of Informatics Sciences, Havana,
Processing), vol. 288. Cham, Switzerland: Springer, 2017, pp. 135–148, Cuba, in 2008. She is currently pursuing the Doctoral degree with KU Leuven,
doi: 10.1007/978-3-319-59336-4_10. Leuven, Belgium.
[68] I. F. Barbosa, M. P. Oliveira, P. B. S. Reis, T. C. S. Gomes, and F. Q. She is an Associate Professor with the University of Holguin. She has
B. Da Silva, “Towards understanding the relationships between interde- been teaching courses on software engineering and management for 15 years.
pendence and trust in software development: A qualitative research,” in Her research interests include software engineering education, technologies
Proc. IEEE/ACM 10th Int. Workshop Cooper. Hum. Aspects Softw. Eng. enhanced learning, software engineering process, models, and management.
(CHASE), 2017, pp. 66–69, doi: 10.1109/CHASE.2017.12.
[69] P. T. J. Costa and R. R. McCrae, “NEO personality inventory, Spanish
version,” in Psychological Assessment Resources, TEA Ediciones
Madrid, Odessa, FL, USA, 2002.
[70] V. Balijepally, R. Mahapatra, S. P. Nerur, and S. Nerur, “Assessing per-
sonality profiles of software developers in Agile development teams,”
Commun. Assoc. Inf. Syst., vol. 18, pp. 55–75, Aug. 2006. [Online].
Available: https://aisel.aisnet.org/cais/vol18/iss1/4
[71] K. Schwaber and J. Sutherland. (2020). The Scrum Guide. Accessed:
Apr. 10, 2021. [Online]. Available: scrumguides.org
Wim Van Petegem (Member, IEEE) received the Ph.D. degree in electrical
[72] P. T. Costa and R. R. Mccrae, “Domains and facets: Hierarchical
engineering from KU Leuven, Leuven, Belgium, in 1993.
personality assessment using the revised NEO personality
He is an Associate Professor with the Faculty of Engineering Technology,
inventory,” J. Pers. Assess., vol. 64, no. 1, pp. 21–50, 1995,
KU Leuven, and Policy Coordinator Learning Technologies. He has worked
doi: 10.1207/s15327752jpa6401_2.
with the University of Alberta, Edmonton, AB, Canada, the Open University
[73] M. Paasivaara, V. Heikkilä, C. Lassenius, and T. Toivola, “Teaching
of the Netherlands, Heerlen, The Netherlands, and the Leuven University
students scrum using LEGO blocks,” in Proc. 36th Int. Conf. Softw.
College, Leuven. His research interests are in the field of multimedia pro-
Eng., 2014, pp. 382–391, doi: 10.1145/2591062.2591169.
duction, new educational technology, networked e-learning, virtual mobility,
[74] C. So and W. Scholl, “Perceptive Agile measurement: New instruments
lifelong learning, open and distance learning, engineering education, and
for quantitative studies in the pursuit of the social-psychological effect
professional and intercultural engineering skills.
of agile practices,” in Proc. Int. Conf. Agile Process. Extreme Program.
Dr. Van Petegem is actively involved in different networks of universities,
Soft. Eng., 2009, pp. 83–93.
such as a Fellow of SEFI, a Senior Fellow of EDEN, and a President of
[75] N. M. Razali and Y. B. Wah, “Power comparisons of Shapiro-Wilk,
MEDEA.
Kolmogorov-Smirnov, Lilliefors and Anderson-Darling tests,” J. Stat.
Model. Anal., vol. 2, no. 1, pp. 21–33, 2011.
[76] A. J. Onwuegbuzie, “Expanding the framework of internal and external
validity in quantitative research,” Res. Sch., vol. 10, no. 1, pp. 71–78,
2003.
[77] P. Kline, The Handbook of Psychological Testing, 2nd ed. NewYork,
NY, USA: Routledge, 2000.
[78] R. Decker, “Management team formation for large scale simulations,”
in Development in Business Simulations and Experiential Exercises,
vol. 22. Statesboro, GA, USA: Assoc. Bus. Simulat. Exp. Learn., 1995,
pp. 128–129. Monique Snoeck (Member, IEEE) received the Ph.D. degree in computer
[79] K. A. Jehn, “A multimethod examination of the benefits and detri- science from KU Leuven, Leuven, Belgium, in 1995.
ments of intragroup conflict,” Admin. Sci. Quart., vol. 40, pp. 256–282, She is a Full Professor with the Research Center for Management
Jun. 1995. Informatics (LIRIS), KU Leuven and a Visiting Professor with the University
[80] E. Molleman and A. van den Beukel, “Worker flexibility and of Namur, Namur, Belgium. She has published over 130 peer-reviewed papers.
its perceived contribution to performance: The moderating role,” Her research focuses on smart learning environments, enterprise modeling,
Hum. Factors Ergon. Manuf., vol. 17, no. 2, pp. 117–135, 2007, requirements engineering, model-driven engineering, and business process
doi: 10.1002/hfm.20069. management and learning analytics. Her main guiding research themes are the
[81] G. S. van der Vegt, B. J. M. Emans, and E. Van De Vuert, “Patterns of integration of different modeling approaches into a comprehensive approach,
interdependence in work teams: A two-level investigation of the relations the quality of models through formal grounding, model to code transforma-
with job and team satisfaction,” Pers. Psychol., vol. 54, no. 1, pp. 51–69, tions, educational aspects of conceptual modeling, and technology-enhanced
2001. learning.

Authorized licensed use limited to: UNIVERSITAS GADJAH MADA. Downloaded on March 09,2023 at 06:31:22 UTC from IEEE Xplore. Restrictions apply.