scispace - formally typeset
Search or ask a question

Showing papers presented at "International Conference on Global Software Engineering in 2017"


Proceedings ArticleDOI
20 May 2017
TL;DR: The comparison of the two adoptions showed that investing in SAFe trainings, engaging people and change agents, hiring a coach, investing in a full-time release train engineer, preparing well for the first planning event and continuously improving and customizing SAFe led to good results.
Abstract: Large software development organizations adopting agile methods need solutions and models to help scale agile to fit their needs. During recent years, several frameworks for scaling agile have been created by consultants, including the Scaled Agile Framework (SAFe), Large-scale Scrum (LeSS) and Disciplined Agile Delivery (DAD). However, research on how these frameworks are adopted in practice is seriously lacking. In this paper we describe how Comptel, a globally distributed software development company, adopted the SAFe framework in two business lines. Based on eleven interviews we present why and how the organization adopted SAFe, and discuss related challenges and success factors. The comparison of the two adoptions showed that investing in SAFe trainings, engaging people and change agents, hiring a coach, investing in a full-time release train engineer, preparing well for the first planning event and continuously improving and customizing SAFe led to good results.

89 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: It is revealed that developers have higher chances to survive in software projects when they start contributing to the project earlier, mainly modify instead of creating files, and mainly code instead of dealing with documentations.
Abstract: Large open source software projects often have a globally distributed development team. Studies have shown developer turnover has a significant impact on the project success. Frequent developer turnover may lead to loss of productivity due to lacking relevant knowledge and spending extra time learning how projects work. Thus, lots of attention has been paid to which factors are related to developer retention, however, few of them focus on the impact of activities of individual developers. In this paper, we study five open source projects from different organizations and examine whether developer turnover is affected by when they start contributing and what types of contributions they are making. Our study reveals that developers have higher chances to survive in software projects when they 1) start contributing to the project earlier, 2) mainly modify instead of creating files, 3) mainly code instead of dealing with documentations. Our results also shed lights on the potential approaches to improving developer retention.

86 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: It is concluded that, even though Scrum allows for extensive modification, Scrum itself represents a barrier for global software engineering, and development teams have to customize Scrum properly to benefit from agile software development in GSE.
Abstract: Distributed software engineering and agility are strongly pushing on today's software industry. Due to inherent incompatibilities, for years, studying Scrum and its application in distributed setups has been subject to theoretical and applied research, and an increasing body of knowledge reports insights into this combination. Through a systematic literature review, this paper contributes a collection of experiences on the application of Scrum to global software engineering (GSE). In total, we identified 40 challenges in 19 categories practitioners face when using Scrum in GSE. Among the challenges, scaling Scrum to GSE and adopting practices accordingly are the most frequently named. Our findings also show that most solution proposals aim at modifying elements of the Scrum core processes. We thus conclude that, even though Scrum allows for extensive modification, Scrum itself represents a barrier for global software engineering, and development teams have to customize Scrum properly to benefit from agile software development in GSE.

38 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: A preliminary, quantitative analysis on how the propensity to trust affects the success of collaborations in a distributed project, where the success is represented by pull requests whose code changes and contributions are successfully merged in the project's repository.
Abstract: Establishing trust between developers working at distant sites facilitates team collaboration in distributed software development. While previous research has focused on how to build and spread trust in absence of direct, face-to-face communication, it has overlooked the effects of the propensity to trust, i.e., the trait of personality representing the individual disposition to perceive the others as trustworthy. In this study, we present a preliminary, quantitative analysis on how the propensity to trust affects the success of collaborations in a distributed project, where the success is represented by pull requests whose code changes and contributions are successfully merged into the project's repository.

37 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: This research identified key Knowledge Areas, Skills and Capabilities for a DevOps role and their relative importance in New Zealand's job market and revealed the global dimensions and the emerging nature of the Dev Ops role in GSE projects.
Abstract: The DevOps phenomenon is gaining popularity through its ability to support continuous value delivery and ready accommodation of change. However, given the relative immaturity and general confusion about DevOps, a common view of expectations from a DevOps role is lacking. Through investigation of online job advertisements, combined with interviews, we identified key Knowledge Areas, Skills and Capabilities for a DevOps role and their relative importance in New Zealand's job market. Our analysis also revealed the global dimensions and the emerging nature of the DevOps role in GSE projects. This research adds a small advanced economy (New Zealand) perspective to the literature on DevOps job advertisements and should be of value to employers, job seekers, researchers as well educators and policy makers.

21 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: A survey of GSE SMEs found which of 70 Global Teaming Model practices were problematic and important to this sample, and a rich set of 63 unique GSE-Ed recommendations were found to support the seven GTM practices, but a surprising complexity of roles and responsibilities undertaken by the instructor in G SE-Ed courses was unearthed.
Abstract: Global Software Engineering (GSE) is a reality for even the smallest companies, so software engineering students need to learn how to work in a globally distributed development context. Many approaches to teaching GSE have been described in the literature. Since the majority of software development is done by engineers working in small or medium sized enterprises (SMEs) we now ask: Are today's students being trained to work effectively in small distributed companies?We surveyed three GSE SMEs to identify which of 70 Global Teaming Model (GTM) practices were problematic and important to this sample. We then mapped recommendations for GSE educators to those pinpointed GTM practices. Finally, we analysed the level to which these needed GTM practices were addressed by the GSE-Education (GSE-Ed) literature, and who performed these practices. Nine GTM practices were found important and relevant to all three SMEs. Seven of these were addressed by GSE-Ed recommendations, and two were seen to be lacking. A rich set of 63 unique GSE-Ed recommendations were found to support the seven GTM practices, but our analysis unearthed a surprising complexity of roles and responsibilities undertaken by the instructor in GSE-Ed courses. As a result student and client involvement in coordination and collaboration activities tended to be weakened or non-existent. In order to ensure graduates are prepared for the reality, practitioners of SMEs need to take on a more active role in the education process. Also, students need to be given more responsibility so they can learn the broader professional and management skills required when developing software in multi-site SME teams.

17 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: Offshoring of complex ongoing products does not seem to lead to short-term bottom-line economic gains, and may not even reach breakeven within five years, according to an empirical case study conducted in a large international corporation.
Abstract: Offshoring software development activities to a remote site in another country continues to be one of the key strategies to save development cost. However, the assumed economic benefits of offshoring are often questionable, due to a large number of hidden costs and too simple cost calculations. This study is a continuation of our work on calculating the true hourly cost that includes the extra direct and indirect costs on top of the salary-based hourly rates. We collected data from an empirical case study conducted in a large international corporation. This corporation develops software-intensive systems and has offshored its ongoing product development from Sweden to a recently on-boarded captive company site in India. In this paper, we report a number of extra costs and their impact on the resulting hourly cost as well as the bottom-line cost per work unit. Our analysis includes quantitative data from corporate archives, and expert-based estimates gathered through focus groups and workshops with company representatives from both the onshore and the offshore sites. Our findings show that there is additional cost that can be directly or at least strongly attributed to the transfer of work, working on a distance, and immaturity of the offshore site. Consideration of extra costs increases the hourly cost several times, while the performance gaps between the mature sites and the immature site leads to an even higher difference. As a result, two years after on-boarding of the offshore teams, the mature teams in high-cost locations continue to be "cheaper" despite the big salary differences, and the most positive hypothetical scenario, in which the company could break even, is unrealistic. The implications of our findings are twofold. First, offshoring of complex ongoing products does not seem to lead to short-term bottom-line economic gains, and may not even reach breakeven within five years. Second, offshoring in the studied case can be justified but merely when initiated for other reasons than cost.

12 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: The research unveils how industrial software organizations capitalize on SDO as a strategic tool in their product development.
Abstract: In today's software industry many business organizations are realizing that Software Development Outsourcing (SDO) is an imperative and strategic step for their system operation success. Many organizations have or are in the process of implementing such business transformation. This study is to investigate the status quo of strategic SDO in the software industry. To conduct this research, a mixed method exploratory study that consists of a survey and multiple cases has been adopted. The research unveils how industrial software organizations capitalize on SDO as a strategic tool in their product development.

7 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: The results suggest that it is important to cope with "little or no tagging" and "excessive tagging" behaviors to implement knowledge condensation based on UTEM tagging, and that tagging could be a good option to structure UTEM interactions, and to retrieve architectural knowledge from UTEM logs.
Abstract: An important challenge in Agile Global Software Development (AGSD) is architectural knowledge vaporization, i.e., the loss of technical knowledge due to a lack of documentation. In a previous work we identified that technical knowledge is usually available in unstructured textual electronic means (e.g. chat, mail, blogs, etc. – also known as UTEMs) used by AGSD workers during development, although not necessarily easily accessible. Also, we proposed the concept of Knowledge Condensation as a means to recover knowledge from UTEMs, by introducing a structure to their contents along with means to retrieve knowledge. In this work we present our first step towards a Knowledge Condensation tool, through a prototype tagging mechanism to structure architectural knowledge during UTEM interactions. We evaluated the prototype and obtained the following results: (1) a high perception of usefulness and a high projected intention of use, and (2) the identification of 6 tagging behavior profiles from participants. These tagging behaviors can be grouped as (i) participants who tag as expected, (ii) participants who tag more than expected, and (ii) participants who tag less than expected. These results suggest that it is important to cope with "little or no tagging" and "excessive tagging" behaviors to implement knowledge condensation based on UTEM tagging. Furthermore, we identified that tagging could be a good option to structure UTEM interactions, and to retrieve architectural knowledge from UTEM logs. Future work includes improving the tagging mechanism prototype based on the participants' suggestions and overall evaluation results, and implementing a searcher prototype to further evaluate the concept of knowledge condensation based on tagging of UTEM interactions.

7 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: There is need for tools and strategies for allocating testing tasks that leverages testers' testing style and creates more awareness among the testers, as there exists a lot of redundancies in testing efforts.
Abstract: Crowdsourced testing is gaining a lot of attention these days. Crowdsourced testing utilizes testers which subscribe to an external or internal crowdsourcing platform. Usually these testers are distributed across geographies. Thus, such testing can be treated as a form of distributed testing. Crowdsourced testing, quite often, is used to perform exploratory testing in which testers test the features as per their wish. Such testing results in redundant testing efforts due to the lack of awareness of other testers' activities, thus does not yield the full benefits of crowdsourced testing in terms of speed and coverage. Moreover, as each tester possesses a testing style, the present model of crowdsourced testing does not fully utilize tester's strength or style. In this paper, we study various redundancies involved in a distributed testing. We also study testers' behavior to understand various testing styles. The study finds that there exists a lot of redundancies in testing efforts. The study also observes that testers indeed have different testing styles which should be understood more deeply for engaging them better. Our study shows that there is need for tools and strategies for allocating testing tasks that leverages testers' testing style and creates more awareness among the testers.

4 citations


Proceedings ArticleDOI
20 May 2017
TL;DR: A case study on a partly successful follow-the-sun approach that was applied in a German company that put its approach on hold but benefited from the learned lessons.
Abstract: Follow-the-sun is an approach to develop software by handing off the progress to different time zones as the day passes. Hence, this approach allows companies to work on a project 24 hours a day, potentially reducing its time-to-market. However, several challenges, such as time zone differences or handing off work, are often reported. In this paper, we describe a case study on a follow-the-sun approach that was applied in a German company. During the approach, we did rarely face the aforementioned challenges but experienced different ones. For this reason, the company put its approach on hold but benefited from the learned lessons. Overall, we report on a partly successful follow-the-sun approach and identify five important practices.

Proceedings ArticleDOI
20 May 2017
TL;DR: The goal is to evaluate how drawing, as one activity that can facilitate expression of personal affective status, can benefit distributed teams through collaborative online drawing.
Abstract: Building up effective teams over a distance is a challenging but common problem in global software engineering. We propose an approach to help build up teams through collaborative online drawing. Our goal is to evaluate how drawing, as one activity that can facilitate expression of personal affective status, can benefit distributed teams. Preliminary results indicate positive effects of collaborative online drawing in increasing team cohesion and positive emotions. We discuss our approach and preliminary results in terms of design implications for future collaborative drawing systems for building up distributed teams.

Proceedings ArticleDOI
20 May 2017
TL;DR: Experiences and empirical evidence from global software engineering and supplier management over several years in different context and companies are provided to allow transfer of results to other companies.
Abstract: Many companies work with suppliers to increase flexibility, focus on their own core competencies and improve efficiency and cost along the supply chain. Working with suppliers and effectively integrating them to complex software supply chains is far from easy. Savings are much smaller and problems are more difficult to cure than with internal development. Obviously suppliers need to optimize both on content and business and thus do not necessarily deliver according to initial commitments. Such diverging optimization needs by suppliers and their clients can be overcome with a Win-win strategy of transparency, controlling and expectation management. This article provides experiences and empirical evidence from global software engineering and supplier management over several years in different context and companies. We illustrate effects of supplier management based on described quantitative methods by looking into two industry case studies. This will allow transfer of results to other companies.

Proceedings ArticleDOI
20 May 2017
TL;DR: This practice paper presents how a software engineering organization spread across three countries successfully transferred the knowledge of a few identified roles for a large mission-critical software system that had to conform to regulatory requirements.
Abstract: This practice paper presents how a software engineering organization spread across three countries successfully transferred the knowledge of a few identified roles for a large mission-critical software system that had to conform to regulatory requirements. Multiple releases of the system have been delivered to customers over the 15 years it has been in the market. Each release of the product had a focus area. The competence availability for these focus areas was distributed. As a natural evolution of the globally distributed team, greater responsibility is devolved to a particular location, based on the availability of the competence at that location. Moving the increased responsibility to a location, created a global role, which did not exist earlier. Building the new role required a new skill, what is unique about a global role. Equipping the team members in the new skill was necessary to take up the roles effectively and quickly. The first step was the identification of the competence for a function/role, training for which may be imparted to another person, who will take over the function/role. This is followed by a process of knowledge transfer, which ensured that a person can take up a new global role from another location. Prioritization based on ease of knowledge transfer for different areas of work, that was found to be effective is described. This helped reduce possible problems that could occur due to incorrect or incomplete transfer of knowledge. The advantages by such knowledge transfer that resulted in new persons taking up global roles have outweighed its disadvantages. The practices described are generic and can be applied to any organization of similar size and complexity.

Proceedings ArticleDOI
20 May 2017
TL;DR: This analysis describes how a client organization can become trapped in a continuous transition cycle if a suitable approach is not applied and results from a case study carried out on the Novopay Project in New Zealand in which the Ministry of Education changed their vendor from an onshore to a near-shore provider.
Abstract: Outsourcing is typically considered to occur in three phases: decision, transition and operation. As outsourcing is now well established the switching of vendors and transitioning from one system to another is common. However, most of the research to date on outsourcing has focused on the decision and operation phases, leaving a gap between theory and practice concerning the transition phase. Transition in outsourcing entails the changing of systems, business processes and/or vendors. If a suitable transition approach is not applied pressures for another transition can immediately build. This paper presents results from a case study carried out on the 'Novopay Project' in which the Ministry of Education in New Zealand changed their vendor from an onshore to a near-shore provider. This project resulted in a sequence of three transitions, with each following a different approach as a direct result of the experiences encountered in the previous transition. In this research we made use of the rich 'data dump' of evidence provided by the Ministry of Education (MoE). Our analysis describes how a client organization can become trapped in a continuous transition cycle if a suitable approach is not applied. Transition1 involved the client - MoE - moving from complete outsourcing to selective insourcing. After realizing that they did not have the capabilities to manage insourcing, Transition2 was initiated. In Transition2 the sourcing approach reverted back to complete outsourcing. When it was realized that the new vendor in Transition2 could not in fact deliver a new service model or support end-users in following new business processes, Transition3 was initiated. In Transition3, the client established an internal company to insource service operations to support end-users. Transition can be a sound business strategy initiated for a range of reasons. However, if a flawed sourcing approach is chosen it can result in 'continuous transition'.

Proceedings ArticleDOI
20 May 2017
TL;DR: This experience paper presents how a globally distributed software engineering team was able to deliver usable software at the end of each takt, why this was important, and the benefits derived.
Abstract: This experience paper presents how a globally distributed software engineering team was able to deliver usable software at the end of each takt, why this was important, and the benefits derived. We also describe the approach taken, the challenges faced and the steps to overcome them..