Communication in Agile Global Software Development

7 downloads 166346 Views 211KB Size Report
Garbajosa J., Yagüe A., Gonzalez E. (2014) Communication in Agile Global ..... Tools to support bi-directional face-to-face and one-to-many communication.
Cite this paper as: Garbajosa J., Yagüe A., Gonzalez E. (2014) Communication in Agile Global Software Development: An Exploratory Study. In: Meersman R. et al. (eds) On the Move to Meaningful Internet Systems: OTM 2014 Workshops. OTM 2014. Lecture Notes in Computer Science, vol 8842. Springer, Berlin, Heidelberg  

Communication in Agile Global Software Development: An Exploratory Study Juan Garbajosa1 , Agustin Yag¨ ue1 , Eloy Gonzalez2 1

Technical University of Madrid (UPM), CITSEM, E.T.S.I Sistemas Inform´ aticos, Madrid, Spain [email protected], [email protected] 2 Indra Software Labs, Madrid, Spain [email protected]

Abstract. Agile Global Software Development is gaining relevance and importance. While communication is key for exchanging information between team members, multi-site software development introduces additional obstacles and delays. This paper reports an exploratory study on the impact of infrastructure on communication. Although this topic has been a subject of interest many issues remain unaddressed. In this paper we address both team member communication and the combination of project and product development. One of the main conclusions is that communication can be improved if tool infrastructure combine different levels of information (i.e. team members, project status and product status). The use of simple tools, such as Vsee in SmartBoards is useful for reducing distance between sites. Dependency on bandwidth is not a new issue but is still relevant. Keywords: Global Distributed Software Development, Agile, Exploratory research, Tools, Technologies, Infrastructure

1

Introduction

Global software development (GSD) is gaining relevance and importance. 3 As communication is key for exchanging information between team members, multisite software development introduces additional obstacles and delays [2]. None of these obstacles are new, with a number of them having been reported in 2003 [10]; however, recent publications and reviews show that they are still serious concerns [2,28]. Communication is even more critical in the case of Agile Global Software Development (AGSD) in which communication plays a primary role: “Business people and developers must work together daily throughout the project”[4]. Communication problems in AGSD have also been broadly addressed [13,1,28], and these have shown that distributed teams strongly depend on tools for communication and, on agile teams to a larger extent [1,16,28]. Though the tool technology to support efficient communication in AGSD has 3

Work partially sponsored by MICINN, Spain. Ref IPT-430000-2010-38.

been addressed, it is still an open issue [1,2,16,28]. This paper reports an exploratory study on the impact of different communication elements, including tools, obtained both from monitoring and the perceptions of team members in three industrial distributed projects. Observations were obtained from three perspectives: communication among team members, communication of the development process status, and communication of the product progress status. The rest of this paper is structured as follows. Section 2 presents a short background about communication and supportive tools in AGSD. Section 3 describes the research methodology. Section 4 presents the findings on the impact of different practices and tools. Finally, Section 5 summarizes the main conclusions obtained from this research.

2

Background

Communication is the core function of cooperation to exchange information between team members [1]. When development is distributed, dispersed members tend to feel a lack of access to all the information, while on-site members have access [14]. Korkala and Maurer later reported a ”lack of involvement, lack of shared understanding, outdated information, restricted access to information and finally scattered information” [16]. Cultural differences also matter [1]. Communication has been classified as spontaneous or informal versus formal, or synchronous versus asynchronous [1]. Communication has also been classified according to whether it is performed face-to-face or using technology (e.g. electronic media, or telephone). Tools and technology have been regarded as an effective support for communication in distributed teams. Sinha et al. reported on the great dependency that geographically distributed teams have to (communication) tools[29]. However, Johnston et al. highlighted that Information and Communication Technologies (ICT) restricts communication because it is less rich than face-to-face communication [14]. Centralized infrastructures can be useful in AGSD frameworks to share information as a way to facilitate team communication [15]. To overcome the identified challenges, Herbsleb stated that GSD should combine different communication media, such as telephone, teleconferences, email or instant messaging [10]. Niinimaki et al. [22] reviewed how communication problems had been addressed in global organizations using different media and systems, and studies on the impact of media selection [7,11,15,22,25] on AGSD have been performed. The impact of cloud infrastructures in agile distributed teams has also been reported [24]. Studies published recently show that current tool support for communication in AGSD is far from satisfactory[1,16,2]. Therefore, more information is required to understand the root causes of the reported problems.

3

Research methodology

3.1

Research environment

This research was performed in Smart Software Factories (SSF), an experimental research facility[19]. SSF is a software engineering research and education laboratory located initially at the University of Helsinki (UH), then at the Technical University of Madrid (UPM) and Indra Software Labs (ISL), a subsidiary of Indra, a global engineering company.4 Each SSF was equipped with video cameras to provide a general view of the room, ambient microphonesand a Smart Board 685i, which is an electronic whiteboard to support inter-site interaction. Each computer had a camera and a microphone. Software development and management infrastructure was centralized and consisting of Redmine, Hudson, Sonar, and SVN tools and plugins. 5 All the SSF laboratories had basically the same infrastructure in terms of computers, video, audio and recording equipment.

3.2

Research design

This research was designed following the guidelines proposed by Runeson and H¨ ost for conducting case studies [26] and comprised five main steps: study design, preparation for data collection, collecting evidence, data analysis and reporting. In the study design, we used an exploratory and qualitative research method following Cresswells recommendations and suggestions [6] due to the nature of the research topic and the research objectives. The research question was: “How does communication infrastructure impact information sharing in Agile Global Software Development?” This research question addressed the lack of communication perceived by dispersed members. Observations were obtained from three perspectives: team member communication, communication of the development process and communication of the product status. Data were collected and classified, following Lethbridge et al’s. [18] approach, into direct, indirect and third degree and according to a number of measures that were defined. The objective of the measures was analyse the impact of SSF infrastructure on communication, and to identify the advantages, disadvantages and challenges. To perform the exploration, four projects of different nature were selected. These projects are described in section 4.1 and they were real distributed agile projects owned by the industrial partner ISL. In the next step, preparation for data collection, the procedures and protocols for data collection were defined. Classification surveys and focus groups [6,26] were used for direct data collection; indirect data were collected from measures obtained from raw data produced by the software development and management 4

5

UH - http://www.helsinki.fi/university/, UPM - http://www.upm.es/internacional, ISL -http://www.indracompany.com/en http://www.redmine.org/, http://hudson-ci.org, http://www.sonarqube.org/, https://subversion.apache.org/

infrastructure; and third degree data consisted of studying the project outputs and generated documentation (including meeting minutes). Surveys were defined following the guidelines provided in [8,26] and were structured into six sections to cover the three perspectives mentioned above. Survey questions, identified from the literature, related to software measurement in agile processes [9,28]. Interviews were conducted through focus group following the guidelines provided by Krueger and Casey’s [17]. Briefly, focus groups were questioned about personal perceptions of the impact of communication tools. For indirect data collection, raw data measures were obtained by reviewing the literature on ASD and AGSD. A set of 41 measures were identified, by considering the research question, the three monitoring perspectives (team communication, development process status and product status) and the reported measures found in the literature. This method is similar to how GQM [3] is applied. Each measure was documented specifying its nature, description, value range, usefulness and how and when it should be collected. Third-degree data were obtained by researchers studying outputs produced by the project while the project was running; this process extracted measures that could not be obtained directly such as those obtained from sessions that were recorded, such as the duration or the number of participants of each meeting.

Project name Optimeter I Optimeter II Research4us Habeo Ideam Table 1.

Language Factories Team size Size Java UPM and ISL 9 6589 LOC Java UPM, ISL and UH 21 9652 LOC PHP UPM and ISL 10 56139 LOC PHP UPM and ISL 15 37034 LOC Team and software size of the projects explored

Collecting evidence was the third step. The projects used to get evidence are described in Section 4.1. At least two SSF teams participated in each project. Following the classification provided in [26], observations were performed by external observers with a low interaction with the development team. Meetings were recorded for both audio and video and later transcribed. Codes were defined using an open code method [17], and each statement was coded and classified separately by two researchers. Confidentiality and anonymity agreements were signed by researchers and team members. Focus groups were used to collect data following the guidelines provided by Krueger and Casey’s [17]. Two observation and analysis levels were implemented: one at an iteration level so that every two weeks, measures were collected and analysed, and results reported; the second at the end of the project. Software development and management infrastructure were used to collect the indirect evidence. Direct evidence was collected from surveys 6 , focus groups. Occasionally, third degree evidence from video observations. 6

Electronic surveys were created at https://www.surveymonkey.com/

The data were analysed following quantitative and qualitative methods depending on their nature, but seeking qualitative outputs. Some of these measures were non-subjective (e. g. meeting duration), and some subjective (e. g. meeting satisfaction). Data analysis was performed following the guidelines suggested by [26], and by Fink et al. [8] for all the subjective measures. Finally, reports were produced to communicate the findings of the research. Validity has been approached following [31]. Construct validity was achieved using several multiple data sources, documenting the research process, searching a of chain evidence, discussing conclusions and introducing triangulation where it was required. Several projects were performed with different teams, so that many of the effects could be verified. Concerning external validity, the limitation of having the same context applies. It should noticed that according to[23] interpretive case studies do not seek generalizability.

4

Measures and Results Obtained

This section briefly describes the projects that were used for exploration, then a subset of measures are presented and, finally, the most relevant findings are enumerated and justified. 4.1

Project decriptions

Four projects were used to obtain evidence. The column “Factories” in Table1 shows the acronym of the SSF participating in each project. The duration of each project was seven weeks with two-week iterations; all projects were managed with Scrum [27]. Engineers participating in these development projects had at least two years of software development experience. Senior engineers performed Scrum master and product owner roles. Table 1 shows the indicators of the projects. The first and second project, Optimeter I and II, were traversal activities to two European ITEA2 projects: IMPONET7 (127 man years) and NEMO&CODED8 (112 man years), and a third Spanish project called ENERGOS9 (budget 24.3 million euros); these three projects focused on supporting power smart grids. Both Optimeters benchmarked massive data distributed processing and storage using Apache Hadoop, NoSQL databases to build a system to optimize searching and management of massive data in the Smart Grid domain. The Optimeter II project involved three sites with different time zones (one hour difference) and, teams with different cultures. The third project was Research4us. This was a customized wiki system based on Dokuwiki10 to add specific functionalities for researchers and was a typical PHP project with MySQL running on an Apache 7

8

9 10

IMPONET Intelligent Monitoring of Power NETworks http://www.itea2.org/project/index/view?project=10032. NEMO NEtworked MOnitoring & COntrol, Diagnostic for Electrical Distribution http://www.itea2.org/project/index/view?project=1131. http://innovationenergy.org/energos/ https://www.dokuwiki.org/dokuwiki

2 server. Finally, Habeo Ideam, the fourth project, consisted of implementing PHP extensions to a Joomla Content Management System (CMS)11 to manage innovative ideas. 4.2

Measures

Table 2 shows a subset of the measures collected, classified by type (direct, indirect and third degree) and perspective (communication among team members, and related to process and, product status). Columns two to four represent the dimensions covered by this research. Rows are grouped by the method applied to collect data. The name of the measure and the where it was collected is in each cell. PerspectiveTeam communication / Type Meet sat level (Prj) Comm channels rate(Prj) comm channels Direct usefl(Prj)

Indirect

Development Process status communication Comm mech sat (Prj) comm mech rate(Prj)

Product status communication Comm mech rate(Prj) comm mech usefl(Prj)

comm mech usefl(Prj) Nof art created (Itr) Nof SVN revisions (Prj) Nof Wiki inputs (Prj) Nof builds (Prj) Nof News (Prj) Nof documents (Project)

Nof meetings: daily, sprint planning, sprint reviews, retrosp.(Itr) (each) meet time Third length(Itr) degree (each) meet part (Itr) Table 2. Subset of measures collected in the four projects. Nof stands for number of, comm communication, mech mechanisms, prj project, itr iteration, sat satisfaction, meet meeting, ret retrospective, part part, rate use rate, usefl usefulness, art artefact

Team communication perspective. This perspective focused on the analysis of the impact of SSF infrastructures to support communication among team members within the scope of AGSD. Two types of measures were collected: direct and third degree. Direct measures were collected by using the surveys built to capture perceptions of the team about the usefulness of tools, the rate of use and meeting satisfaction. The objective of these measures was to understand how each media type impacted the communication of teams. Third degree measures were collected by researchers after analysing the information recorded and stored during the project. Measures included attendees, time duration or 11

http://www.joomla.org/

meeting frequencies. Video-conferencing systems, white boards, meeting rooms, emails and instant messaging systems were some of the communication media analysed. The literature used to identify measures was e.g. [16,25,11]. Development process perspective status. This perspective focused on the analysis of the impact of SSF infrastructures available to support the communication of the development process status to the team. Two types of measures were collected: direct and indirect. Surveys were used to collect direct measures to get perceptions about the usefulness of software development and management infrastructure. Indirect measures were extracted from the software development and management infrastructure to get evidence of the amount of shared information in the project and the use of tools. Several references were used to identify project measurement status [30,9] Product perspective status. This perspective focused on the analysis of the impact of SSF infrastructures to communicate the status of the project by using software product status indicators, mainly quality characteristics. Two types of measures were collected: direct and indirect. Direct measures were obtained from surveys focussed on how the product status and evolution of the product was shared. Indirect measures, extracted from the software development and management infrastructure, provided quantitative evidence about the status and quality of the product. McCall’s model [20], Boehm’s [5] and international standards as ISO 25000 [12] were used for product measurement. 4.3

Findings

1. Tools to support bi-directional face-to-face and one-to-many communication are critical to facilitate team building in the case of GSD. Tools such as VSee and Skype with open sessions while teams were working helped teams to see and talk to each other as if they were in the same room. In this case Vsee or Skype ran on the Smartboard. This finding is not fully in agreement with that of Niinimaki et al. [22]. Even with a language barrier, having a viewable team member helped. Face-to-face communication tools were the most recognised media for team members to support team communication and to increase the feeling of working as a team. This fact was highlighted by one of the participants in one focus group: “... if there’s a problem, you ask someone and they answer right away. Also for sharing files or sharing the screen. - Hey, something’s not working here - and everyone would look into it, or we’d try to find solutions among us for some of the things that caused problems.”. Another participant said: “But also the usefulness of this kind of infrastructure is clear in terms of communication and visibility. It seemed that we were far away from each other, but with these tools that distance decreased.”. Sinha [29] suggested that developers should be able to initiate conversations easily and one-to-many communication tools support this facility. 2. The use of centralized repositories enabled knowledge sharing in GSD. The use of tools like SVN, and Redmine helped teams share information as if the team were co-located. The usefulness of the complete infrastructure was

3.

4.

5.

6.

summarized by one of the participants in a focus group: “We’re looking at each of the tools separately, but what we had was a single system of infrastructures and all of them together helped us. In other words, we had, like, a lot of alarms Sonar, Hudson... - So you’d arrive and see if the day looked bright or not, and in fact... The problem was when all of the alarms went off, that was the problem.” The use of smartboards or large screens and cameras, running for instance VSee, enhanced the feeling of being a co-located team. A smartboard was an open window to the other sites. This combined with cameras was considered as important as software development and management infrastructure to share information about the status of the project. The availability of this infrastructure was highlighted during one of the focus groups: “Multiconference communication. It wasn’t one-to-one, but rather five, six, seven on screen and all working and seeing each other’s face, seeing each other’s screen. Even, by clicking on a camera - not only one person, but clicking different people’s cameras - you could really see those people working”. This could be a solution to some of the challenges identified by Sinha et al.[29] and at the same time mitigates the problems related to customer interaction. There is a huge dependency on bandwidth. Having VSee with a high frame rate (25 frames per second) open the whole time, requires a high bandwidth rate. Therefore, with respect to limitations in the bandwidth some constraints must be applied, such as to reduce the frame rate or to limit the number of simultaneously opened connections. This issue was also noted by team members during the focus groups. One developer mentioned: “... weve had some problems with the audio and video, though its also true that there have been various changes in the material used ...” and another developer commented: “On the one hand, there’s the network communication between rooms, because there have been problems when it came to using servers, or installing some of the tools that needed to communicate between various servers and couldn’t do so because the communication wasn’t good. ” This issue has previously been cited [16]. In the case of shared rooms for different projects, the infrastructure could be affected by noise or some other projects could be disturbed by this faceto-face connection with the remote site. Infrastructure as understood in this study, i.e. combining media, and project and process status sharing, provides visibility on the whole project, facilitating the integration of communication media, in accordance with [21]. This integration is always complex. In any case, these infrastructures enhanced the communication and allowed teams feel like they were working together. In one of the focus groups, one of the participants noted: “Someone in one of the rooms sneezed and someone in another room said ’Hadoop.’ Instead of saying ’Bless you’ they said ’Hadoop,’ which is the name of the technology we were using. Things like that gave me the feeling that we were all working in the same room.”. Figure 1 shows the level of satisfaction with the overall communication in the four projects ran of this research.

Fig. 1. Communication satisfaction level perceived in analysed projects

5

Conclusions and Future Work

This paper has summarized an exploratory research study on communication in AGSD. The main focus was how infrastructure can impact communication. One of the main conclusions is that communication can be improved as long as tools combine different levels of information (i.e. team members, project status and product status). The use of simple tools like Vsee in SmartBoards, proved much more useful than in team members computers. However, dependency on the bandwidth is clear; however, this is not a new issue. Future research will be focused on exploring the relations between the different levels of information, and the influence of cultural factors.

References 1. Alzoubi, Y.I., Gill, A.Q.: Agile global software development communication challenges: A systematic review. In: Siau, K., Li, Q., Guo, X. (eds.) PACIS 2014 (2014) 2. Babar, M.A., Lescher, C.: Editorial: Global software engineering: Identifying challenges is important and providing solutions is even better. Inf. Softw. Technol. 56(1), 1–5 (Jan 2014) 3. Basili, V.R.: Software modeling and measurement: The goal/question/metric paradigm. Tech. rep., U. of Maryland at College Park, MD, USA (1992) 4. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D.: Manifesto for agile software development (2001), http://www.agilemanifesto.org/ 5. Boehm, B.W.: Characteristics of Software Quality, vol. 1. North-Holland Publishing Company, 1st edn. (Jun 1978) 6. Creswell, J.: Research Design: Qualitative, Quantitative, and Mixed Methods Approaches. SAGE (2014) 7. Fernando, B.A.J., Hall, T., Fitzpatrick, A.: The impact of media selection on stakeholder communication in agile global software development: A preliminary industrial case study. pp. 131–139. SIGMIS-CPR ’11, ACM, NY, USA (2011) 8. Fink, A.: How To Conduct Surveys: A Step-by-Step Guide. Sage (2012) 9. Hartmann, D., Dymond, R.: Appropriate agile measurement: Using metrics and diagnostics to deliver business value. In: Proc. of AGILE 2006. pp. 126–134. IEEE CS, Washington, DC, USA (2006)

10. Herbsleb, J., Mockus, A.: An empirical study of speed and communication in globally distributed software development. IEEE TSE 29(6), 481–494 (June 2003) 11. Hummel, M., Rosenkranz, C., Holten, R.: The role of communication in agile systems development. ”Business and Inf. Sys. Eng.” 5(5), 343–355 (2013) 12. ISO/IEC25000: Systems and software engineering – systems and software quality requirements and evaluation (square). Tech. rep., ”ISO” (2014) 13. Jalali, S., Wohlin, C.: Global software engineering and agile practices: a systematic review. Journal of Software: Evolution and Process 24(6), 643–659 (2012) 14. Johnston, K., Rosin, K.: Global virtual teams: How to manage them. In: CAMAN 2011. pp. 1–4 (May 2011) 15. K¨ aa ¨ri¨ ainen, J., Eskeli, J., Teppola, S., V¨ alim¨ aki, A., Tuuttila, P., Piippola, M.: Extending global tool integration environment towards lifecycle management. In: Meersman, R., Herrero, P., Dillon, T. (eds.) OTM 2009, LNCS, vol. 5872, pp. 238–247. Springer Berlin Heidelberg (2009) 16. Korkala, M., Maurer, F.: Waste identification as the means for improving communication in globally distributed agile software development. Journal of Systems and Software 95(0), 122 – 140 (2014) 17. Krueger, R., Casey, M.: Focus groups: a practical guide for applied research. Sage (2009) 18. Lethbridge, T.C., Sim, S.E., Singer, J.: Studying software engineers: Data collection techniques for software field studies. Emp. Softw. Eng. 10(3), 311–341 (Jul 2005) 19. Martin, J., Yague, A., Gonzalez, E., Garbajosa, J.: Making software factory truly global: the smart software factory project. Software factory magazine (2010) 20. McCall, J.: Factors in Software Quality: Preliminary Handbook on Software Quality for an Acquisiton Manager, vol. 1-3. General Electric (November 1977) 21. Mishra, A., M¨ unch, J., Mishra, D.: Distributed development of information systems. Journal of Universal Computer Science 18(19), 2599–2601 (nov 2012) 22. Niinimaki, T., Piri, A., Lassenius, C.: Factors affecting audio and text-based communication media choice in global software development projects. In: ICGSE 2009. pp. 153–162 (July 2009) 23. Orlikowski, W.J., Baroudi, J.J.: Studying information technology in organizations: Research approaches and assumptions. Inf Sys Res 2(1), 1–28 (1991) 24. Oza, N., M¨ unch, J., Garbajosa, J., Yag¨ ue, A., Ortega, E.G.: Identifying potential risks and benefits of using cloud in distributed software development. In: Heidrich, J., Oivo, M., Jedlitschka, A., Baldassarre, M.T. (eds.) PROFES. LNCS, vol. 7983, pp. 229–239. Springer (2013) 25. Persson, J.S., Mathiassen, L., Aaen, I.: Agile distributed software development: enacting control through media and context. Inf Sys J. 22(6), 411–433 (2012) 26. Runeson, P., H¨ ost, M.: Guidelines for conducting and reporting case study research in software engineering. John Wiley Sons (2012) 27. Schwaber, K.: Agile Project Management With Scrum. Microsoft Press, Redmond, WA, USA (2004) 28. da Silva, F., Costa, C., Francanda, A., Prikladinicki, R.: Challenges and solutions in distributed software development project management: A systematic literature review. In: ICGSE 2010. pp. 87 –96 (aug 2010) 29. Sinha, V., Sengupta, B., Chandra, S.: Enabling collaboration in distributed requirements management. Software, IEEE 23(5), 52–61 (Sept 2006) 30. Unterkalmsteiner, M., Gorschek, T., Islam, A., Cheng, C., Permadi, R., Feldt, R.: Evaluation and measurement of software process improvement - a systematic literature review. Software Engineering, IEEE Transactions on PP(99), 1 (2011) 31. Yin, R.K.: Case study research: Design and methods. Sage publications (2003)