Eric Hanchen Jiang, Weixuan Ou, Run Liu, Shengyuan Pang, Guancheng Wan, Ranjie Duan, Wei Dong, Kai-Wei Chang, XiaoFeng Wang, Ying Nian Wu, Xinfeng Li. Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 2026.

Abstract While Generative AI (GenAI) has rapidly transformed software development and GenAI tools receive widespread adoption, how humans and AI should collaborate has become a focal point for Agile practitioners, whose values emphasise teamwork and collaboration. Yet, despite growing interest, research on human-AI collaboration in software engineering, especially within Agile contexts, remains limited. Our study investigates Agile practitioners’ perceptions of collaborating with GenAI in software development activities. We conducted a survey with 73 Agile practitioners, revealing how they currently collaborate with GenAI across various activities and how they expect this collaboration to evolve. Key findings include that GenAI is currently not a substantial part of real-world workflows, being either unused or limited to an assistant role, but that there is a clear tendency towards greater AI involvement in the future, with practitioners increasingly viewing AI as a collaborator rather than merely a tool. These findings advance our understanding of human-AI collaboration in Agile settings and can guide both future research and the practical adoption of GenAI in Agile environments.

Abstract Agility embraces changes in the functional and non-functional requirements. When the latter happens, the architecture needs to evolve, putting architectural refactoring in evidence. Microservices is an architectural style that enables more agility in a system’s architecture, as it favors the evolution of the system by adding new operations. But it also has its liabilities: the number of services can explode, with similar ones being created. Ultimately, that harms the system’s evolution and maintenance. This work addresses these challenges by proposing a catalog of architecture refactorings to promote reusability in Microservices. These refactorings target patterns that embrace data heterogeneity in the APIs and employ metadata to enhance messages and guide processing. We evaluated the catalog with case studies of three real-world applications and conducted change impact analysis in two scenarios: adding a new data provider, and adding a new processing algorithm. The results showed that embracing heterogeneous data in the API enables a more seamless addition of new data providers, and using metadata can strongly decouple the processing algorithms from the data they use. Furthermore, the results point to other improvements in observability, scalability, and infrastructure.

Abstract The lack of core theories is a challenge for the whole software engineering (SE) discipline, particularly crucial for the agile software development (ASD) field, which is largely practice-driven. Without solid and continuous theoretical development glued by core theories, ASD risks repeating wrong practices and oversimplifying real-world phenomena. To address this issue and foster a strong link between empirical evidence and theoretical development, we conduct this critical review using the Complex Network Analysis (CNA) approach, in response to the editors’ call on the XP2020 conference. Based on 83 selected articles and 88 identified theories, our analysis traced the originating disciplines of these theories and synthesized 3 key theory communities. We position ASD core theories between empirical generalization and middle-range theories in the SE theory spectrum and offer practical guidelines for researchers to use, borrow, and generate ASD theories. It is further recommended that new theory development be aligned with the theory of coordination and control theory while employing Complex Adaptive Systems (CAS) theory as a theoretical lens when borrowing theories to ASD.

Uncertainty is present in software architecture decisions due to a lack of knowledge about the requirements and the solutions involved. However, this uncertainty is usually not made explicit, and decisions can be made based on unproven premises or false assumptions. This paper focuses on a technique called ArchHypo that uses hypotheses engineering to manage uncertainties related to software architecture. It proposes formulating a technical plan based on each hypothesis’ assessment, incorporating measures able to mitigate its impact and reduce uncertainty. To evaluate the proposed technique, this paper reports an application of the technique in a mission-critical project that faced several technical challenges. Conclusions were based on data extracted from the project documentation and a questionnaire answered by all team members. As a result, the application of ArchHypo provided a structured approach to dividing the architectural work through iterations, which facilitated architectural decision-making. However, further research is needed to fully understand its impact across different contexts. On the other hand, the team identified the learning curve and process adjustments required for ArchHypo's adoption as significant challenges that could hinder its widespread adoption. In conclusion, the evidence found in this study indicates that the technique has the potential to provide a suitable way to manage the uncertainties related to software architecture, facilitating the strategic postponement of decisions while addressing their potential impact.

Defining and designing a software product is not merely a technical endeavor, but also a socio-technical journey. As such, its success is associated with human-related aspects, such as the value users perceive. To handle this issue, the product manager role has become more evident in software-intensive companies. A unique, challenging context for these professionals is constituted by software startups, emerging companies developing novel solutions looking for sustainable and scalable business models. This study aims to describe the role of product managers in the context of software startups. We performed a Socio-Technical Grounded Theory study using data from blog posts and interviews. The results describe the product manager as a multidisciplinary, general role, not only guiding the product by developing its vision but also as a connector that emerges in a growing company, enabling communication of software development with other areas, mainly business and user experience. The professional performing this role has a background in one of these areas but a broad knowledge and understanding of key concepts of the other areas is needed. We also describe how differences of this role to other lead roles are perceived in practice. Our findings represent several implications for research, such as better understanding of the role transformation in growing software startups, practice, e.g., identifying the points to which a professional migrating to this role should pay attention, and the education of future software developers, by suggesting the inclusion of related topics in the education and training of future software engineers.

Context The COVID‐19 pandemic has had a disruptive impact on how people work and collaborate across all global economic sectors, including software business. While remote working is not new for software engineers, forced WFH situations come with both limitations and opportunities. As the ‘new normal’ for working might be based on the current state of Work‐from‐home (WFH), it is useful to understand what has happened and learn from that. Objective This study aims to gain insights into how their WFH arrangement impacts project management and software engineering. We are also interested in exploring these impacts in different contexts, such as startups and established companies. Method We conducted a global‐scale, cross‐sectional survey during the spring and summer 2021. Our results are based on quantitative and qualitative analysis of 297 valid responses. Results We characterize the profile of WFH in both spatial and temporal aspects, together with a set of common collaborative tools and coordination and control mechanisms. We revealed some areas of project management that are relatively more challenging during WFH situations, such as coordination, communication and project planning. We also revealed a mixed picture of the perceived impact of WFH on different software engineering activities. Conclusion WFH is a situational phenomenon which can have both negative and positive impact on software teams. For practitioners, we suggest a unified approach to consider the context of WFH, collaborative tools, associated coordination and control approaches and a process that resolve those aspects that are sensitive to physical interaction.

[Context] Systematic Literature Review (SLR) has been a major type of study published in Software Engineering (SE) venues for about two decades. However, there is a lack of understanding of whether an SLR is really needed in comparison to a more conventional literature review. Very often, SE researchers embark on an SLR with such doubts. We aspire to provide more understanding of when an SLR in SE should be conducted. [Objective] The first step of our investigation was focused on the dataset, i.e., the reviewed papers, in an SLR, which indicates the development of a research topic or area. The objective of this step is to provide a better understanding of the characteristics of the datasets of SLRs in SE. [Method] A research synthesis was conducted on a sample of 170 SLRs published in top-tier SE journals. We extracted and analysed the quantitative attributes of the datasets of these SLRs. [Results] The findings show that the median size of the datasets in our sample is 57 reviewed papers, and the median review period covered is 14 years. The number of reviewed papers and review period have a very weak and non-significant positive correlation. [Conclusions] The results of our study can be used by SE researchers as an indicator or benchmark to understand whether an SLR is conducted at a good time.

Abstract Managing non-functional requirements (NFRs) has been a challenge in software development for many years. These requirements are typically used to make important architectural decisions early in the project, which can be problematic if they are uncertain or unstable. When this uncertainty is not considered when designing the software architecture, changes are often costly and sometimes even unfeasible. Some empirical studies on the subject have already been carried out, but few have focused on the perspective of professionals with extensive experience on the changes and uncertainties of NFRs. This work aims to expand the understanding about the management, clarity and validation of NFRs to fill this gap in the literature. To achieve this goal, a survey was carried out with professionals to find out how NFRs were managed and validated. For the research design, instead of generic questions, the questionnaire focused on some specific types of NFRs to induce participants to recall and report concrete situations. As a result, 40 valid responses were obtained, most from professionals with more than 10 years of experience. The results reveal that a significant number of NFRs were defined after the delivery of software increments (more than 30%) and that revision and change occurred in about a third of the NFRs. Hence, this study presents evidence that NFRs, as the functional ones, can also be uncertain and change frequently, requiring agile approaches and techniques to evolve the software architecture to consider this uncertainty.

Background: Researchers in software engineering have increasingly added gray literature (GL) to primary and, especially, secondary studies. Several reasons explain this decision, such as grasping practitioners’ view on the topic under study. However, the use of GL in research poses several challenges like the amount and unstructured nature of data. The lack of automated tools and approaches to aid this task creates a bottleneck in selecting documents for inclusion. Aims: We investigate how summaries generated by PositionRank, an unsupervised text summarization approach, could support the inclusion analysis of documents in a GL study. Method: We performed an evaluation of using PositionRank to summarize documents analyzed on an ongoing study on software engineering. We compared the rating among two raters in a cross-over setup using summaries and full-text documents. We calculated their agreement, the precision and miss-rate using summaries against the full-text. The raters also discussed the documents on which they had conflicted answers and reached categories of reasons to explain the disagreements. Results: The results indicate that some inclusion criteria, which might be positively determined by few sentences, is susceptible to be misclassified when using summaries. Conclusions: Our study presents an analysis of the use of automatic summarization to support the inclusion assessment in gray literature studies discussing when this solution is viable. Our results could guide further studies in this direction.

LEGO ® SERIOUS PLAY ® (LSP) is an effective methodology to enable the representation of abstract concepts and has been applied to teach several Software Engineering topics.However, there is limited evidence on how LSP can be used in training on agile mindset, which is the core and central element of agile methods.This paper demonstrates how LSP can be utilized in agile training to reveal the agile mindset of participants.We describe our experience of utilising LSP in an agile training project for local software companies.Since the project was run during the COVID-19 pandemic, we adapted the LSP methodology for online settings, which was not straightforward because face-to-face interactions and tangible objects are key characteristics of LSP.In this experience report, we describe the design of the online LSP workshops and explain how to analyze LSP models to reveal the agile mindset of the participants and to tailor the training accordingly.We also provide evidence of the effectiveness of the LSP methodology in our training project.Drawing upon our experience, we synthesize a set of lessons learned and sketch recommendations for educators who intend to apply LSP in their future endeavours.

Abstract One essential prerequisite for successful agile retrospective sessions is to accomplish a psychologically safe environment. Creating a psychologically safe environment for the co-located team is challenging. Further, it becomes more demanding with online agile retrospective teams. Literature sheds little light on creating a psychologically safe online environment for conducting agile retrospectives. Our study aims at addressing this knowledge gap and asks the research question: how does the usage of online tools influence psychological safety in online agile retrospectives? A single case study was conducted with a major software company’s Research and Development team. We analysed a recorded online retrospective session of the team to identify patterns of the usage of online tools associated with the online meeting platform they used and how that usage influenced the psychological safety level of the team. Our findings show that retrospective participants are psychologically safe if they share opinions, make mistakes, raise a problem, ask questions, and show consent using online tools. Our study contributes online tools that influence psychological safety factors, corresponding levels and behaviours.

Following the highly pervasive and effective use of agile methods at the team level, many software organisations now wish to replicate this success at the organisational level, adopting large-scale agile methods such as SAFe, Scrum-at-Scale, and others. However, this has proven significantly challenging. An analysis of the extant literature reveals a disparate set of studies across each individual method, with no cross-method comparison based on empirical evidence. This systematic literature review compares the main large-scale agile methods, namely SAFe, LeSS, Scrum-at-Scale, DAD, and the Spotify model. It is the first study to analyse and compare each of the method’s principles, practices, tools, and metrics in a standardised manner. For each method, it presents not just the original method specifications but also all extensions and modifications to each method proposed by subsequent empirical research. It includes in this comparison not just commercial large-scale methods but also those that have been custom-built in organisations such as Nokia, Ericsson, and others. Based on the findings reported in this study, practitioners can make a more informed decision as to which commercial method or method component or, indeed, custom-built method is better suited to their needs. Our study reveals a number of theoretical and practical issues in the current literature, such as an emphasis on the practices of commercial frameworks at the expense of their underlying principles, or indeed any of the custom method. A set of challenges and success factors associated with the use of large-scale agile methods are identified. The study also identifies a number of research gaps to be addressed across methods.

Software startups develop innovative, software-intensive products or services. Such innovativeness translates into uncertainty regarding a matching need for a product from potential customers, representing a possible determinant reason for startup failure. Research has shown that experimentation, an approach based on the use of experiments to guide several aspects of software development, could improve these companies’ success rate by fostering the evaluation of assumptions about customers’ needs before developing a full-fledged product. Nevertheless, software startups are not using experimentation as expected. In this study, we investigated the reasons behind such a mismatch between theory and practice. To achieve it, we performed a qualitative survey study of 106 failed software startups. We built the eXperimentation Progression model (XPro), demonstrating that the effective adoption and implementation of experimentation is a staged process: first, teams should be aware of experimentation, then they need to develop an intention to experiment, perform the experiments, analyze the results, and finally act based on the obtained learning. Based on the XPro model, we further identified 25 inhibitors that prevent a team from progressing along the stages properly. Our findings inform researchers of how to develop practices and techniques to improve experimentation adoption in software startups. Practitioners could learn various factors that could lead to their startup failure so they could take action to avoid them.

[Context] Software startups are engines of innovation and economy, yet building software startups is challenging and subject to a high failure rate. They need to act and respond fast in highly uncertain business environments. To do so, they need to identify crucial and actionable information that supports them in making correct decisions and reduce uncertainty. So far, the software startup literature focused predominantly on what information to measure from a metrics perspective. Thus, there is a lack of research investigating how to deal with information from an analytics perspective.

Abstract Social loafing is a common issue encountered by many software development teams. In practice, agile software development teams often use team expectations agreements (TEAs), which contain rules to prevent social loafing behaviour. However, few studies in the software engineering literature examine how these rules are specified in TEAs and whether they serve the purpose. The authors intend to provide a better understanding on how to specify rules in TEAs to prevent social loafing behaviour in agile software development teams. A mixed‐method approach using both qualitative and quantitative data was employed. The results of our study show that agile software development teams specify the expectations of the whole team on meeting attendance and contribution, respect of tasks, roles and teammates, and collaboration with each other. These rules have the potential to prevent social loafing behaviours. However, specifying the rules in TEAs alone is not sufficient to make them effective. It needs to be complemented with team commitment to TEA rules. The work of the authors contributes to a better understanding of how to use TEAs to prevent social loafing in agile software development teams, and provides a conceptual basis for future research to investigate social loafing prevention using TEAs.

Developing soft skills as well as other non-technical issues is essential for a successful career in software engineering. Educators, practitioners and researchers are paying more attention to this matter as they understand its importance to a software development context. Even the IEEE/ACM software engineering guidelines has already pointed out the importance of working with real-world projects in order to develop such skills. Being technically competent is not enough; students should have opportunities to go beyond coding and experience interactions with real users in order to better prepare themselves for their future. In this sense, this paper presents a software engineering undergraduate program that connects students with real projects throughout its curriculum. In order to evaluate whether this program helps students into understanding the importance of connecting and interacting with real stakeholders, we performed a survey with 111 students from this program. Our results indicate that providing a structure throughout the program in which students actually work on real projects is beneficial for their soft skills development.

Background: Given the social aspects of Software Engineering (SE), in the last twenty years, researchers from the field started using research methods common in social sciences such as case study, ethnography, and grounded theory. More recently, case survey, another imported research method, has seen its increasing use in SE studies. It is based on existing case studies reported in the literature and intends to harness the generalizability of survey and the depth of case study. However, little is known on how case survey has been applied in SE research, let alone guidelines on how to employ it properly. Aims: This article aims to provide a better understanding of how case survey has been applied in Software Engineering research. Method: To address this knowledge gap, we performed a systematic mapping study and analyzed 12 Software Engineering studies that used the case survey method. Results: Our findings show that these studies presented a heterogeneous understanding of the approach ranging from secondary studies to primary inquiries focused on a large number of instances of a research phenomenon. They have not applied the case survey method consistently as defined in the seminal methodological papers. Conclusions: We conclude that a set of clearly defined guidelines are needed on how to use case survey in SE research, to ensure the quality of the studies employing this approach and to provide a set of clearly defined criteria to evaluate such work.

Startups are often seen as drivers of innovation. In an attempt to leverage this potential, larger business organizations have founded internal startups as a subset of internal corporate ventures (ICV). These smaller organizations are intended to be more agile than the parent organization, in order to produce new service and product innovations using their own methods and practices independently of the organizational culture and methods of the parent organization. However, our understanding of ICVs is still lacking in terms of processes and success factors, and especially the more recent internal startups have scarcely been studied thus far. To approach this novel area of research, we take on a qualitative approach by means of a multiple case study of internal startups in large companies. Based on the data, we argue that the origin of the idea of the internal startup heavily influences the processes utilized by the internal startup, as well as the connections between the internal startup and its parent organization. We also highlight various practical implications.

The Lean Startup methodology disseminated the concept of MVP. Since then, the term has been used in several contexts aside startups with a blur definition. Practitioners name several artifacts as MVPs, such as prototypes or initial versions of a new product, rather than an instrument for experimentation. Given the importance of experimentation to the success rate of software startups, it is essential to understand if the experimentation element is still present in practitioners' understanding of the term and how they applied MVPs. To achieve this objective, we performed a survey with practitioners and coded their answers according to aspects found in a systematic mapping study on MVP. Our results indicate that MVP is mostly associated with the ideas of a product version and customer value rather than hypothesis testing and learning processes. Additionally, those respondents that focused on the first related group of terms did not give experiments as examples of MVP. In contrast, the opposite happened to those that used the second group.

Software startups develop innovative products for which there are typically no customers to refer to elicit requirements. Often, these companies develop a set of features without a better understanding of customer needs. An experiment-based approach to validate hypotheses about the customer and market could increase their chance of success or, at least, accelerate their realization of the product worthlessness. The first step of an experiment-based approach is to elicit hypotheses to guide experiments. Software startups base their products on business assumptions, but there is a lack of understanding of how these assumptions are formed and how teams could elicit hypotheses systematically. To fill this gap, we performed an empirical study consisted of two steps. First, we explored based on which assumptions startups define their products using a multiple case study. The results indicate that these companies developed their products based on founders’ assumptions derived from their previous experience. Second, we investigated cognitive mapping as a tool to elicit hypotheses systematically with two software startups. The results indicate that this approach can serve as the basis of a method to elicit hypotheses in early-stage software startups.

Software Engineers work using highly diverse methods and practices, and general theories in software engineering are lacking. A recent attempt at creating a common ground in the area of software engineering methodologies has been the Essence Theory of Software Engineering. Essence is a method-agnostic progress management framework and a meta-method for Software Engineering (SE). However, tooling for Essence is still lacking. Without dedicated tools and other instruments, a meta-method such as Essence is cumbersome to utilize by practitioners and students. Indeed, Essence currently suffers from a lack of widespread practitioner adoption. In this paper, we thus present an Open Source tool for essentializing methods and practices: Essencery. We conduct a qualitative evaluation of the tool through a quasi-formal experiment and a set of semi-structured interviews. Based on this data, we improve Essencery iteratively before it is utilized in a large-scale project-based course as a proof of concept.

Internet-of-Things applications are not only the new opportunity for digital businesses but also a major driving force for the modification and creation of software systems in all industries and businesses. Compared to other types of software-intensive products, the development of Internet-of-Things applications lacks a systematic approach and guidelines. This paper aims at understanding the methodological commonalities among startups who are developing Internet-of-Things products. Using the SEMAT Essence framework, we captured common team compositions, common types of Minimum Viable Products and common way of working in early stage Internet-of-Things startups. We found that startups include various engineering and business competence, but do not cover all of what is needed. The development of Internet-of-Things applications adopts certain speed-favor approaches, i.e. rapid prototyping, iterative development and outsourcing. The finding implies some recommendations for both researchers and practitioners in the area of Internet-of-Things development.

The need of skills other than technical from software developers is becoming evident. The DevOps movement is an example of that applied to operational tasks. Startup development methodologies focus on business activities in innovative organizations. Several universities offer courses based on these methodologies to software engineering students, mainly to improve their creativity, problem solving, and business skills. This paper investigates how software engineering students learned startup development methodologies and discusses what are the challenges and benefits in their learning process. We conducted a multi-method study in three different universities. The data was collected in two phases and analyzed using thematic analysis. Our study reveals that students realized the importance of collaboration with other courses and the importance of user involvement in development. However, students tend to over-simplify concepts, trying to adapt them to what they are familiar with. The results indicate the necessity of business education for technical students and directions for improvements.

Context: Over the past 20 years, software startups have created many products that have changed human life. Since these companies are creating brand-new products or services, requirements are difficult to gather and highly volatile. Although scientific interest in software development in this context has increased, the studies on requirements engineering in software startups are still scarce and mostly focused on elicitation activities. Objective: This study overcomes this gap by answering how requirements engineering practices are performed in this context. Method: We conducted a grounded theory study based on 17 interviews with software startups practitioners. Results: We constructed a model to show that software startups do not follow a single set of practices but, instead, build a custom process, changed throughout the development of the company, combining different practices according to a set of influences (Founders, Software Development Manager, Developers, Market, Business Model and Startup Ecosystem). Conclusion: Our findings show that requirements engineering activities in software startups are similar to those in agile teams, but some steps vary as a consequence of the lack of an accessible customer.

[Context] Advancement in technologies, popularity of small-batch manufacturing and the recent trend of investing in hardware startups are among the factors leading to the rise of hardware startups nowadays. It is essential for hardware startups, companies that involve both software and hardware development, to be not only agile to develop their business but also efficient to develop the right products. [Objective] We investigate how hardware startups achieve agility when developing their products in early stages. [Methods] A qualitative research is conducted with data from 20 hardware startups. [Result] Preliminary results show that agile development is known to hardware entrepreneurs, however it is limitedly adopted. We also found four categories of tactics: (1) strategy, (2) personnel, (3) artifact and (4) resource that enable hardware startups agile in their early stage business and product development. [Conclusions] Agile methodologies should be adopted with the consideration of specific features of hardware development, such as up-front design and vendor dependencies.

This extended abstract summarises an article, which has been published in the Information and Software Technology (IST) Journal and was selected for the Journal-First presentations at the International Conference on Software and System Process (ICSSP 2018). Full Article Reference. Henry Edison, Xiaofeng Wang, Ronald Jabangwe, and Pekka Abrahamsson. 2018. Innovation Initiatives in Large Software Companies: A Systematic Mapping Study. Information and Software Technology, 95:1--14, (March 2018) DOI:10.1016/j.infsof.2017.12.007.

To keep the competitive advantage and adapt to changes in the market and technology, companies need to innovate in an organised, purposeful and systematic manner. However, due to their size and complexity, large companies tend to focus on maintaining their business, which can potentially lower their agility to innovate. This study aims to provide an overview of the current research on innovation initiatives and to identify the challenges of implementing the initiatives in the context of large software companies. The investigation was performed using a systematic mapping approach of published literature on corporate innovation and entrepreneurship. Then it was complemented with interviews with four experts with rich industry experience. Our study results suggest that, there is a lack of high quality empirical studies on innovation initiative in the context of large software companies. A total of 7 studies are conducted in such context, which reported 5 types of initiatives: intrapreneurship, bootlegging, internal venture, spin-off and crowdsourcing. Our study offers three contributions. First, this paper represents the map of existing literature on innovation initiatives inside large companies. The second contribution is to provide an innovation initiative tree. The third contribution is to identify key challenges faced by each initiative in large software companies. At the strategic and tactical levels, there is no difference between large software companies and other companies. At the operational level, large software companies are highly influenced by the advancement of Internet technology. Large software companies use open innovation paradigm as part of their innovation initiatives. We envision a future work is to further empirically evaluate the innovation initiative tree in large software companies, which involves more practitioners from different companies.

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.

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 2 220 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.

[Background] A high-functioning team is a decisive factor for a successful software development project. However building such a team is not easy. Among many issues and obstacles encountered by teams, social loafing is a common but difficult one to tackle. [Aim] We intend to construct an approach to effectively prevent social loafing behaviors in software development teams. [Method] We built one social loafing prevention approach based on existing literature and survey instruments. It has been applied in an educational context with 2nd-year computer science students working on software development projects in teams. [Results] The approach starts with increasing team members' awareness of social loafing. Team Expectations Agreement (TEA) is then used to help the team to write down the terms that explicitly prevent social loafing. During the project, a small survey instrument is used to track regularly if the specified terms are followed by the team members. At the end of a period, the presence/absence of social loafing is assessed by the team using another short survey. How to interpret the results of the surveys is explained as part of the presented approach. [Conclusions] This approach has potential to improve team-work skills of students, which is not adequately addressed in higher education programs. Meanwhile it can be adapted in professional software development environments to prevent social loafing and improve teamwork. The next step of our study will be using the collected data to evaluate the proposed approach, and formulating a set of recommendations to use the approach in the professional software development context.

Requirements elicitation is the first crucial stage of a requirements engineering process, which intends to uncover, acquire and elaborate requirements for software systems. When software startups are concerned, requirements elicitation is particularly challenging due to the high uncertainty that a startup is confronted with. Few studies have investigated how software startups conduct requirements elicitation and what techniques are used in such a context. This study intends to address this knowledge gap. Three software startups from different part of the globe were studied. The findings reveal that the requirements elicitation process in startups is primordial and mainly informal, and it is an ongoing process alongside with product evolution. Software startups do employ established requirements elicitation techniques including interviews, prototyping and brainstorming. They also utilize other less common ones such as competitor analysis, collaborative team discussion and use of model users. This study highlights the market-driven nature of requirements that software startups have to deal with, and offers the first insights on the requirements elicitation techniques that could be relevant and applicable in the context of software startups.

It is essential for startups to quickly experiment business ideas by building tangible prototypes and collecting user feedback on them. As prototyping is an inevitable part of learning for early stage software startups, how fast startups can learn depends on how fast they can prototype. Despite of the importance, there is a lack of research about prototyping in software startups. In this study, we aimed at understanding what are factors influencing different types of prototyping activities. We conducted a multiple case study on twenty European software startups. The results are two folds; firstly we propose a prototype-centric learning model in early stage software startups. Secondly, we identify factors occur as barriers but also facilitators for prototyping in early stage software startups. The factors are grouped into (1) artifacts, (2) team competence, (3) collaboration, (4) customer and (5) process dimensions. To speed up a startup’s progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototyping.

Software startups operate under various uncertainties and the demand on their ability to deal with change is high. Agile methods are considered a suitable and viable development approach for them. However, the competing needs for speed and quality may render certain agile practices less suitable than others in the startup context. The adoption of agile practices can be further complicated in software startups that adopt the Lean Startup approach. To make the best of agile practices, it is necessary to first understand whether and how they are used in software startups. This study targets at a better understanding of the use of agile practices in software startups, with a particular focus on lean startups. Based on a large survey of 1526 software startups, we examined the use of five agile practices, including quality related (regular refactoring and test first), speed related (frequent release and agile planning) and communication practice (daily standup meeting). The findings show that speed related agile practices are used to a greater extent in comparison to quality practices. Daily standup meeting is least used. Software startups who adopt the Lean Startup approach do not sacrifice quality for speed more than other startups do.

Editorial article Since the publication of Agile Manifesto in 2001, agile methods have transited from a grass- root initiative among enthusiastic advocates and developers to a mainstream software development approach adopted by both small and large companies worldwide. Meanwhile research on agile methods has grown rapidly and steadily into an established research area, evidenced by dedicated conferences (e.g., XP conference series, research track of previous Agile Conference series), special issues and sections in top Information Systems and Software Engineering journals. However, practitioners and consultants have largely driven the advancement in agile field, and agile research has lagged behind practice in the past. Has this situation changed as both agile methods and research community become increasingly mature? To be able to answer such questions, there is a constant need to check what interest agile practitioners and what agile researchers are investigating, to make sure that the states of the art and practice are aligned properly.

Product innovation is a risky activity, but when successful, it enables large software companies accrue high profits and leapfrog the competition. Internal startups have been promoted as one way to foster product innovation in large companies, which allows them to innovate as startups do. However, internal startups in large companies are challenging endeavours despite of the promised benefits. How large software companies can leverage internal startups in software product innovation is not fully understood due to the scarcity of the relevant studies. Based on a conceptual framework that combines the elements from the Lean startup approach and an internal corporate venturing model, we conducted a case study of a large software company to examine how a new product was developed through the internal startup effort and struggled to achieve the desired outcomes set by the management. As a result, the conceptual framework was further developed into a Lean startup-enabled new product development model for large software companies.

Software startups are challenging endeavours, with various road blocks on their path to success. The current understanding of the challenges that software startups may encounter is very limited. In this paper, we use the research framework of learning and product development stages to analyse the key challenges that software startups have to deal with at different life cycle stages, from problem definition to solution validation and from concept to mature product. Based on an analysis of the empirical data collected by a large survey of 4100 startups, we find out that what perceived as biggest challenges by software startups do vary across different life cycle stages. Building product is the biggest obstacle for software startups, even though its significance decreases when the learning focuses of the startups move from problem to solution and their products mature. Business related challenges such as customer acquisition and scaling are more noticeable at the later stages. Our study raises the awareness of these challenges and suggests to tackle right challenges at the right time.

A growing number of companies are discovering that their software development processes must be in compliance with some form of regulation. This is particularly so when it comes to safety-critical or business-critical systems such as Automotive Software, Robotics, Medical Devices or Finan- cial Management systems. These regulations aect the soft- ware development process itself in various forms. Further- more, much attention is being given to ways of improving the eciency of businesses, for example, by adopting lean principles. This raises the question for how to adopt lean principles for software development within a regulated envi- ronment? This poster presents the results of our empirical research into lean and regulated software development. Built from a combination of data sources, we have developed a conceptual framework comprising ve primary components. In addition the relationships they have with both the central focus of the framework (the situated software development practices) and with each other are indicated.

Abstract Software engineering (SE) research lacks theory and methodologies for addressing human aspects in software development. Development tasks are undertaken through cognitive processing activities. Affects (emotions, moods, and feelings) have a linkage to cognitive processing activities and the productivity of individuals. SE research needs to incorporate affect measurements to valorize human factors and to enhance management styles. The objective of this study is to analyze the affects dimensions of valence, arousal, and dominance of software developers and their real‐time correlation with their self‐assessed productivity (sPR). A repeated measurements design was conducted with eight participants (four students and four professionals), conveniently sampled and studied individually over 90 min of programming. The analysis was performed by fitting a linear mixed‐effects (LME) model. The results showed that valence and dominance are positively correlated with the sPR. The model was able to express about 38% of deviance from the sPR. Many lessons were learned when employing psychological measurements in SE and for fitting LME. This article demonstrates the value of applying psychological tests in SE and echoes a call to valorize the human individualized aspects of software developers. It reports a body of knowledge about affects, their classification, their measurement, and the best practices to perform psychological measurements in SE with LME models. Copyright © 2014 John Wiley & Sons, Ltd.

We present our ongoing work building a Raspberry Pi cluster consisting of 300 nodes. The unique characteristics of this single board computer pose several challenges, but also offer a number of interesting opportunities. On the one hand, a single Raspberry Pi can be purchased cheaply and has a low power consumption, which makes it possible to create an affordable and energy-efficient cluster. On the other hand, it lacks in computing power, which makes it difficult to run computationally intensive software on it. Nevertheless, by combining a large number of Raspberries into a cluster, this drawback can be (partially) offset. Here we report on the first important steps of creating our cluster: how to set up and configure the hardware and the system software, and how to monitor and maintain the system. We also discuss potential use cases for our cluster, the two most important being an inexpensive and green test bed for cloud computing research and a robust and mobile data center for operating in adverse environments.

Agile systems development methods emerged as a response to the inability of previous plan-driven approaches to handle rapidly changing environments (Highsmith, 2002). Originating from the so-called...