Context

Agility allows the rapid construction of computer programs by adopting iterative and incremental models where analysis, design and construction activities are interspersed (^{Pressman, 2014}). There are several methodologies with these features, all of which are based on a set of principles gathered in the agile manifest (^{Kendall & Kendall, 2013}). Literature extensively discusses the philosophy, principles and practices of agile methodologies (^{Kendall & Kendall, 2013}; Pressman, 2013; ^{Beck & Andres, 2005}). In this field, empirical research has focused more on industrial settings than on educational scenarios (^{Fuertes & Sepúlveda, 2016}). Also, it must considered that the software engineering literature recognizes that not all facts found in literature are based on empirical evidence; for example, there are many procedures or techniques purported to be better than others based on opinions instead of real objective data (^{Juristo & M., 2001}). On the other hand, software engineering is a practical area, where the teaching and learning process should not rely on the single automatic repetition of concepts or theoretical case studies, but should also involve activities that present scenarios to students to generate their own knowledge from new experiences.

Earlier studies

Agile development has been a topic of interest in several studies conducted in business and industrial scenarios during the last five years. For instance, ^{Yetunde & Kolade (2015)} studied collaboration and strategies used to integrate usability activities into a big scale agile project ; they found that some tactics like negotiating inclusion and establishing credibility were useful in succeeding in this process. On the other hand, ^{Serrador & Pinto (2015)} studied efficiency and user satisfaction in several industrial projects , and a positive effect of agile software methodologies was observed. ^{Papatheocharus & Andreou (2014)} used a questionnaire to study communication, management and quality assurance, aspects of agile teams. The results showed that agility improved the development process. ^{McHugh, Conboy, & Lang (2012)} analyzed several case studies in which the importance of human aspects in software development was highlighted. Their study observed that agile practices increased trust among programmers. In a previous work by ^{McHugh, Conboy, & Lang (2011)}, a study involving three agile practices was conducted, and it was found that motivation was recognized to be highly important for the project and its leaders. In that research, it was also stressed that motivation is not addressed as much as other topics in the context of agile practices.

Agile software practices in the teaching field have also caught the attention of some researchers. For example, ^{Salleh, Mendes, & Grundy (2014)} studied the personality of students in pair programming practices; they found that openness was a significant factor to differentiate academic performance in students and that Pair Programming caused increased satisfaction, confidence and motivation in the class. Additionally, ^{von Wangenheim, Savi, & Ferreti Borgatto (2013)} and ^{Rodriguez, Soria, & Ocampo (2015)}, studied the educational resources needed to teach SCRUM; they presented inexpensive games to reinforce the application of SCRUM. They reported that their approaches engaged students in the SCRUM activities inside the classroom; good motivation and good user experiences were described as well. Additionally, ^{Devedzic & Milenkovic (2011)} analyzed the experiences and problems encountered when teaching agile software development with SCRUM and XP in different scenarios and cultures; they learned that iterations should be short, that pairing up students helps them increase their motivation levels, that practices are useful to increase commitment among students, and that teams should be small and self-organized. ^{Schroeder, Klarl, Mayer, & Kroiss (2012)} studied the importance of lab practices when teaching agile approaches; they discovered that SCRUM was suitable to introduce students to software processes and that it motivated students by posing fun challenges to them. ^{Kropp & Meier (2013)}, ^{Kofune & Koita (2014)}, ^{Soria, Campo, & Rodríguez (2012)}, ^{J. Faria, Yamanaka, & Tavares, (2012)} presented their experiences in the teaching of agility and offered models to successfully address these types of courses. For example, Kofuna & Koita (2014) derived an approach to teach programming based on agile practices; they promoted critical thinking and communication among students using the trial and error practice. It was found that students were very motivated to learn. Moreover, in the work of ^{Enríquez & Gómez (2015)}, a model for improving agile software development training in small companies is described; the model is based on SCRUM and consists on meetings, tasks, practices and steps. In the work of ^{Kropp & Meier (2014)}, the pyramid of agile competencies that represents the different levels of competence needed for agility is derived; three levels are identified: Agile values, Management practices, and Engineering practices. They recommend practical approaches to acquire these competencies in the classroom.

The many reasons to teach agile software development in universities are discussed by ^{Hazzan & Dubinsky, (2007)}. The most relevant are: Agility comes from and is used in the industry, it educates for teamwork, deals with human aspects, encourages diversity and supports the learning process. Nowadays, companies increasingly implement agile practices and experience the lack of skilled personnel (^{Kropp & Meier, 2013}). Universities haven’t been able to produce the appropriately skilled professionals (^{Kropp & Meier, 2014}), and a gap exists between what is taught in the classroom and what is required by industry (^{Rodriguez, Soria, & Ocampo, 2015}). This is why courses should be re-designed in order to teach students according to the demands of the software industry (^{Soria, Campo, & Rodríguez, 2012}). In this process, the human side of software development should be taken seriously by academia because it is a field in which students have to make progress to benefit their transition to job market; this includes the organization of a development process, work coordination, and dealing with people with different skills, points of view, and motivations (^{Schroeder, Klarl, Mayer, & Kroiss, 2012}). In the private sector, agility has surpassed the software development activities and is identified as a valuable tool for other fields such as management. Nevertheless, the lack of training is still a limitation that leads to misunderstands and undermines the benefits of agile work (^{Rigby, Sutherland, & Takeuchi, 2016}).

Extreme Programming

Extreme Programming (XP or eXtreme Programming) is one of the most widely used agile methodologies (^{Rizwan, & Qureshi, 2011}). It is an efficient, low risk, flexible, predictable, scientific, and fun method for developing software (^{Beck & Andres, 2005}). For example, XP encourages quick iterations for product delivery consisting of one to two weeks. XP requires the client and the team working together in the same place where the development takes place, and that the programming take place in groups of two people sharing the same computer (pair programming). XP also states that the size of the releases should be small but with a complete sense of value; in addition, it recommends the design of the system to be as simple as possible, the tests written before programming, and developers not to work overtime or take work home with them, and to participate in a symbolic ceremony at the end of each iteration.

Instead of creating long documents with functional requirements, an XP project starts making end users create software “user stories” that describe what new applications need to do. The requirements’ test is done before coding and automated code testing is performed throughout the project. “Refactoring”, frequent-design simplification, and improvement of the code, is also a basic tenet (^{Copeland, 2001}). Devotees say the XP methodology helps generate code faster and with fewer errors.

SCRUM

SCRUM (^{Pressman, 2014}) is an agile methodology that encompasses a series of iterative practices for developers to work as a team, contributing their individual skills to develop quality software. In SCRUM, software is incrementally developed, generating different versions, and at the end of each iteration, a functional end product is delivered. The customer can make changes or continue with development as was originally planned. The Sprint is the fundamental cycle or iteration of the SCRUM process. It is considered that two to four weeks is the most common amount of time for a Sprint.

In SCRUM there are meetings where the feedback process and the collection and clarification of requirements take place. These meetings are the daily Scrum, the sprint planning meeting, the review meeting and the sprint retrospective. The daily Scrum consists of a meeting at the beginning of each work session where each participant discloses what has been completed, what they expect to complete and any impediments found. The Sprint planning meeting is held at the beginning of iterations and consists of two parts: in the first part, the team commits to a set of goals; in the second, the team identifies specific tasks. The Sprint review meeting is where the team presents the completed requirements and the ones yet to be completed. The Sprint retrospective is a meeting that takes place at the end of each Sprint, where the team focuses on the lessons learned during the work accomplished in that iteration.

Pair Programming and Mob Programming

Pair Programming is one of the core practices of XP methodology. In Pair Programming, two people use a single computer to write and test computer programs. Since only one keyboard is available, the programmers change roles often. Globalization has introduced some new ways to do Pair Programming through technological platforms (^{da Silva Estácio & Prikladnicki, 2015}); for example, when a team is scattered across different countries, they can use specialized software to implement the pair programming practice remotely. Another phenomenon studied with regards to Pair Programming is the knowledge transfer between programmers, and at least six different types of transference have been identified (^{Plonka, Sharp, van der Linden, & Dittrich, 2015}). In research, Pair Programming in the academic field has not been addressed as much as in the industry (^{Prabu & Duraisami, 2015}), and there is still a lack of consensus about its best use and its benefits (^{Coman, Robillard, Silliti, & Succi, 2014}).

Mob Programming (^{Zuill, 2014}) is a concept that recently emerged from practice as an evolution of pair programming. It consists of a whole team working on the same project, at the same time/space allocation, and using a single computer for coding. A projector or big screen is needed to amplify the image coming from the computer where the coding is performed. Some practices that have been reported in the implementation of Mob programming are: 1) treating each other with respect, 2) the driver and navigators roles when programming-the driver types the code, the navigators discuss and guide the driver, 3) frequent rotation of drivers, 4) communication is made as a team, and 5) involves periodical reflection on how to improve as a team.

The implementation of agile methodologies in the development of mobile applications

While software development in general can be more efficient with agile methodologies, software development for mobile devices, specifically, is an area that should be obligated to consider using agility because of the possible direct benefits from its implementation. For example, in the literature there are studies that suggest that the development of mobile applications should not be accomplished with a traditional methodology based on documentation or timeconsuming processes, but should pursue the rapid attainment of a functional product considering the features of mobile applications.

(^{Blanco, Camarero, Fumero, Werterski, & Rodríguez, 2009}; ^{Abrahamsson, Ihme, Kolehmainen, Kyllönen, & Salo, 2005}; ^{Gasca Mantilla, Cmargo Ariza, & Medina Delgado, 2014}; ^{Ávila Domenech & Meneses Abad, 2013}) Although agile software development emerged long before the mobile software development with its actual platforms, its principles can be implemented easily in the development of this particular type of software.

Sample

Work was performed separately with two groups of students. Each developed its own version of the same Android application using Java with Eclipse (^{Eclipse, 2015}; ^{Vogel, 2013}). One team with seven students followed the agile methodology called Extreme Programming, and the other, with eight participants used SCRUM. They were university students from two different undergraduate programs related to computer systems that offer programming courses as part of their curricula.

The invitation to take part in a course outside the regular class schedule was extended to programming students who: 1) were close to graduating from undergraduate studies in computer science, 2) had a beginner or intermediate level of programming experience, 3) were able to code using at least one language, preferably Java or C, and 4) had enough knowledge about software design to work on the project.

Once the students responded to the invitation, they answered a questionnaire and a knowledge test of programming; it served for the selection of participants. Both the questionnaire and knowledge test gave an overview of the aptitudes and attitudes of the participants. Selection criteria for this study included good theoretical knowledge, ability to propose a design, and basic to intermediate coding skills. Both teams were randomly chosen from the selected participants. Prior to selection, participants did not know that this study was taking place. They were not given any financial compensation, but they were offered a certificate of participation, provided they had perfect attendance and punctuality.

Instruments

In order to get an approximation to the answers of our research questions, perceptions from participants and researchers were studied. At the end of software development, a five point Likert scale-based questionnaire was answered by the students (see Table 2), in which some statements were presented about team dynamics, methodology used, learning and motivation, and the personal perception of the development and changing requirements. The scale was numerically coded as follows: strongly disagree (0), disagree (1), neutral position (2), agree (3), strongly agree (4). Students were asked to provide responses about the approach as a whole and not only about specific practices performed during the development process.

Table 1 Overview of App Requirements 

Source: Prepared by the authors, 2015.

Table 2 Survey results. 

Source: Prepared by the authors, 2015.

Procedure

The process began with ten hours of training on Java for Android and agile standards. Each team, separately, received specific training on the basics of the methodology they were to use. The sessions were interactive and focused on this project’s needs. After this training process, a second ten-hour period began during which the software was developed following the methodology assigned to each team. Programmers took on their specific roles. A member of the research team took on the role of a client with the teams and remained with the developers at their workplace.

The students listened to the client, who voiced the requirements as previously established by the research team (see Table 1). The goal was the development of a mobile Android application to help exercise mathematical reasoning. To get the final version of the software, each team completed two iterations. In the first iteration, the programmers were faced with a situation which had the requirements of Table 1 with the following exceptions: only two levels would be taken into account: beginner and advanced, they were not asked to include a help function for using the program and were asked that the program had a single screen to interact with the user. In the second iteration, the requirements were intentionally modified: now the app should show a different menu screen; it should also include a help function to guide the user, and it should have an intermediate level to generate arithmetic problems.

Students had to get the user stories and estimate times, discuss with the client the stories that would be implemented in each iteration, divide the stories into specific tasks, assign responsibilities and make adjustments, all the while adhering to the principles of the assigned methodology. XP team worked in pairs the entire time; they coded with a pair programming approach. SCRUM team worked in a self-organized way using an approach inspired by Mob Programming.

At the end of software development, the questionnaire presented in Table 2 was answered by the students. Subsequently, these responses were entered and analyzed in SPSS (^{Field, 2013}), in which a nonparametric Mann-Whitney test (^{Kuanli, Pavur, & Keeling, 2006}) was performed for the difference between the responses of both teams. For this test, the following hypotheses were proposed for the responses to the 18 questions:

H₀: There is no significant difference between the perception of XP team and SCRUM team regarding the ith sentence.

H_a: There is significant difference between the perception of XP team and SCRUM team regarding the ith sentence.

A confidence level of 95 % was used. If the PValue shown in Table 2 was less than .05, H₀ was rejected and a significant difference between the responses of both teams was assumed. Distributions of the scores for both groups were not assumed to be similar; therefore, mean ranks are presented in Table 2. A methodology having higher mean ranks in a statement exhibits a team with an attitude closer to the “strongly agree” value in regards to that sentence.

Unstructured interviews were also conducted with both students and researchers. Finally, the researcher who had adopted the role of client evaluated the final version of the software. Another user who was completely oblivious to the project team performed a usability test to the final version of the teams’ software and shared his views on the app.

Quantitative results

The Mann Whitney test that was run to determine differences in responses between XP and Scrum participants revealed a difference of opinion and feelings when it comes to having to revise work by modifying the requirements.

Scores for question 12 (“When changing the requirements, I felt I had much work to redo”) in Scrum team (mean rank=10.06) were statistically significantly higher than in XP team (mean rank=5.64), U=11.50, z=-2.04, p=.041. Also, scores for question 13 (“I would have rather that the requirements didn’t change”) in Scrum team (mean rank=10.00) were statistically significantly higher than in XP team (mean rank=5.71), U=12.00, z=-2.03, p=.042.

Some other important facts derived from survey results are:

Qualitative results

During interviews, XP team members reported having worked in an agreeable atmosphere and being highly motivated to continue learning about XP. The celebrations held by the team at the end of iterations were very important, for it allowed them to relax and recognize their effort. The practice of not taking work home with them seemed very convenient, attractive and contrasting to the work requirements of many domestic software development companies today. The coding practices were perceived by the team as convenient and relevant to the app development. Pair programming made them feel very confident throughout the process. Nevertheless, they perceived that the different approaches to design and programming of each participant could have been a problem meeting the deadlines.

On the other hand, SCRUM participants mentioned that new aspects of software development were acquired by them in an interactive way. They felt that the project was completed quickly because of their joint participation that allowed them to do several activities simultaneously. SCRUM team also reported the lack of patience of some members, and the different levels of participation among them.

While recognizing that this development was their first encounter with agile methodologies and mobile development, XP and SCRUM members were open to work with these methodologies in the future. They also reported not having troubles when managing the artifacts or activities related to their methodology.

The researchers reported that the implementation of XP and SCRUM managed to timely produce software that met the specified requirements. They realized that participants were involved in their work and that they were committed to meet the specified requirements of the software being developed. The researchers perceived that the SCRUM team was concerned with managing carefully method, tools and artifacts while the XP team had a more relaxed attitude about the process. On the other hand, although both teams assigned the complex programming tasks to their most proficient members, XP participants were more involved in every programming task due to the interaction promoted by the pair programming practice.

The final programs delivered by both teams were approved by the client. In addition, an outsider conducted a usability test to both applications and reported no trouble in using them. He referred that the software developed with XP was intuitive and easy to use, but the app developed with SCRUM was not very user friendly and could have been more intuitive.