Paper Title (use style: paper title)

0 downloads 0 Views 456KB Size Report
On the Difficulties for Students to Adhere to Scrum on Global Software ... The Scrum Master guides the team through the process. .... During the course of the.
On the Difficulties for Students to Adhere to Scrum on Global Software Development Projects: Preliminary Results Christelle Scharff

Samedi Heng

Vidya Kulkarni

Seidenberg School of Computer Science and Information Systems, Pace University New York, NY, USA [email protected]

Louvain School of Management Université catholique de Louvain Louvain-La-Neuve, Belgium [email protected]

Department of Computer Science University of Delhi Delhi, India [email protected]

Abstract—We present the 2011 version of the Global Software Development project that we run annually. Developers were distributed across three countries to develop mobile solutions on the theme of sustainability. They followed the Scrum process and used the IBM Rational Team Concert tool. This study elicits the difficulties encountered by the students new to Scrum in adhering to its discipline. We examined if the causes of these difficulties were due to the fact that developers were distributed across time, distance, and culture. We also studied the impact of the chosen tooling. Keywords-tooling infrastructure; development; process; scrum

global

software

I. INTRODUCTION Global software development is a standard of today’s software industry that comes with its challenges and opportunities [4]. We have been running an annual global software development project (GSD) since 2005 to prepare students to work in distributed settings [3]. In 2009 we switched from web application to mobile applications and from waterfall to Scrum [1]. Scrum emphasizes specific ceremonies, roles, and artifacts. Iterations of fixed durations are called Sprints. The Product Owner is responsible of the requirements. The developers constitute the Scrum Team. The Scrum Master guides the team through the process. During the Sprint Planning, the team commits to complete a certain number of tasks. At the end the Sprint, a Sprint Demo and a Sprint Retrospective take place to demo the software and reflect on the sprint. The team meets in Daily Standup Scrum Meetings. Distributed Scrum has been introduced to accommodate the distributed impact of global software development [2]. From an instructor point of view, the key advantage of using Scrum is the increased visibility in the progress of the students and the demonstration of a software increment very early in the process. In GSD 2011 students distributed across three countries developed mobile solutions targeting the theme of sustainability. Sustainability is defined as “improving the quality of human life while living within the carrying capacity of supporting eco-systems” (International Union for Conservation of Nature, 1993). This study focuses on the difficulties that developers new to Scrum face in adhering to the discipline of Scrum in a distributed context. The paper is organized as follows. Section 2 presents the project setup. Section 3 discusses how Scrum was

implemented on the project. Section 4 summarizes our lessons, and recommendations, and describes our future work. II. PROJECT SETUP In this section, we describe the setup of the 2011 GSD project. We present the goal of this study, the teams, and the mobile applications they developed. Figure 1 summarizes the 2011 setup. Project goal. This paper is motivated by the difficulties we observed in developers to follow Scrum when they are distributed across different countries. This study focuses on developers who are new to Scrum and the tooling infrastructure used to support Scrum. The goal of this paper is to elicit their difficulties based on measurement of their adherence to the framework of Scrum, and evaluate how preparation of the developers and tools influence their difficulties positively or negatively. We also examined if the difficulties were due to the fact that developers were distributed across time, distance, and culture. Theme. The 2011 edition of the project tackled the theme of sustainability. A student researcher was in charge of providing papers, links and videos on the topic of sustainability to help the teams find ideas for their applications. During the development phase, she acted as the content manager and provided content for the apps. Her role was crucial for one of the applications that was relying heavily on contextual and relevant content on dirty / clean and renewable / nonrenewable energy. Timeline. The project spanned 10 weeks including: 1 ½ week for research and idea generation, 1 ½ week for requirements gathering, 6 weeks for development, and one week for final presentations and wrap-up of the project. Figure 2 summarizes the timeline. Teams and roles. Two teams were involved in the 2011 GSD project and they developed two mobile applications on the theme of sustainability. The teams totaled eleven undergraduate and graduate developers distributed in three countries and continents spanning three time zones. Nine students were computer science majors, one student was an information system major, and one student was a psychology major. Specifically, the project involved:  three students from Pace University, USA http://www.pace.edu;



four students from University of Delhi, India http://www.du.ac.in; and  three students from Dakar, Senegal: one was from University Gaston Berger in Saint Louis http://www.ugb.sn, and the other two were from Ecole Superieure Polytechnique in Dakar http://www.esp.sn. The project was not part of the curriculum at the universities involved. Students participated voluntarily to the project and were interested in learning more about Scrum, software engineering practices, tools used in the industry and mobile technology (Android programming in particular), and gaining experience of collaborating with international students. Students mentioned that they were part of this project “to work with teammates from different countries, learn about tools, and know how things work elsewhere”. Students from Senegal were recruited through a group created by one of the instructors on Facebook. Students were developers and testers, except two. One student acted as a researcher and content manager for the mobile applications on the theme of sustainability. Another student acted as an external tester. In addition to their developer roles, students volunteered on roles such as architects, tool guru, graphic artists and marketing managers. The architects were in charge of the overall architecture of the application (e.g., changes, and databases). The tool guru provided guidance on the tools used in the project. The market managers were to write the description of the app, realize videos, provide screenshots, and summarize the work in presentations. These roles were assigned to demonstrate that the development of software requires a multi-disciplinary approach. Some students volunteered to fulfill roles specific to Scrum: Product Owner and Scrum Master. Students’ background. At the beginning of the project, we conducted an online survey that permitted us to gauge the background of the students. Questions included the following sections: university context (e.g., internet access and labs), use of computers and phones, mobile apps consumption, studies, programming skills, and software engineering experience. All students except one had laptops. They were accessing Internet from home (except two students who were accessing Internet from cyber-cafes). Two third of the students took a software engineering class at their university. In general, they were more accustomed with the waterfall process and did not hear about Scrum and Agile before being part of this project. They had intermediate programming knowledge in five programming script / markup language such as Java, C++, PHP, JavaScript, HTML and XML, Java being the language they used the most. Three students had some knowledge in Android. One of the students had already published an app in Google Play. One of the students took a Java ME class. Their main IDE was Eclipse and the DBMS they were familiar with was MySQL. Governance. The project was set up, monitored and supervised by three instructors who are experienced in

students’ global software development projects. Two of the instructors have been collaborating since 2006 in global software development research. Interestingly, the third instructor, who joined the project in 2011, was a student who participated in the first version of the global software development project in 2005. One of the instructors on the project is a certified Scrum Master. During the course of the project, the instructors in the US and India met the local teams once or twice a week. The instructor in Belgium acted as a process coach and provided an assessment of the work of the teams at the end of each sprint. The feedback focused on the process followed and the product developed by the teams. Each team met online once a week with the instructors. A wiki gathering all the documents and links related to the project is available at: http://atlantis.seidenberg.pace.edu/wiki/gsd2011. Software projects. Students had to come up with ideas for the development of mobile solutions targeting sustainability in the context of their countries, which have very different environments and mobile markets. They had to think about mobile solutions such as SMS services, Interactive Voice Response (IVR) systems, and native Android applications. Android phones are not widespread in India and Senegal. However, we decided to go with Android as all students were particularly excited to learn and use this development platform. Voice and SMS solutions were appropriate for all countries. Voice is promising in countries such as India and Senegal where the illiteracy rate is still high. The idea generation phase lasted ½ week. Students conducted personal research on the theme of sustainability, explored a list of papers, links and videos prepared by the researcher on the project, and brainstormed ideas in a shared Google Docs document and using chats. Ideas targeted traffic control, reduction of carbon footprint, smart use of home appliances, providing tips on how to save energy / water, recycling, and access to clean water. Two ideas emerged out of this phase: ClubCar and Green awareness. Two globally distributed teams were formed accordingly to these ideas.  ClubCar. Carpooling has become a necessity in large cities to save gas, reduce traffic, save driving time, and control pollution. Users of ClubCar are riders and/or drivers. ClubCar is a multi-channel application available as an Android application, SMS service, and IVR system. Users can register themselves by SMS, voice or through the Android application. Drivers propose rides and submit their details with dates, times, sources and destinations. Riders can search for available rides. Six students participated in the development of ClubCar. One student focused on the IVR part, two students with experience in PHP worked on the SMS part, and the six students participated in the Android part.  Green Awareness. Green Awareness is an Android application that focuses on clean versus dirty energy, and renewable and non-renewable energy. The application educates users about the consequences of

dirty energy and the clean energy alternatives. It provides fun facts about these specific topics for daily life. Users take a quiz to test how green they became. Five students participated in the development of Green Awareness. Process. Students followed Scrum and Agile. This provided a formal framework of development and ensured regular delivery of increments of the mobile application at the end of each short iteration. This paper only covers the Scrum part of the process. In terms of Agile practices, developers had to use a coding standard, share code in a repository, commit code regularly, and refactor each other’s code. Tools. Table 1 summarizes the tools used on the project categorized as tools for project management, development and communication. Teams used the same technologies (except for SMS and IVR services). We opted for an integrated tooling infrastructure, specifically IBM Rational Team Concert (RTC), that supports the Scrum process and could contain all artifacts developed on the project. RTC was installed in the IBM Academic Skills Cloud. TABLE 1. TOOLS USED IN GSD 2011. Development

Project Management

Communications

RTC for requirements Cacoo (http://cacoo.com) for the design of mobile applications Eclipse, Android SDK and Android plug-in Java and XML for Android development Voxeo for IVR services PHP for SMS services Java.net and Subversion for code version control and repository RTC for bug submissions and tracking Word for testing reports RTC to support Scrum Google Calendar for the timeline of the project Wikis in RTC for team awareness and document repository Google Groups for emails Skype for chats and voice communications Wikis in RTC for team awareness Camstudio for video preparations YouTube for videos

Training. Students went through three weeks of training on Scrum and RTC. They were directed to readings and videos on Agile, Scrum, RTC, and Subversion to get enough understanding of the software engineering process and tools of the project. They had to answer a multiple-choice quiz on Scrum. The quiz was administered in Moodle. They had to go through a RTC tutorial designed by the instructors that targeted specific tasks relevant for the projects (e.g., creation of a Product Backlog, and decomposition of a User Story into tasks). Students learned Android and Voxeo on their own. Data gathering. An entry survey was conducted to understand students’ background and its influence on the project. An exit survey permitted the instructors to comprehend students’ overall experience in the project,

learning experience (technology, tools, Scrum, global software development, etc), difficulties they encountered, and what they liked and disliked. As a tool customizable for Scrum, RTC also permitted the collection of data related to the progress in the project and adherence to Scrum (e.g., business value delivered, and Burndown Chart).

Figure 1. GSD 2011 Setup. III. SCRUM IMPLEMENTATION AND TIMELINE In this section, we describe how we used Scrum in this project. The implementation of Scrum is described in terms of the roles, ceremonies and artifacts of Scrum. The framework was adapted to fit the classroom setting (e.g., impossibility of daily Scrums). Scrum practices. The following principles of Scrum were emphasized: 1) regular communication to share information and increase visibility; 2) collaborative work toward a common and fixed goal; 3) fixed-length iteration where the work is planned, prioritized and committed; 4) team empowerment to reach full potential; and 5) learning and reflecting to improve results and quality with respect to the product delivered and the process followed. Scrum timeline. 1 ½ weeks was dedicated to the capture and elicitation of the User Stories for the mobile solutions to be developed. The development phase comprised three sprints of two weeks. All the students signed a contract stating that they will dedicate twenty hours per sprint on the project. That contract also included information about time to answer emails, content of emails, and collaboration with teammates. Figure 2 depicts the Scrum timeline of the project. Scrum roles. The Scrum Team was composed of the developers in the US, India and Senegal. One of the developers played the role of the Product Owner in addition to the developer role. The Product Owner maintained the requirements, and accepted or rejected the implementation of User Stories at delivery. Another developer played the role of Scrum Master. The Scrum Master made sure the team roles were enforced and the ceremonies took place. The Scrum Master was assisted by the Process Coach (one of the instructors) who provided feedback and guidance.

Burndown charts were automatically generated in RTC and used as a metrics to monitor the team’s progress in terms of remaining work. Tooling to support Scrum. Table II summarizes the use of RTC to support Scrum ceremonies and artifacts. TABLE II. RTC TO SUPPORT SCRUM. Scrum Ceremonies

Scrums Sprint Planning

Figure 2. Timeline. Scrum Ceremonies. The Scrums were recorded online and available in RTC to make them available to the whole distributed team. Developers answered the three traditional questions twice a week: (1) What did you do since our last meeting? (2) What will you do until our next meeting? and (3) What are the impediments that you are facing? A Scrum of Scrum took place once a week online in Skype with all the team members and instructors present. During the meeting, each developer answered the three traditional questions. The rest of the time was used to discuss specific problems. When in the planning phase, the meeting was also used for the Sprint Planning. The online meeting lasted one to two hours for each team. The Sprint Planning meetings took place during the online meeting. Developers always used additional time to finalize the planning after the meeting. The Sprint Goal was recorded in RTC to increase commitment. The Sprint Demos and the Sprint Retrospectives occurred during the weekly online meeting. The developers were asked to prepare videos of their software before the meetings and make them available online with a link in RTC. They were also asked to post their Sprint Retrospectives and answer the following questions: 1)What worked well during the sprint?; 2) What could have worked better during the sprint?; and 3) What success / problems were due to Scrum? The Sprint Retrospective was shared in RTC. The Process Coach added a summary of the achievements of the developers: committed versus implemented stories, planned and actual velocity. Scrum Artifacts. The Product Backlogs were saved and maintained in RTC. User Stories followed the patterns: “As a I should be able to so that ”. We had 25 user stories for the carpooling application which include 16 high, 8 medium and 1 low priority and 937 user story points. The Green Awareness application comprised 27 user stories including 18 high and 9 medium priority stories, and 1632 user story points. During the Sprint Planning, the User Stories were decomposed into estimated tasks and added to the Sprint Backlogs in RTC.

Scrum Artifacts

Spring Retrospecti ve Sprint Demo Product Backlog Sprint Backlog Burndown Chart

Written on the dedicated wiki page entitled “Scrums” available in RTC Sprint Goal written on the dedicated wiki page entitled “Sprint Goal” available in RTC Dedicated Sprint Plan available in RTC Written on the dedicated wiki page entitled “Sprint Retrospective” available in RTC Written on the dedicated wiki page entitled “Demo” available in RTC Product Backlog as a dedicated plan in RTC Spring Backlog as a dedicated plan in RTC Burndown Chart automatically generated in RTC dashboard

IV. LESSONS, RECOMMENDATIONS AND FUTURE WORK This section presents our project outcomes and answers our research questions. It also presents recommendations to integrate Scrum in students’ global software development projects and our future work. Scrum ceremonies. Table III summarizes the number of Scrums, Sprint Planning meetings, Sprint Retrospectives and Sprint Demos that effectively occurred on schedule for each team. The total number of each of the ceremonies that should have taken place is also provided for comparison. Scrum is a demanding process for developers who have to develop, follow the ceremonies, and maintain the artifacts. Scrum is equally demanding for instructors who need to be vigilant at all times, the cycle of the work being short (bound with the length of a sprint) and the pace of work being sustained. The team that conducted more of the ceremonies developed a better solution in terms of functional and non-functional user stories implemented and accepted by the product owner. Difficulties met by the students. Table IV describes the difficulties encountered by the students and if they are due to the fact that developers were distributed or to confusions in using RTC. Distributed developers and the tool used on the project had impact on adherence to Scrum. TABLE III. SUMMARY OF THE SCRUM CEREMONIES. (in #Sprint #Sprint #Scrums wiki) Plannings Retrospectives Team 2/3 33 / 48 3/3 1 Team 0/3 24 / 60 0/3 2

#Sprint Demos

#Online Meetings

3/ 3

6/6

2/3

6/6

Developers’ testimonials. In the exit survey, one of the developers reported that he “tried [his] best to use Scrum, but it was quite cumbersome to follow and [to] update RTC every now and then“. While the teams faced numerous difficulties to adhere to Scrum, they felt they learned a lot about this type of process and had a good experience. “The product was not completely ready so honestly I am not satisfied. But we have learned many methods and techniques to develop software. So overall it was a good experience.”

TABLE V. RECOMMENDATION TO INTEGRATE SCRUM IN STUDENTS’ GSD PROJECTS. Scrum Roles

Scrum Team

TABLE IV. DIFFICULTIES OF THE TEAMS AND RELATION TO THE DISTRIBUTION OF THE TEAMS. Difficulties Scrum Roles

Scrum Team Product Owner Scrum Master

Scrum Ceremonies

Scrums

Sprint Planning

Spring Retrospective Sprint Demo

Scrum Artifacts

Product Backlog

Sprint Backlog Burndown Chart

Unexpected or expected absences of developers during several days. Difficulties to dissociate the roles of developer and product owner. Difficulties to dissociate the roles of developer and Scrum Master. No regularity in doing the Scrums. Three Scrum questions not answered. Sprint planning done late. Notion of commitment not understood to its full meaning. No preparation of the retrospective. No preparation of the sprint demo (e.g., missing video and software version). Difficulty in elicitating the requirements as user stories. Difficulties to maintain the product backlog (e.g., changes) Difficulties to decompose user stories into tasks. The burndown chart is not used as an instrument to monitor the progress of the team by the team itself.

Due to GSD In part No No

Due to RTC No No

Scrum Master

No

In part No No

Product Owner

Scrum Ceremonies

Scrums

No

In part In No part No

Sprint Planning

In part No In part No

No

No

In part No In part In part No

No

Recommendations. Table V presents our recommendation concerning the use of Scrum in students’ global software development projects. Future work. In GSD 2012 we will take into account our lessons learned and recommendations. We plan to examine what development process is most suitable for developing mobile apps while learning about process, technology and specific tooling. We will set up a controlled experiment where some teams will use Scrum and some teams will use a waterfall process with iteration. We will also gauge the stress level of the teams on the project for comparison.

Sprint Retrospective Sprint Backlog Burndown Chart

 Readings are not enough to understand Scrum before the project. Provide formal training to all students involved in the project using the XP Planning Game [5] for example. The game should be experienced co-located and distributed for more impact. Discussions on Scrum can also be organized.  Synchronous discussions, justification and experimentation with the tooling infrastructure are necessary. Mastering the tools is crucial before beginning the project.  Choose a Product Owner external to the Scrum Team to provide a real Scrum experience.  Choose a Scrum Master external to the Scrum Team to provide a real Scrum experience.  Demonstrate the importance of Scrums for the health of the project. Have specific examples showing what happens if Scrums are not done.  Sprint Planning should be done on day one of the Sprint. Plan a complete meeting including the instructors to have the Sprint Planning finalized.  Explain the notion of commitment and its value.  Synchronous preparation of the sprint retrospective is necessary to make sure it is done.  Sprint Backlog should be prepared by the team synchronously.  Burndown Chart should be used as a health check by the team.

ACKNOWLEDGMENT This work was supported by an IBM Smarter Cities Innovation Award and a Pace University Thinkfinity grant. REFERENCES [1] Deemer, P. and Benefield. G. The Scrum Primer: An Introduction to Agile Project Management with Scrum. http://www.goodagile.com/scrumprimer/scrumprimer.pdf. [2] Deemer, P., The Distributed Scrum Primer. http://www.goodagile.com. [3] Gotel, O. Scharff, C. and Kulkarni, V. Mixing Continents, Competences and Roles: Five Years of Lessons for Software Engineering Education, Special Issue of Management of Global Software Development: Opportunities, Challenges and Lessons Learned, The Institution of Engineering and Technology (IET) (to appear). [4] Herbsleb, J.D. “Global Software Engineering: The Future of Socio-technical Coordination”. Proc. ICSE’07, The Future of Software Engineering (FASE), Minneapolis, USA, 2007. [5] Peters, V. and Van Cauwenberghe, P. The XP Game. http://www.xp.be/xpgame.html.