Staffing software projects with engineers from inexpensive locations has become commonplace. However, distributed development remains practically challenging because of recurring problems, e.g., decreased productivity, low quality, and high, unforeseen costs. Although it is often overlooked, one of the main underlying reasons for these challenges is high employee turnover. This might be especially noticeable in developing countries with strong economic growth such as India. This article examines turnover of Indian software engineers and introduces strategies to address it.

@en

Background: Employee turnover in GSD is an extremely important issue, especially in Western companies offshoring to emerging nations. Aims: In this case study we investigated an offshore vendor company and in particular whether the employees' retention is related with their experience. Moreover, we studied whether we can identify a threshold associated with the employees' tendency to leave the particular company. Method: We used a case study, applied and presented descriptive statistics, contingency tables, results from Chi-Square test of association and post hoc tests. Results: The emerging results showed that employee retention and company experience are associated. In particular, almost 90% of the employees are leaving the company within the first year, where the percentage within the second year is 50-50%. Thus, there is an indication that the 2 years' time is the retention threshold for the investigated offshore vendor company. Conclusions: The results are preliminary and lead us to the need for building a prediction model which should include more inherent characteristics of the projects to aid the companies avoiding massive turnover waves.

@en

Context: In this paper we present a multiple case study on the insights of software organizations into stakeholder satisfaction and (perceived) value of their software projects. Our study is based on the notion that quantifying and qualifying project size, cost, duration, defects, and estimation accuracy needs to be done in relation with stakeholder satisfaction and perceived value. Objectives: We contrast project metrics such as cost, duration, number of defects and estimation accuracy with stakeholder satisfaction and perceived value. Method: In order to find out whether our approach is practically feasible in an industrial setting, we performed two case studies; one in a Belgian telecom company and the other in a Dutch software company. Results: In this study we evaluate 22 software projects that were delivered during one release in the Belgian telecom company, and 4 additional large software releases (representing an extension of 174% in project size) that were delivered in a Dutch software company. Eighty-three (83) key stakeholders of two companies provide stakeholder satisfaction and perceived value measurements in 133 completed surveys. Conclusions: We conclude that a focus on shortening overall project duration, and improving communication and team collaboration on intermediate progress is likely to have a positive impact on stakeholder satisfaction and perceived value. Our study does not provide any evidence that steering on costs helped to improve these. As an answer to our research question - how do stakeholder satisfaction and perceived value relate to cost, duration, defects, size and estimation accuracy of software projects? - we found five take-away-messages.

@en

Context: In this paper we present an exploratory study on the insights of organizations into the perceived value of their software projects. Our study is based on the notion that quantifying and qualifying project size, cost, duration and defects needs to be done in relation with stakeholder satisfaction and perceived value. Objectives: We expect that bringing perceived value into the equation will help in increasing the impact such organizations deliver. Method: In order to find out whether our approach is practically feasible in an industrial setting, we performed an exploratory study in a Belgian telecom company. Results: In this study we evaluate 22 software projects that were delivered during one release. Fiftythree (53) key stakeholders provide stakeholder satisfaction and perceived value measurements in 103 completed surveys. Conclusions: We conclude that a focus on shortening overall project duration, and improving communication on intermediate progress improved stakeholder satisfaction and perceived value. Our study does not provide any evidence that steering on costs helped to improve these.@en

In this paper, we attempt to understand what contributes to a successful process for managing legacy system evolution. We provide an analysis of a number of key performance indicators such as cost, duration, and defects. By normalizing through function points, we furthermore compare to a larger benchmark. To do so we performed a mixed, retrospective case study on a series of nine software releases and eight single once-only releases, all performing on a single, legacy software system, in a West-European telecom company. We interviewed eleven stakeholders that were closely involved in the subject software releases. As a result, we listed a number of observations from the quantitative and qualitative analysis. We found that a release process that performs above average on cost and duration satisfies stakeholders through fast response and direct value, even when the reliability and availability of the actual system is weak.

@en

Many enterprises that adopt Agile/Scrum suffer from collaboration issues between Scrum teams that depend on one another to deliver end-to-end functionality. These dependencies delay delivery and as a result deteriorate the business value delivered in such value chains. The objective of our study is to support enterprises that suffer from such dependencies with a governance framework that helps them mitigate collaboration issues between sets of codependent Scrum teams. We first identify a set of intervention actions that aim to mitigate the collaboration issues between codependent Scrum teams. Second, we validate the effectiveness of these intervention actions in a large confirmatory industrial case study. This study was held in a large multi-national financial institute that worked with a large number of codependent Scrum teams. Third, we triangulate the findings in three focus groups. We finally package the intervention actions in a governance framework. The intervention actions led to a delivery time reduction from 29 days to 10 days. The participants in the focus groups confirmed the causality between the intervention actions and the observed delivery improvement. The empirical results show that the intervention actions, packaged in the governance framework, enable codependent sets of Scrum teams to deliver faster.

@en

Most companies have learned that cost calculations for offshore outsourcing shouldn't be limited to hourly wages. Looking at salaries alone, you could naively hope for cost reductions of up to 90 percent. However, don't underestimate the cost of knowledge transfer, travel, attrition, miscommunication, and so on. But does an opportunity for cost reduction still exist? To answer this question, researchers delved into the collaboration between a Dutch software company and an Indian vendor. They gathered evidence for direct costs and quantified perceptions of indirect costs associated with an in-house team in the Netherlands and the outsourced offshore team in India. The offshore team's true hourly costs took three years to become comparable with those of the in-house team. Getting close to the break-even point took five years. Learning costs due to offshore employee turnover were the primary cost factor to get under control.@en

What can we learn from historic data that is collected in three software companies that on a daily basis had to cope with highly complex project portfolios? In this paper we analyze a large dataset, containing 352 finalized software engineering projects, with the goal to discover what factors affect software project performance, and what actions can be taken to increase project performance when building a software project portfolio. The software projects were classified in four quadrants of a Cost/Duration matrix: analysis was performed on factors that were strongly related to two of those quadrants, Good Practices and Bad Practices. A ranking was performed on the factors based on statistical significance. The paper results in an inventory of 'what factors should be embraced when building a project portfolio?' (Success Factors), and 'what factors should be avoided when doing so?' (Failure Factors). The major contribution of this paper is that it analyzes characteristics of best performers and worst performers in the dataset of software projects, resulting in 7 Success Factors (a.o. steady heartbeat, a fixed, experienced team, agile (Scrum), and release-based), and 9 Failure Factors (a.o. once-only project, dependencies with other systems, technology driven, and rules- and regulations driven).

@en

Research has highlighted a need for a specific and practical implementation framework for deploying Lean Six Sigma (LSS) in small- and medium-sized enterprises (SMEs). The success of LSS implementation in SMEs is highly dependent on the extent to which an LSS deployment programme addresses the specific properties of SMEs. In this study we have evaluated an existing framework for Six Sigma implementation for SMEs [Kumar, M., Antony, J., & Tiwari, M. K. (2011). Six Sigma implementation framework for SMEs – a roadmap to manage and sustain the change. International Journal of Production Research, 49(18), 5449–5467] using a multi-method triangulation approach. The objectives of this study were firstly to strengthen the foundations of the existing framework by uncovering evidence for some of its elements and, secondly, to identify the proposed revisions to the framework, especially focussed on its application in manufacturing SMEs. The results of our study are a collection of confirmations and revision proposals for the framework, leading to a revised conceptual framework.

@en

In this research we aimed to identify distinguishing factors in software releases. For this purpose we analyzed the metrics of 26 software projects. These projects were release-based deliveries from two stable, experienced development teams. During the measurement period both teams transformed from a plan-driven delivery model (waterfall) to an agile approach (Scrum). Overall, we observed that these small release-based projects differ largely from non-release-based projects. Our research indicates that a combination of release-based working, a fixed and experienced development team, and a steady heartbeat contribute to performances that can be characterized as best-practice. The main contribution of this paper is that we found five success factors (all reducing development complexity) that result in best-of-class performance for small software releases. @en

Authors highlight computer software in fictional story about business owner The world of computer software can be difficult to understand if one is not entrenched in it every day. In their book ¿Power of Scrum¿ (ISBN 1463578067) Jeffrey V. Sutherland, D.M. van Solingen and Eelco Rustenberg use a fictional story to help the readers to better understand the real intricacies of the frame working software, Scrum. Scrum is a software development methodology that allows companies to work more efficiently and productively. This book gives readers an easy-to-read overview of Scrum and how and why it works. It uses a narrative story to explain some of the basic do¿s and don¿ts of using Scrum while presenting only a small amount of the theory that goes into the system. The story introduces us to Mark Resting, the Chief Technology Officer (CTO) of a software company. Resting has been having some difficulty with a project for one of his company¿s major customers, LogiStrux. After meeting with the customer¿s board in London, he meets Jerry, a Scrum system expert. After discussing Scrum, Resting is convinced that some of the strategies that the system uses can help in the LogiStrux project and possibly even in some of his company¿s other areas of work. Resting invites Jerry to his company¿s headquarters in Washington, D.C. so he can show him and his employees how to implement these new methods. ¿The book is a very easy read and can be read cover to cover in less than three hours,¿ Sutherland says. ¿The characters and narrative development were created to help translate some of the theories in Scrum to a more personal, and easier to understand level.¿ Sutherland is hoping that the story and non-technical language attracts a wider audience than just those interested in technology and software. He also hopes the book will be purchased by companies and given to the associates who use Scrum so they can become more familiar with it. ¿Power of Scrum¿ is available for sale at Amazon.com.@en