Context - Software companies should track innovation as rigorously as core business operations. For that, the assessment of innovation projects is a critical process, in particular to make their innovation initiatives funded. Objective - In this article, we aim to evaluate the need for more practical measurement tools, by checking the agreement of very experienced analysts, from the industry, about the innovation degree of four actual software projects. Method - We conducted a survey with eight business analysts, using a combination of the Three Horizons Model and the Gartner's Hyper Cycle for emerging technologies as a frame of reference. Results - In general, the level of agreement about the innovation degree in the projects was very low. Looking at the cases in isolation, it is possible to suggest reasons for the low level of agreement between the evaluators. Conclusions - Our data support the fact that innovation is an activity difficult to characterize and even more difficult to measure, and the need for practices to achieve better intersubjective agreement for innovation assessment became evident in this work.

Context: In the workplace, some individuals engage in the voluntary and intentional generation, promotion, and realization of new ideas for the benefit of individual performance, group effectiveness, or the organization. The literature classifies this phenomenon as innovative behaviour. Despite its importance to the development of innovation, innovative behaviour has not been fully investigated in software engineering. Objective: To understand the factors that support or inhibit innovative behaviour in software engineering practice. Method: We conducted a pilot case study in a Canadian software company using interviews and observations as data collection techniques. Using qualitative analysis, we identified relevant factors and relationships not addressed by studies from other areas. Results: Individual innovative behaviour is influenced by individual attitudes and also by situational factors such as relationships in the workplace, organizational characteristics, and project type. We built a model to express the interacting effects of these factors. Conclusions: Innovative behaviour is dependent on individual and contextual factors. Our results contribute to relevant impacts on research and practice, and to topics that deserve further study.

Context: A case study is a powerful research strategy for investigating complex social-technical and managerial phenomena in real life settings. However, when the phenomenon has not been fully discovered or understood, pilot case studies are important to refine the research problem, the research variables, and the case study design before launching a full-scale investigation. The role of pilot case studies has not been fully addressed in empirical software engineering research literature. Objective: To explore the use of pilot case studies in the design of full-scale case studies, and to report the main lessons learned from an industrial pilot study. Method: We designed and conducted an exploratory case study to identify new relevant research variables that influence the innovative behaviour of software engineers in the industrial setting and to refine the full-scale case study design for the next phase of our research. Results: The use of a pilot case study identified several important research variables that were missing in the initial framework. The pilot study also supported a more sophisticated case study design, which was used to guide a full-scale study. Conclusions: When a research topic is has not been fully discovered or understood, it is difficult to create a case study design that covers the relevant research variables and their potential relationships. Conducting a full-scale case study using an untested case design can lead to waste of resources and time if the design has to be reworked during the study. In these situations, the use of pilot case studies can significantly improve the case study design.

Job Rotation is an organizational practice in which individuals are frequently moved from a job (or project) to another in the same organization. Studies in other areas have found that this practice has both negative and positive effects on individuals' work. However, there are only few studies addressing this issue in software engineering so far. The goal of our study is to investigate the effects of job rotation on work related factors in software engineering by performing a qualitative case study on a large software organization that uses job rotation as an organizational practice. We interviewed senior managers, project managers, and software engineers that had experienced this practice. Altogether, 48 participants were involved in all phases of this research. Collected data was analyzed using qualitative coding techniques and the results were checked and validated with participants through member checking. Our findings suggest that it is necessary to find balance between the positive effects on work variety and learning opportunities, and negative effects on cognitive workload and performance. Further, the lack of feedback resulting from constant movement among projects and teams may have a negative impact on performance feedback. We conclude that job rotation is an important organizational practice with important positive results. However, managers must be aware of potential negative effects and deploy tactics to balance them. We discuss such tactics in this article.

ABSTRACT Distributed software development (DSD) has intensified over the past few years, and DSD project management is more complex than collocated project management. However, no systematic research effort has focused on aggregating evidence from the scientific literature to build models to support project management on DSD context. For these reasons, the goal of this paper is to build an evidence‐based model of DSD project management from the research findings about challenges of DSD and the practices, models and tools proposed and used to overcome these challenges. We based the construction of this model on the evidence collected and synthesized by a comprehensive systematic mapping study of 70 research papers published between 1997 and 2009. We believe that our results can help practitioners and researchers to better understand the challenges and implement more effective solutions to improve project management within distributed project management teams. These results also provide a mapping of the research about DSD project management, identifying areas where further research is needed. Copyright © 2011 John Wiley & Sons, Ltd.

Background The influence of individual personalities on individual tasks and team work has been a concern in software engineering over the past 50 years. However, how to use personality analysis and what it can offer for the practice of software engineering is still subject to debate among researchers. Aim The goal of this work is to identify the methods used, topics addressed, personality tests applied, and the main findings produced in the research about personality in software engineering. Method We performed a systematic literature review of peer reviewed studies published between 1970 and 2010. Results Data extracted from 42 studies shows that pair programming and team building are the most recurring research topics and MBTI is the most used test. Conclusions Contradicting evidences were found that may have been caused by differences in context, research method, and versions of the tests used in the studies. While this raises a warning for practitioners that wish to use of personality tests in practice, it shows several opportunities for researchers.

The goal of this article is to identify criteria used in industrial practice to select members of a software project team, and to look for relationships between these criteria and project success. Initially, using semi-structured interviews for data collection and qualitative methods for data analysis and synthesis, a set of team building criteria was identified from project managers in industry. Then, using this set of criteria and a method to evaluate software project success, a survey questionnaire was created to investigate the relationship between the consistent use or application of the criteria and project success. A cross-sectional survey collected data from 48 projects in 24 software companies and the data was analyzed for internal reliability using statistical methods. The findings show that the consistent use of the set of criteria correlated significantly with project success, and the criteria related to human factors present the strongest correlations.

After a seminal article introducing-evidence based software engineering in 2004, systematic reviews (SR) have been increasingly used as a method for conducting secondary studies in software engineering. Our goal is to critically appraise the use of SR in software engineering with respect to the research questions asked and the ways the questions were used in the reviews. We analyzed 53 literature reviews that had been collected in two published tertiary studies. We found that over 65% of the research questions asked in the reviews were exploratory and only 15% investigated causality questions. We concluded that there is a need for a consistent use of terminology to classify secondary studies and that reports of literature reviews should follow reporting guidelines to support assessment and comparison.