Communication Practices in a Distributed Scrum Project


While global software development (GSD) projects face cultural and time differences, the biggest challenge is communication. We studied a distributed student project with an industrial customer. The project lasted 3 months, involved 25 participants, and was distributed between the University of Victoria, Canada and Aalto University, Finland. We analyzed email communication, version control system (VCS) data, and surveys on satisfaction. Our aim was to find out whether reflecting on communication affected it, if standups influenced when developers committed to the VCS repository, and if leaders emerged in the three distributed Scrum teams. Initially students sent on average 21 emails per day. With the reduction to 16 emails, satisfaction with communication increased. By comparing Scrum standup times and VCS activity we found that the live communication of standups activated people to work on the project. Out of the three teams, one had an emergent communication facilitator. INTRODUCTION Global software development (GSD), meaning projects using teams in several locations, are increasingly common. They allow geographical distances to be ignored and provide access to more talented and skilled resources [Herbsleb, 2007]. Modern software projects are often multi-disciplinary, which makes it hard to find experts with required skills within one location [Cavrak et al., 2012]. In addition, business globalization and market demand pushes companies to adopt global software development practices, as they are forced to improve time-tomarket by adopting round-the-clock development [Herbsleb and Moitra, 2001]. Agile methods are a collection of related iterative and incremental software development processes. Agile methods were originally designed to improve communication by emphasizing face-to-face communication [Schwaber and Beedle, 2002]. This means agile methods have traditionally been applied in a localised context. Scrum is one of these methods which has its focus on day-today project management practises [Schwaber and Beedle, 2002]. A global aspect in a project decreases the amount of face-to-face communication making communication more complicated [Monasor et al., 2010]. The overall amount of communication and collaboration will decline as good communication gets harder to achieve because of a geographical separation [Herbsleb, 2007]. The lack of personal contact impedes the ability to build understanding and trust among parties [Jarvenpaa and Leidner, 1998]. There is ongoing research of ways to mitigate these problems in GSD, and agile methods adapted to GSD are rising as a candidate solution [Paasivaara et al., 2013]. It is necessary to substitute live communication with technical aids such as videoconferencing, email, and chat, which helps to maintain especially informal communication. The interest in GSD teaching and education will increase, as it is becoming a common practice in the software industry and therefore there is a growing demand for knowledge [Monasor et al., 2010]. Cavrak et al. [2012] mention that GSD projects face not only technical problems, but also difficulties in handling both cultural and language differences. They also show that the lack of trust and cooperation can be a consequence of cultural misunderstanding, which is usually caused by weak communication [Cavrak et al., 2012]. For this reason, it is highly valuable to teach working in a distributed environment and to encourage students to cooperate with people from different cultures, and at the same time prepare students to work in a global environment after graduation. In this research, we investigate communication practices and perceived satisfaction in an industrial student project arranged in cooperation with two universities. We study how students changed used communication practices based on their reflection in a project where all team members were not able to meet each other faceto-face. In addition, we inspected what kind of effect standups (short Scrum mandated status meetings) had on the commit activity of the students, and whether leaders emerged in Scrum teams. Based on the results, we have three proposals for future GSD projects. The first is that developers are made aware of the problems involved in sending too many emails. The second is to emphasize the importance of standup meetings, not only as a means of sharing information, but also as a way of increasing motivation to work on a project when there are other projects going on at the same time. The third is to use communication visualization and metrics as a tool in retrospectives so that teams are more aware of their communication practices and can use the information as a base for their potential process changes. The paper is structured as follows. We start with the background of the research including explanations of GSD and Scrum. Then the section Research Design shortly describes the course, what data we inspected, ar X iv :1 30 8. 22 60 v1 [ cs .S E ] 9 A ug 2 01 3 PROCEEDINGS, COINs 2013 and clarifies what kind of data we had and how it was analyzed. After going through results, in Discussion we summarize our findings and discuss a little about possible limitations of the research. Finally we conclude our findings and propose a direction for future work. BACKGROUND In this section we describe GSD in general and how agile methods can be applied in GSD. We pay particular attention to the agile method called Scrum and how it can be applied in GSD, as Scrum was used in the case project. As a comparison with our case study we present a brief review on how GSD skills have been taught in other courses. Agile methods in global software development Agile software development has its foundation in enabling change [Dingsøyr et al., 2010]. The ability to cope with change hinges on the internal and external collaboration and communication of development teams. Delivering working software in short iterations, and integrating and testing the product continuously are important practices in agile development [Highsmith and Cockburn, 2001]. These practices aim to provide continuous feedback and transparency, which improves control and the ability to cope with change. Global software development is a well established trend, which aims to gain benefits by distributing development effort across multiple sites. The main reasons to make development global are expected cost savings as well as the need for extra people and knowledge [Smite and Wohlin, 2011]. The benefits are however weighted against challenges, which in GSD are due to the difficulty of arranging control over a distance [Herbsleb, 2007]. A centralized development setting allows frequent interactions and eases creating a shared understanding, but a distributed setting lacks these benefits. The main challenges of GSD are less effective communication, which results in a lack of understanding and awareness of what people at other sites are doing, and incompatibilities in ways of working and the use of tools [Herbsleb, 2007]. Agile and GSD seem to have a very different basis, as agile emphasizes close collaboration, whereas in GSD collaboration is hampered by the necessity to work across organizational and geographical boundaries. Nevertheless, agile practices are used in GSD, and a potential is seen for combining the benefits of both disciplines [Hanssen et al., 2011]. As these two disciplines have different fundamentals, it is clear that problems arise, with communication being the foremost [Paasivaara and Lassenius, 2006]. Agile methods emphasize frequent face-to-face communication, which may be difficult to emulate between remote sites. However, striving to satisfy this requirement may also be seen as a strength as enabling frequent communication is a recommended practice in GSD [Smite and Wohlin, 2011]. Other challenges are the requirement for short iterations and frequent integration, but when implemented properly agile methods provide transparency and control [Paasivaara and Lassenius, 2006]. Agile methods are often seen as sets of simple rules, which should be used as a basis for an organization to learn and build their own optimal way of working [Highsmith and Cockburn, 2001]. This implies that it is meaningful to apply agile methods partially, even if the environment is not on their home ground, such as in a distributed project. Selectively applying suitable agile practices has proven to benefit distributed projects [Holmstrom et al., 2006]. Scrum in GSD Scrum is an agile software development method, which has its focus on day-to-day project management practices. The main elements of Scrum are splitting work into prioritized increments, delivering working increments of software in time boxed sprints, daily standup meetings to keep everyone on track, and enabling teams to self-organize [Schwaber and Beedle, 2002]. Work is divided in to 2-4 week sprints. The sprints start with a planning meeting to create the initial scope. At the end of the sprint there is a demo where the work results are demonstrated to stakeholders. The ending of the sprint also includes a retrospective session in which the team can adjust the process to solve problems they have observed. Scrum emphasizes empirical control in order to react to change [Schwaber and Beedle, 2002]. Empirical control implies frequent communication which is manifested in Scrum as standup meetings and a preference for face-to-face communication. Hossain et al. [2009] found in their systematic review of literature that communication issues are major challenges when using Scrum in distributed development. The possible communication challenges and misunderstandings could be partially avoided by providing synchronous communication. This can be arranged, for example, using synchronized working hours or generating Scrum teams that are not dependent on offshore teams. Team members’ cultural background has been shown to have an impact on collaboration and communication. Furthermore, coordination may also arise as a challenge if Scrum teams do not have proper facilities to support the needs of daily communication. In addition to these, offshore team members might feel discouraged to voice their opinion aloud, which might cause confusion and misunderstanding among people on other site, but is actually caused by cultural and linguistic disparity. [Hossain et al., 2009] GSD courses During the last decade, the amount of publications related to teaching GSD has increased considerably, which indicates emergent interest in the subject [Monasor et al., 2010]. Swigger et al. [2012] looked at when distributed student teams work and found that students often work outside the normal workday. Hossain et al. PROCEEDINGS, COINs 2013 [2009] found that there is a growing trend of papers covering the subject of using Scrum practices in GSD context. Still most reported GSD courses have used the waterfall process instead of agile methods, which reflects the contradiction between education and industry [Paasivaara et al., 2013]. As a clear link to the success of Scrum practices in GSD is missing, it is important to put more effort on studying this area in practice. Agile methods have a clear place in GSD and their impact could be emphasized more on GSD courses. RESEARCH DESIGN In this section, we first describe our case study project. We then present our research questions and the related hypothesis. Finally we list the collected data and briefly explain how it was analyzed. Course description The research was based on a case study following Yin [1994]. The case study was arranged as a collaborative course between the University of Victoria, Canada and Aalto University, Finland in spring 2012. The course aimed to teach students important GSD skills by constructing a real software development environment using agile methodologies [Paasivaara et al., 2013]. To accomplish this, the course coordinators had procured a real customer, for whom the software was developed. There were some minor differences in the course settings at both locations. The Finns started their course in September 2011, as a part of a Software Development Project course. During the fall, students got familiar with the Scrum framework and started using it as a development process. They were instructed to use distributed Scrum when the Canadian team joined them in January 2012. The students worked together until the course ended at the beginning of April, even though the Finnish course officially ended at the end of February. After the Canadians joined on the course, all students excluding a Scrum Master were divided in to three teams, so that each team consisted of 7 to 8 students and contained students from both countries. The core idea was to implement a more accurate Scrum environment in comparison to earlier research groups such as Scharff et al. [2012]. The Scrum Master (also the first author) was shared between the three teams because he was the only one with previous experience with the source code and had industry experience working in that role. This enabled all teams to tap into his knowledge as needed. The Canadian instructor had selected a student per team for a role that was described before the project started as a team leader. Because there are no leaders in Scrum, it was emphasized to all students that the role is to serve as the contact person between the Canadian instructor and the team so that the Canadian instructor has to only deal with one point of contact. However, we can not rule out the potential effect this had on the students. The cultural background of the students in the Finnish location was uniform as all the students were Finnish. However, in Canada many students had grown up elsewhere. In addition to Canadians, the course at the University of Victoria had students from other countries, for example Iran and China. Furthermore, English was the language of communication, which was not a native language for twelve (vs. 11 natives) of the students. In both locations the students were expected to spend about 10 to 12 hours per week on the project. For Finns this was their full amount of hours for the project but for the Canadians the course also included lectures, reading and blogging. The experience background in programming for the students varied from taking a single basic programming course to having a decade worth of experience. When creating the teams, the students and instructors aimed to create three teams that were as equal in skill and experience as possible. Students used both synchronous and asynchronous communication. Google+ Hangout was primarily used for videoconferencing in Scrum meetings. Skype was also used to for example reach the product owner. In addition, email was used for a project or team related asynchronous communication, and internet relay chat (IRC) for instant messaging inside teams. IRC was a familiar tool to Finns but Canadians had less previous experience with it. The course provided each team and the whole project mailing lists that everyone was allowed and encouraged to use in order to reach a suitable audience. For our research and educational purposes there were mandatory practices. The sprints were of equal length and lasted two weeks. Having the sprints of equal length makes it easier for us to compare the sprints for research purposes, and for education purposes enables learning the Scrum practices by repetition. The students were required to have two Scrum standup meetings per week. Normally the meeting happens daily in a Scrum team working full time in an industrial setting. Because the students only worked part time, having two standups per week allowed roughly the same amount of work to happen between the standups. The students were allowed to agree among themselves for the time of the standups because neither location had time dedicated in the course schedule that could be used for that purpose. At the beginning of the project we selected Google+ Hangout as the videoconferencing tool because it allowed the needed amount of simultaneous connections and was available for free on all operating systems. During the project Google also released mobile applications allowing students to connect to the standups from the road. The version control system used in the project was Git. Research questions The goal of our research was to find out whether reflecting on communication had an effect on the actual communication, if standups influenced the time when developers made commits to the VCS repository, and if leaders would emerge in the teams. PROCEEDINGS, COINs 2013 Does reflecting on communication affect the actual practices of communication? In Scrum, teams should be self-organized and thus decide the best practices by themselves [Schwaber and Beedle, 2002]. Based on this we hypothesized that teams would try to adjust used communication practices based on the reflection of previously used practices. Teams were asked to keep a retrospective after each sprint in which team members went through the current sprint and discussed problems they had observed. The goal was to identify improvements and implement them in the next sprint. Hence, it would be logical to see communication practices change whenever people were not satisfied with the way they are used. Do standups activate developers to do work? The students did not have a set schedule to work on the project and from previous work we know that students work irregular hours [Swigger et al., 2012]. Our hypothesis is that the live communication of standups activates students to commit more if there is a standup near. In the standup you need to have answer the question: “What have you done since the last standup?” The social pressure and the fact that you must spend at least the standup thinking about the project should mean that students commit more near standups. Do leaders emerge in the distributed Scrum teams? There are no designated leaders in Scrum teams. We wanted to study the communication of the teams to see if developers emerged that could be characterized as dominant communicators due to their communication patterns. We know that leaders can have a different ratio on how many messages they send and receive [Gloor et al., 2003] and we can use that knowledge to see if such patterns emerge in this context. Collected data Data was collected using techniques listed in table 1 [Paasivaara et al., 2013]. The most important data sources were sprint surveys, sent and received email messages, and version control data. At the end of every sprint, a web-based sprint survey was sent to all 25 students, and 19-22 submitted surveys for a response rate between 76% and 88%. The surveys contained 23 stationary questions with a total of 101 sub-questions emphasizing the perceived satisfaction, trust, used tools, and usefulness of Scrum and communication practices. The surveys were conducted for our scientific purposes and are not a mandated part of the Scrum process but they do also force the developers to reflect on the experiences from the current sprint. The emails were collected by having the students submit the email headers from all the course related messages to the course personnel at the end of the project. This way the students could be confident that the bodies of messages were never read by the teaching personnel. All students were assigned random numeric user identifiers so in this paper u10 means developer 10. The three teams were assigned similar random numeric identifier 0, 1, and 2. Data analysis Data analysis was primarily conducted using quantitative analysis supported with qualitative observation. To analyze the data centrally all the data was collected to one relational database. The survey data was primarily analyzed using R programming language, which produced diagrams that we used for qualitative analysis of how students’ opinion changed during sprints. The same method was used for VCS data analysis. For communication, we studied the amount of sent and received emails per a person in order to analyze students’ activity and how communication practices changed during sprints. RESULTS In this section, we present the results of our data analysis. This section is divided into subsections for each research question. A central part are the figures that resulted from our analysis. Communication and Satisfaction

Extracted Key Phrases

7 Figures and Tables

Cite this paper

@article{Rty2013CommunicationPI, title={Communication Practices in a Distributed Scrum Project}, author={Petteri R{\"a}ty and Benjamin Behm and Kim-Karol Dikert and Maria Paasivaara and Casper Lassenius and Daniela E. Damian}, journal={CoRR}, year={2013}, volume={abs/1308.2260} }