-
Pre-Release Experimentation in Indie Game Development: An Interview Survey
Authors:
Johan Linåker,
Elizabeth Bjarnason,
Fabian Fagerholm
Abstract:
[Background] The game industry faces fierce competition and games are developed on short deadlines and tight budgets. Continuously testing and experimenting with new ideas and features is essential in validating and guiding development toward market viability and success. Such continuous experimentation (CE) requires user data, which is often limited in early development stages. This challenge is…
▽ More
[Background] The game industry faces fierce competition and games are developed on short deadlines and tight budgets. Continuously testing and experimenting with new ideas and features is essential in validating and guiding development toward market viability and success. Such continuous experimentation (CE) requires user data, which is often limited in early development stages. This challenge is further exacerbated for independent (indie) game companies with limited resources. [Aim] We wanted to gain insights into CE practices in pre-release indie game development. [Method] We performed an exploratory interview survey with 10 indie game developers from different companies and synthesised findings through an iterative coding process. [Results] We present a CE framework for game development that highlights key parts to consider when planning and implementing an experiment and note that pre-release experimentation is centred on qualitative data. Time and resource constraints impose limits on the type and extent of experimentation and playtesting that indie companies can perform, e.g. due to limited access to participants, biases and representativeness of the target audience. [Conclusions] Our results outline challenges and practices for conducting experiments with limited user data in early stages of indie game development, and may be of value also for larger game companies, and for software intensive organisations in other industries.
△ Less
Submitted 26 November, 2024;
originally announced November 2024.
-
Preliminary Guideline for Creating Boundary Artefacts in Software Engineering
Authors:
Raquel Ouriques,
Fabian Fagerholm,
Daniel Mendez,
Tony Gorschek,
Baldvin Gislason Bern
Abstract:
Context: Software development benefits from having Boundary Artefacts (BAs), as a single artefact can supply stakeholders with different boundaries, facilitating collaboration among social worlds. When those artefacts display inconsistencies, such as incorrect information, the practitioners have decreased trust in the BA. As trust is an essential factor guiding the utilisation of BAs in software p…
▽ More
Context: Software development benefits from having Boundary Artefacts (BAs), as a single artefact can supply stakeholders with different boundaries, facilitating collaboration among social worlds. When those artefacts display inconsistencies, such as incorrect information, the practitioners have decreased trust in the BA. As trust is an essential factor guiding the utilisation of BAs in software projects, it is necessary to understand which principles should be observed when creating them. Objective: This study aimed at develop and validate a preliminary guideline support the creation of trustworthy BAs. Method: We followed a multi-step approach. We developed our guideline through a literature review and previous results from our case study. Second, we submitted the guideline for an expert evaluation via two workshops and a survey. At last, we adjusted our guideline by incorporating the feedback obtained during the workshops. Results: We grouped the principles collected from a literature review into three categories. The first category (Scope) focuses on the scope, displaying principles referring to defining each boundary's target audience, needs, and terminology. The second category (Structure) relates to how the artefact's content is structured to meet stakeholders' needs. The third (Management) refers to principles that can guide the establishment of practices to manage the artefact throughout time. The expert validation revealed that the principles contribute to creating trustworthy BAs at different levels. Also, the relevance of the guideline and its usefulness. Conclusions: The guideline strengthen BA traits such as shared understanding, plasticity and ability to transfer. Practitioners can utilise the guideline to guide the creation or even evaluate current practices for existing BAs.
△ Less
Submitted 9 June, 2023;
originally announced June 2023.
-
Connecting the Dots of Knowledge in Agile Software Development
Authors:
Raquel Ouriques,
Tony Gorschek,
Daniel Mendez,
Fabian Fagerholm
Abstract:
This article discusses the importance of managing knowledge as a resource due to its great potential to create economic value. We detail the types of knowledge resources, the challenges associated with their management, and potential solutions to maximise their utility. Our contribution is based on empirical studies performed in an industry context.
This article discusses the importance of managing knowledge as a resource due to its great potential to create economic value. We detail the types of knowledge resources, the challenges associated with their management, and potential solutions to maximise their utility. Our contribution is based on empirical studies performed in an industry context.
△ Less
Submitted 9 June, 2023;
originally announced June 2023.
-
Synthesizing Research on Programmers' Mental Models of Programs, Tasks and Concepts -- a Systematic Literature Review
Authors:
Ava Heinonen,
Bettina Lehtelä,
Arto Hellas,
Fabian Fagerholm
Abstract:
Programmers' mental models represent their knowledge and understanding of programs, programming concepts, and programming in general. They guide programmers' work and influence their task performance. Understanding mental models is important for designing work systems and practices that support programmers. Although the importance of programmers' mental models is widely acknowledged, research on m…
▽ More
Programmers' mental models represent their knowledge and understanding of programs, programming concepts, and programming in general. They guide programmers' work and influence their task performance. Understanding mental models is important for designing work systems and practices that support programmers. Although the importance of programmers' mental models is widely acknowledged, research on mental models has decreased over the years. The results are scattered and do not take into account recent developments in software engineering. We analyze the state of research into programmers' mental models and provide an overview of existing research. We connect results on mental models from different strands of research to form a more unified knowledge base on the topic. We conducted a systematic literature review on programmers' mental models. We analyzed literature addressing mental models in different contexts, including mental models of programs, programming tasks, and programming concepts. Using nine search engines, we found 3678 articles (excluding duplicates). 84 were selected for further analysis. Using the snowballing technique, we obtained a final result set containing 187 articles. We show that the literature shares a kernel of shared understanding of mental models. By collating and connecting results on mental models from different fields of research, we uncovered some well-researched aspects, which we argue are fundamental characteristics of programmers' mental models. This work provides a basis for future work on mental models. The research field on programmers' mental models still faces many challenges rising from a lack of a shared knowledge base and poorly defined constructs. We created a unified knowledge base on the topic. We also point to directions for future studies. In particular, we call for studies that examine programmers working with modern practices and tools.
△ Less
Submitted 15 December, 2022;
originally announced December 2022.
-
The Viability of Continuous Experimentation in Early-Stage Software Startups: A Descriptive Multiple-Case Study
Authors:
Vihtori Mäntylä,
Bettina Lehtelä,
Fabian Fagerholm
Abstract:
Background: Continuous experimentation (CE) has been proposed as a data-driven approach to software product development. Several challenges with this approach have been described in large organisations, but its application in smaller companies with early-stage products remains largely unexplored. Aims: The goal of this study is to understand what factors could affect the adoption of CE in early-st…
▽ More
Background: Continuous experimentation (CE) has been proposed as a data-driven approach to software product development. Several challenges with this approach have been described in large organisations, but its application in smaller companies with early-stage products remains largely unexplored. Aims: The goal of this study is to understand what factors could affect the adoption of CE in early-stage software startups. Method: We present a descriptive multiple-case study of five startups in Finland which differ in their utilisation of experimentation. Results: We find that practices often mentioned as prerequisites for CE, such as iterative development and continuous integration and delivery, were used in the case companies. CE was not widely recognised or used as described in the literature. Only one company performed experiments and used experimental data systematically. Conclusions: Our study indicates that small companies may be unlikely to adopt CE unless 1) at least some company employees have prior experience with the practice, 2) the company's limited available resources are not exceeded by its adoption, and 3) the practice solves a problem currently experienced by the company, or the company perceives almost immediate benefit of adopting it. We discuss implications for advancing CE in early-stage startups and outline directions for future research on the approach.
△ Less
Submitted 12 December, 2022;
originally announced December 2022.
-
Cognition in Software Engineering: A Taxonomy and Survey of a Half-Century of Research
Authors:
Fabian Fagerholm,
Michael Felderer,
Davide Fucci,
Michael Unterkalmsteiner,
Bogdan Marculescu,
Markus Martini,
Lars Göran Wallgren Tengberg,
Robert Feldt,
Bettina Lehtelä,
Balázs Nagyváradi,
Jehan Khattak
Abstract:
Cognition plays a fundamental role in most software engineering activities. This article provides a taxonomy of cognitive concepts and a survey of the literature since the beginning of the Software Engineering discipline. The taxonomy comprises the top-level concepts of perception, attention, memory, cognitive load, reasoning, cognitive biases, knowledge, social cognition, cognitive control, and e…
▽ More
Cognition plays a fundamental role in most software engineering activities. This article provides a taxonomy of cognitive concepts and a survey of the literature since the beginning of the Software Engineering discipline. The taxonomy comprises the top-level concepts of perception, attention, memory, cognitive load, reasoning, cognitive biases, knowledge, social cognition, cognitive control, and errors, and procedures to assess them both qualitatively and quantitatively. The taxonomy provides a useful tool to filter existing studies, classify new studies, and support researchers in getting familiar with a (sub) area. In the literature survey, we systematically collected and analysed 311 scientific papers spanning five decades and classified them using the cognitive concepts from the taxonomy. Our analysis shows that the most developed areas of research correspond to the four life-cycle stages, software requirements, design, construction, and maintenance. Most research is quantitative and focuses on knowledge, cognitive load, memory, and reasoning. Overall, the state of the art appears fragmented when viewed from the perspective of cognition. There is a lack of use of cognitive concepts that would represent a coherent picture of the cognitive processes active in specific tasks. Accordingly, we discuss the research gap in each cognitive concept and provide recommendations for future research.
△ Less
Submitted 14 January, 2022;
originally announced January 2022.
-
The human side of Software Engineering Teams: an investigation of contemporary challenges
Authors:
Marco Hoffmann,
Daniel Mendez,
Fabian Fagerholm,
Anton Luckhardt
Abstract:
There have been recent calls for research on the human side of software engineering and its impact on various factors such as productivity, developer happiness and project success. An analysis of which challenges in software engineering teams are most frequent is still missing.
We aim to provide a starting point for a theory about relevant human challenges and their causes in software engineerin…
▽ More
There have been recent calls for research on the human side of software engineering and its impact on various factors such as productivity, developer happiness and project success. An analysis of which challenges in software engineering teams are most frequent is still missing.
We aim to provide a starting point for a theory about relevant human challenges and their causes in software engineering. We establish a reusable set of challenges and start out by investigating the effect of team virtualization. Virtual teams often use digital communication and consist of members with different nationalities.
We designed a survey instrument and asked respondents to assess the frequency and criticality of a set of challenges, separated in context "within teams" as well as "between teams and clients", compiled from previous empiric work, blog posts and pilot survey feedback. For the team challenges, we asked if mitigation measures were already in place. Respondents were also asked to provide information about their team setup. The survey also measured Schwartz human values. Finally, respondents were asked if there were additional challenges at their workplace.
We report on the results obtained from 192 respondents. We present a set of challenges that takes the survey feedback into account and introduce two categories of challenges; "interpersonal" and "intrapersonal". We found no evidence for links between human values and challenges. We found some significant links between the number of distinct nationalities in a team and certain challenges, with less frequent and critical challenges occurring if 2-3 different nationalities were present compared to a team having members of just one nationality or more than three. A higher degree of virtualization seems to increase the frequency of some human challenges.
△ Less
Submitted 31 January, 2022; v1 submitted 8 April, 2021;
originally announced April 2021.
-
A Taxonomy of Assets for the Development of Software-Intensive Products and Services
Authors:
Ehsan Zabardast,
Javier Gonzalez-Huerta,
Tony Gorschek,
Darja Šmite,
Emil Alégroth,
Fabian Fagerholm
Abstract:
Context: Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Theref…
▽ More
Context: Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. Method: We perform a systematic literature review and a field study at five companies to study and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. Results: We create the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. Conclusions: The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.
△ Less
Submitted 21 October, 2022; v1 submitted 19 February, 2021;
originally announced February 2021.
-
Temporal Discounting in Software Engineering: A Replication Study
Authors:
Fabian Fagerholm,
Christoph Becker,
Alexander Chatzigeorgiou,
Stefanie Betz,
Leticia Duboc,
Birgit Penzenstadler,
Rahul Mohanani,
Colin Venters
Abstract:
Background: Many decisions made in Software Engineering practices are intertemporal choices: trade-offs in time between closer options with potential short-term benefit and future options with potential long-term benefit. However, how software professionals make intertemporal decisions is not well understood.
Aim: This paper investigates how shifting time frames influence preferences in software…
▽ More
Background: Many decisions made in Software Engineering practices are intertemporal choices: trade-offs in time between closer options with potential short-term benefit and future options with potential long-term benefit. However, how software professionals make intertemporal decisions is not well understood.
Aim: This paper investigates how shifting time frames influence preferences in software projects in relation to purposefully selected background factors.
Method: We investigate temporal discounting by replicating a questionnaire-based observational study. The replication uses a changed-population and -experimenter design to increase the internal and external validity of the original results.
Results: The results of this study confirm the occurrence of temporal discounting in samples of both professional and student participants from different countries and demonstrate strong variance in discounting between study participants. We found that professional experience influenced discounting. Participants with broader professional experience exhibited less discounting than those with narrower experience.
Conclusions: The results provide strong empirical support for the relevance and importance of temporal discounting in SE and the urgency of targeted interdisciplinary research to explore the underlying mechanisms and their theoretical and practical implications. The results suggest that technical debt management could be improved by increasing the breadth of experience available for critical decisions with long-term impact. In addition, the present study provides a methodological basis for replicating temporal discounting studies in software engineering.
△ Less
Submitted 26 June, 2019;
originally announced June 2019.
-
Happiness and the productivity of software engineers
Authors:
Daniel Graziotin,
Fabian Fagerholm
Abstract:
Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained.
But is it the case that happy software engineers are more productive? Moreover, are…
▽ More
Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained.
But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers?
These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns.
This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.
△ Less
Submitted 16 April, 2019;
originally announced April 2019.
-
Temporal Discounting in Technical Debt: How do Software Practitioners Discount the Future?
Authors:
Christoph Becker,
Fabian Fagerholm,
Rahul Mohanani,
Alexandros Chatzigeorgiou
Abstract:
Technical Debt management decisions always imply a trade-off among outcomes at different points in time. In such intertemporal choices, distant outcomes are often valued lower than close ones, a phenomenon known as temporal discounting. Technical Debt research largely develops prescriptive approaches for how software engineers should make such decisions. Few have studied how they actually make the…
▽ More
Technical Debt management decisions always imply a trade-off among outcomes at different points in time. In such intertemporal choices, distant outcomes are often valued lower than close ones, a phenomenon known as temporal discounting. Technical Debt research largely develops prescriptive approaches for how software engineers should make such decisions. Few have studied how they actually make them. This leaves open central questions about how software practitioners make decisions.
This paper investigates how software practitioners discount uncertain future outcomes and whether they exhibit temporal discounting. We adopt experimental methods from intertemporal choice, an active area of research. We administered an online questionnaire to 33 developers from two companies in which we presented choices between developing a feature and making a longer-term investment in architecture. The results show wide-spread temporal discounting with notable differences in individual behavior. The results are consistent with similar studies in consumer behavior and raise a number of questions about the causal factors that influence temporal discounting in software engineering. As the first empirical study on intertemporal choice in SE, the paper establishes an empirical basis for understanding how software developers approach intertemporal choice and provides a blueprint for future studies.
△ Less
Submitted 2 April, 2019; v1 submitted 21 January, 2019;
originally announced January 2019.
-
What happens when software developers are (un)happy
Authors:
Daniel Graziotin,
Fabian Fagerholm,
Xiaofeng Wang,
Pekka Abrahamsson
Abstract:
The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness…
▽ More
The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.
△ Less
Submitted 23 April, 2018; v1 submitted 3 July, 2017;
originally announced July 2017.
-
On the Unhappiness of Software Developers
Authors:
Daniel Graziotin,
Fabian Fagerholm,
Xiaofeng Wang,
Pekka Abrahamsson
Abstract:
The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Ps…
▽ More
The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2220 developers, yielding a rich and balanced sample of 1318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest considering happiness in future studies of both human and technical aspects in software engineering.
△ Less
Submitted 10 May, 2017; v1 submitted 15 March, 2017;
originally announced March 2017.
-
Consequences of Unhappiness While Developing Software
Authors:
Daniel Graziotin,
Fabian Fagerholm,
Xiaofeng Wang,
Pekka Abrahamsson
Abstract:
The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness -- positive emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side -- unhappiness -- cou…
▽ More
The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness -- positive emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side -- unhappiness -- could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, and is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among software developers. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness while doing software development. We found detrimental consequences on developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data, will spawn new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.
△ Less
Submitted 24 February, 2017; v1 submitted 20 January, 2017;
originally announced January 2017.
-
Unhappy Developers: Bad for Themselves, Bad for Process, and Bad for Software Product
Authors:
Daniel Graziotin,
Fabian Fagerholm,
Xiaofeng Wang,
Pekka Abrahamsson
Abstract:
Recent research in software engineering supports the "happy-productive" thesis, and the desire of flourishing happiness among programmers is often expressed by industry practitioners. Recent literature has suggested that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness of developers due to its negative impact. However, possible negative effects…
▽ More
Recent research in software engineering supports the "happy-productive" thesis, and the desire of flourishing happiness among programmers is often expressed by industry practitioners. Recent literature has suggested that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness of developers due to its negative impact. However, possible negative effects of unhappiness are still largely unknown in the software development context. In this paper, we present the first results from a study exploring the consequences of the unhappy developers. Using qualitative data analysis of the survey responses given by 181 participants, we identified 49 potential consequences of unhappiness while developing software. These results have several implications. While raising the awareness of the role of moods, emotions and feelings in software development, we foresee that our classification scheme will spawn new happiness studies linking causes and effects, and it can act as a guideline for developers and managers to foster happiness at work.
△ Less
Submitted 10 February, 2017; v1 submitted 11 January, 2017;
originally announced January 2017.
-
A Platform for Teaching Applied Distributed Software Development: The Ongoing Journey of the Helsinki Software Factory
Authors:
Fabian Fagerholm,
Nilay Oza,
Jürgen Münch
Abstract:
Teaching distributed software development (DSD) in project courses where student teams are geographically distributed promises several benefits. One main benefit is that in contrast to traditional classroom courses, students can experience the effects of distribution and the mechanisms for coping with distribution by themselves, therefore understanding their relevance for software development. The…
▽ More
Teaching distributed software development (DSD) in project courses where student teams are geographically distributed promises several benefits. One main benefit is that in contrast to traditional classroom courses, students can experience the effects of distribution and the mechanisms for coping with distribution by themselves, therefore understanding their relevance for software development. They can thus learn to take more care of distribution challenges and risks when starting to develop software in industry. However, providing a sustainable environment for such project courses is difficult. A development environment is needed that can connect to different distributed teams and an ongoing routine to conduct such courses needs to be established. This article sketches a picture of the Software Factory, a platform that supports teaching distributed student projects and that has now been operational for more than three years. We describe the basic steps of conducting Software Factory projects, and portray experiences from past factory projects. In addition, we provide a short overview of related approaches and future activities.
△ Less
Submitted 18 December, 2013;
originally announced December 2013.
-
Developer Experience: Concept and Definition
Authors:
Fabian Fagerholm,
Jürgen Münch
Abstract:
New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers' feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about prod…
▽ More
New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers' feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.
△ Less
Submitted 5 December, 2013;
originally announced December 2013.
-
The Effects of GQM+Strategies on Organizational Alignment
Authors:
Jürgen Münch,
Fabian Fagerholm,
Petri Kettunen,
Max Pagels,
Jari Partanen
Abstract:
The increasing role of software for developing products and services requires that organizations align their software-related activities with high-level business goals. In practice, this alignment is very difficult and only little systematic support is available. GQM+Strategies is a method that aims at aligning organizational goals, strategies, and measurements at all levels of an organization in…
▽ More
The increasing role of software for developing products and services requires that organizations align their software-related activities with high-level business goals. In practice, this alignment is very difficult and only little systematic support is available. GQM+Strategies is a method that aims at aligning organizational goals, strategies, and measurements at all levels of an organization in a seamless way. This article describes a case study of applying GQM+Strategies in a globally op- erating industrial R&D organization developing special-purpose device products for B2B customers. The study analyzes how GQM+Strategies has helped clarify and harmonize the goal set of the organization. Results of the study indicate improved alignment and integration of different goals. In addition, the method helped to make the initially informal goal-setting more transparent and consequently enabled revising it while new, more important goals were discovered and comprehended. Moreover, several elements affecting the achievement of goals as well as impediments were identified.
△ Less
Submitted 25 November, 2013;
originally announced November 2013.
-
Experiences and Insights from Applying GQM+Strategies in a Systems Product Development Organisation
Authors:
Jürgen Münch,
Fabian Fagerholm,
Petri Kettunen,
Max Pagels,
Jari Partanen
Abstract:
Aligning software-related activities with corporate strategies and goals is increasingly important for several reasons such as increasing the customer satisfaction in software-based products and services. Several approaches have been proposed to create such an alignment. GQM+Strategies is an approach that applies measurement principles to link goals and strategies on different levels of an organis…
▽ More
Aligning software-related activities with corporate strategies and goals is increasingly important for several reasons such as increasing the customer satisfaction in software-based products and services. Several approaches have been proposed to create such an alignment. GQM+Strategies is an approach that applies measurement principles to link goals and strategies on different levels of an organisation. In this paper, we describe experiences from applying GQM+Strategies to elicit, link, and align the goals of an integrated systems product development organisation across multiple organisational levels. We provide insights into how GQM+Strategies was applied during a five- month period. The paper presents the enacted application process and main lessons learnt. In addition, related approaches are described and an outlook on future work is given.
△ Less
Submitted 7 November, 2013;
originally announced November 2013.
-
Onboarding in Open Source Software Projects: A Preliminary Analysis
Authors:
Fabian Fagerholm,
Patrik Johnson,
Alejandro Sánchez Guinea,
Jay Borenstein,
Jürgen Münch
Abstract:
Nowadays, many software projects are partially or completely open-source based. There is an increasing need for companies to participate in open-source software (OSS) projects, e.g., in order to benefit from open source ecosystems. OSS projects introduce particular challenges that have to be understood in order to gain the benefits. One such challenge is getting newcomers onboard into the projects…
▽ More
Nowadays, many software projects are partially or completely open-source based. There is an increasing need for companies to participate in open-source software (OSS) projects, e.g., in order to benefit from open source ecosystems. OSS projects introduce particular challenges that have to be understood in order to gain the benefits. One such challenge is getting newcomers onboard into the projects effectively. Similar challenges may be present in other self-organised, virtual team environments. In this paper we present preliminary observations and results of in-progress research that studies the process of onboarding into virtual OSS teams. The study is based on a program created and conceived at Stanford University in conjunction with Facebook's Education Modernization program. It involves the collaboration of more than a dozen international universities and nine open source projects. More than 120 students participated in 2013. The students have been introduced to and supported by mentors experienced in the participating OSS projects. Our findings indicate that mentoring is an important factor for effective onboarding in OSS projects, promoting cohesion within distributed teams and maintaining an appropriate pace.
△ Less
Submitted 6 November, 2013;
originally announced November 2013.
-
How Does Kanban Impact Communication and Collaboration in Software Engineering Teams?
Authors:
Nilay Oza,
Fabian Fagerholm,
Jürgen Münch
Abstract:
Highly iterative development processes such as Kanban have gained significant importance in industry. However, the impact of such processes on team collaboration and communication is widely unknown. In this paper, we analyze how the Kanban process aids software team's behaviours -- in particular, communication and collaboration. The team under study developed a mobile payment software product in s…
▽ More
Highly iterative development processes such as Kanban have gained significant importance in industry. However, the impact of such processes on team collaboration and communication is widely unknown. In this paper, we analyze how the Kanban process aids software team's behaviours -- in particular, communication and collaboration. The team under study developed a mobile payment software product in six iterations over seven weeks. The data were collected by a questionnaire, repeated at the end of each iteration. The results indicate that Kanban has a positive effect at the beginning to get the team working together to identify and coordinate the work. Later phases, when the team members have established good rapport among them, the importance for facilitating team collaboration could not be shown. Results also indicate that Kanban helps team members to collectively identify and surface the missing tasks to keep the pace of the development harmonized across the whole team, resulting into increased collaboration. Besides presenting the study and the results, the article gives an outlook on future work.
△ Less
Submitted 6 November, 2013;
originally announced November 2013.
