Discovering the Chimera of (Un)Happiness in Agile Software Development Communities: A Systematic Literature Review

Abstract

Agile approaches have gradually and widely gained adoption in the software industry, emphasizing the importance of individuals within software communities over processes or tools. In this context, ensuring the well-being of professionals is essential, positively impacting their quality of life and promoting their happiness. While some solutions exist to study happiness and unhappiness in agile work communities, there is still limited evidence regarding their causes, impact, consequences, and overall understanding. As a result, this article presents a state-of-the-art analysis aimed at understanding the causes and consequences of happiness and unhappiness and how these aspects influence or contribute to the rise of social debt. A systematic literature search identified 1713 studies, of which 27 were selected as primary. These articles allowed for answering the five formulated research questions. The analysis identified 189 causes, of which 65 are related to happiness, organized into 48 social, 16 procedural, and 1 technical, while 125 are linked to unhappiness, classified as 47 social, 65 procedural, and 12 technical. Additionally, 96 consequences were identified, of which 35 correspond to happiness, distributed as 27 social, 5 procedural, and 3 technical, while 61 are associated with unhappiness, categorized as 36 social, 19 procedural, and 6 technical. Additionally, 10 challenges and proposals for future research were identified. This study classifies existing and future approaches to improving happiness and well-being in agile teams. It provides a comprehensive perspective on how these factors affect the work environment and their role in mitigating social debt within software development.

1. Introduction

In the last decade, there has been a growing interest in the psychological and emotional well-being of professionals who are part of software development communities and how these aspects influence the success of projects [1], the quality of the product, interaction with other members and software communities, and within themselves [2]. Sociotechnical decisions made in projects and organizational structures can influence the well-being of development communities. In this regard, the social connotation can change the way people work and how they interact with other members of their development community [3,4,5], e.g., the transition from a vertical to a horizontal work structure with the adoption of an agile approach like Scrum, or changes in the development process from a traditional agile approach like Scrum to a scaled agile framework such as Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), and others. On the other hand, the technical connotation changes the way tasks are carried out during the software development lifecycle; e.g., agile approaches place more value on delivering working software and customer value than on the exhaustive documentation required by more heavyweight approaches [6]. The Royal Spanish Academy (RAE) defines happiness as “A state of pleasant physical, mental, and spiritual satisfaction”.

Additionally, it is essential to highlight the definition proposed by Diener and Diener [7], who describe happiness as well-being and the positive evaluation an individual makes of their own life. Likewise, the authors of [8] consider that positive emotions can transform individuals but can also have an impact at the organizational level. In particular, they argue that individual positive emotions can contribute to transforming organizations and communities, as a person’s thoughts, feelings, and moods influence others within a social interaction.

Another relevant definition of happiness is the one proposed by Lu [9], who argued that it can be summarized as follows:

• Happiness is a complex mental process that encompasses positive emotions and an optimistic outlook on the future.
• Happiness is a harmonious state in which individuals maintain a positive relationship with themselves and the external world.
• Happiness and unhappiness are interconnected and mutually influence each other.
• Particular virtues, such as gratitude, generosity, and transcendence, are essential for achieving happiness.

Throughout this paragraph, the concept of happiness has been discussed, but it is also relevant to consider the idea of unhappiness. According to the Dictionary of the Spanish Language of the Royal Spanish Academy (RAE), unhappiness is defined as “misfortune, adverse luck”. This definition emphasizes that adverse situations affect a person’s well-being. On the other hand, the authors of [2] indicate that people can experience unhappiness for various reasons, such as poverty, unemployment, family disintegration, or physical illness.

Incorrect sociotechnical decisions can negatively impact software development communities and generate additional costs for software projects [10]. These additional costs generally stem from SD, which is generated by low levels of well-being within a development community. According to [11], this can be defined as a suboptimal software community or an inferior community characterized by some psychological behavior alterations, soft skills, and attitudes that do not reach the desired levels for successful software projects. In this sense, a software community with SD (hereinafter referred to as SD) is a suboptimal software community that generates additional costs in projects, which often go unnoticed and are generally postponed, ignoring that the cost increases as the suboptimal community participates in more projects [11]. According to [12], the additional costs and rework due to social presence in suboptimal software communities can be comparable to technical debt.

Due to the erratic and unpredictable nature of software development communities and the importance of proper SD management for the success of software projects [11], there is a need for further exploration in this field, considering not only the technical aspects of software development but also the social, psychological, and emotional aspects, which still lack the attention they deserve or are not addressed in greater detail [13].

1.1. Lack of Existing Articles

To the best of our knowledge, no comprehensive study on research related to unhappiness and happiness in Agile Software Development Communities exists. Studies related to the topic of welfare and SD in software development communities encompass a variety of perspectives that contribute to the knowledge of the field.

From a broader perspective, the study [14] offers an empirical view of factors affecting software experiments, highlighting the role of social interactions in technical outcomes. In [15], social, process, and people debts are analyzed, identifying challenges and proposing strategies to mitigate these problems in organizations. Likewise, in [16], the authors’ interest in a specific well-being problem known as burnout syndrome is presented, which shows the results obtained through a systematic mapping that identifies its causes and consequences and highlights its impact on productivity and team morale. These works differ from our study, which comprehensively analyzes the causes and consequences of happiness and unhappiness in agile communities. This study proposes a comprehensive classification of 189 causes and 96 consequences, identifying key challenges and future research directions. Unlike previous work, our approach combines a holistic view with practical actions to guide researchers and practitioners in improving the well-being and effectiveness of development communities.

Other conceptual and prominent studies in the context of unhappiness and happiness in agile software development communities address related issues; however, they are outside the scope and specific objectives of our study. In [11], the term “SD“ is conceptualized in the context of software engineering, establishing a theoretical basis on how organizational and technical dynamics affect developing communities. This framework is extended in S12, which specifically explores sources of satisfaction in agile contexts, providing a practical approach to improving the emotional well-being of teams.

In the realm of emotional states, [17] investigates how technical debt affects developers’ affective states, using a psychometrical approach that connects technical aspects with psychological well-being. Meanwhile, [18] examines onboarding strategies in agile teams, emphasizing improving initial productivity and cultural fit and linking onboarding practices to team performance.

1.2. Goals and Contributions

As a result, the objective of this systematic literature review (hereinafter SLR) was to identify and gather primary studies through a basic search string focused on the happiness and unhappiness of agile software development communities. Furthermore, it establishes the geographic distribution of the primary studies, examines the main scientific initiatives on SD in agile software development communities, which have been found and categorized using the classification scheme proposed by Wieringa et al. [19], and collects relevant information such as definitions, concepts, the quality of the primary studies, citation counts, causes, consequences, challenges, future work, and existing contributions. The defined basic search string was adapted and applied over an 11-year period, from 2013 to 2024, and was used in six search engines: IEEEXplore, SpringerLink, Scopus, Google Scholar, Science Direct, and Web of Science. After analyzing the information gathered from the selected primary studies, it became evident that, although there is a limited number of studies related to happiness and unhappiness in agile work communities, interest in this topic has grown significantly in recent years due to its influence on critical aspects related to the quality of life (physical, mental, and spiritual health) of professionals within software development communities, and how these aspects positively or negatively impact the value of the deliverables and project costs [8,10,17,18,19,20].

Additionally, the SLR revealed that there are causes and consequences related to happiness and unhappiness in development communities. However, most identified causes and consequences in the literature are ambiguous or lack a formal definition. This means that the community’s perception can be subject to different interpretations, be uncertain, and even generate confusion. For example, two or more causes (or consequences) may have similar names but refer to entirely different aspects, or they may refer to similar elements but have different names. Moreover, it is important to mention that a large portion of the identified literature focuses on the negative impact of poor or nonexistent management of SD or certain social, psychological, and emotional aspects of software communities. For example, the focus of the identified studies is primarily on unhappiness, which reveals that the literature has identified issues related to SD in software development communities that were not previously considered. This provides a different perspective, where individuals are not only viewed as tools with technical knowledge and skills capable of achieving organizational objectives through high-quality standards and continuous value delivery in the products developed, but also as individuals with emotions and feelings who are affected by their environment, interpersonal relationships, mental health, and the work they perform. On the other hand, it is also important to highlight that no studies were found that present concrete results regarding the percentage of happiness achieved in companies that use complex organizational structures, such as remote work and/or global software development, where physical contact and personal interactions are practically nonexistent [11,21]. Similarly, the studies identified in the literature tend to approach happiness as a means for development communities to be more productive. Still, they do not delve into the mechanisms, strategies, or elements necessary to achieve or manage it.

This SLR is structured as follows: Section 2 presents the research protocol used for the SLR and the execution of the information search. Section 3 presents the results obtained by answering the research questions. Section 4 discusses the results, the main observations, the limitations of the review, and the significance of this research. Finally, Section 5 presents the conclusions and future work.

2. Materials and Methods

SLRs allow the collection and categorization of existing information and knowledge on a specific research topic by classifying and counting contributions in the literature. They provide insight into which topics have been covered in the literature and where they have been published [22,23] and consist of four stages: (i) applying the GQM (Goal, Question, Metric) approach; (ii) defining the search and selection strategy; (iii) conducting the review; and (iv) reporting the review. Figure 1 outlines the activities carried out in the SLR, where input and output artifacts from the process are also shown. In the following sections, a detailed explanation of the activities is provided: (i) definition of the search objectives and research questions; (ii) definition of the search strategy; (iii) definition of the selection criteria for primary studies; (iv) definition of the quality assessment criteria; (v) definition of the data extraction strategy; and (vi) selection of the synthesis methods [24,25].

2.1. Definition of Search Objectives and Research Questions

To properly focus the research efforts in the SLR, four search objectives (SO) and a set of research questions were defined, following the approach proposed by Basili and Calera [26], known as the Goal-Question-Metric (GQM) approach. This approach proposes a measurement model composed of three levels of abstraction: (i) Conceptual (Goal), (ii) Operational (Question), and (iii) Quantitative (Metric).

At the conceptual level, the objectives were defined to establish, understand, and identify the purpose of the SLR to be conducted. Subsequently, at the operational level, a set of questions was designed based on the objectives obtained at the conceptual level. These questions aimed to focus, characterize, and structure the evaluation of the primary studies identified and related to (un)happiness in agile software communities. The GQM approach suggests establishing a set of metrics related to each question that allow measuring specific aspects associated with a project; however, in this SLR, the metrics suggested by the GQM approach will be developed in future work.

The conceptual search objectives (SO) established for the SLR are as follows:

• Objective 1. Provide basic information, define the scope from a demographic perspective, and allow the identification of relevant sources of information and research in the field of SD in agile software project development from the perspective of happiness or unhappiness in communities.
• Objective 2. Help researchers and stakeholders understand the quality, validation, processes, and methods used by the authors of the studies found.
• Objective 3. Identify the state of development of the proposals in terms of the results obtained.
• Objective 4. Identify the main research trends, ongoing work, and future work related to SD in agile software project development from the perspective of happiness or unhappiness in communities.

Based on the search objectives, five (5) research questions (RQ) were defined along with their respective motivations. The RQs aimed to segment the information found on (un)happiness in agile software communities, thereby supporting the identification of existing research gaps (see

Table 1. Research questions.

Id.	Research Question	Motivation
1	What type of research has been conducted?	To determine the type of research being conducted according to the classification scheme proposed by [27]: validation research, evaluation research, solution proposal, philosophical studies, opinion papers, or experience studies.
2	What are the causes that generate happiness and/or unhappiness in agile software development communities?	To identify the causes of happiness and/or unhappiness presented in the literature.
3	How does happiness or unhappiness impact software development?	To determine how software development is affected by the happiness and/or unhappiness of work communities.
4	Are there any proposed contributions to mitigate unhappiness in work communities within software projects?	To identify the type of contribution, such as a catalog, process, method, or tool.
5	What are the challenges/future work proposed in the analyzed studies?	To identify possible future research directions and the challenges presented in the analyzed studies.

Acronyms used: Identifier (Id.), Inclusion Criteria (IC).

). The results for Objective 1 are presented in Section 3.1 and Section 3.2.

It is important to highlight that the search for articles was conducted manually, applying the filters established in each scientific database and following the predefined inclusion and exclusion criteria. Additionally, the search string was adapted to each search engine to optimize the retrieved results. During the manual review of the selected articles, new keywords were identified, allowing for the refinement of the search strategy, improved interactions, and an expanded number of relevant contributions on the topic.

This methodology was chosen due to the expertise and specialized knowledge in conducting Systematic Literature Reviews (SLR). The advantages of performing a manual SLR include:

(i)

Greater objectivity and scientific rigor;

(ii)

Clarity in identifying relevant articles;

(iii)

Comprehensiveness in synthesizing the obtained results;

(iv)

Ease of team discussions regarding the analysis of results and existing gaps;

(v)

Informed and consensus-based decision-making by the entire team.

However, conducting a manual SLR also presents challenges. One of the main limitations is the absence of automated tools, such as generative AI or specialized search engines, which significantly increased the time required to complete the process, totaling nine months. This may lead to an outdated list of primary articles due to the publication of new studies. Additionally, more checkpoints within the team were required to ensure informed and consensus-based decision-making, demanding additional time and availability, which could occasionally result in delays.

2.2. Search Strategy

To conduct the search, a combination of terms or keywords was employed, identified through a preliminary reading and review of documents provided by experts on (un)happiness in agile software communities. The combination of keywords was formulated using the logical connectors “AND” and “OR”, which yielded the following basic search string: (“agile software development” OR “agile development” OR “agile approach” OR “agile project”) AND “debt” AND (unhappiness OR happiness).

Additionally, studies on this topic published between 2013 and 2024 were considered, as the concept of SD is linked to the well-being of software development communities and, consequently, to their happiness and unhappiness. Since SD was first defined in 2013 by Tamburri et al. [11], the search for primary articles was conducted from 2013 to the present year. Similarly, six (6) databases were consulted, including IEEE Xplore, SpringerLink, Scopus, Google Scholar, Science Direct, and Web of Science, where the search string was adapted for each database. In addition, articles found in gray literature were included, also known as non-conventional, semi-published, invisible, minor, or informal literature, which refers to any type of document not disseminated through regular commercial publication channels.

2.3. Inclusion and Exclusion Criteria

The studies found were evaluated according to five aspects (i) title, (ii) abstract, (iii) keywords, (iv) introduction, and (v) conclusions, to decide whether they should be included among the relevant studies. Subsequently, the relevant studies resulting from the first filter were analyzed in detail to identify the primary studies. For this, a full-text review was conducted to determine if the article met at least one of the inclusion criteria (IC) presented in

Table 2. Inclusion criteria.

Id.	Inclusion Criteria (IC)
IC1	Articles in English that refer to SD in agile software projects.
IC2	Full articles published between 2013 and 2024 in peer-reviewed, prestigious journals, conferences, congresses, or workshops.
IC3	Articles whose main topic is happiness and/or unhappiness in agile software development communities and projects.
IC4	Articles that address topics related to technical debt.
IC5	Articles published in peer-reviewed, prestigious journals, congresses, or conferences.

Acronyms used: Identifier (Id.), Inclusion Criteria (IC).

. On the other hand, studies that met any of the exclusion criteria (EC) presented in

Table 3. Exclusion criteria.

Id.	Exclusion Criteria (EC)
EC1	Duplicate articles (considering only the most complete and recent one available).
EC2	Articles that address the research topic in a superficial manner.
EC3	Articles that do not address issues related to happiness and/or unhappiness in agile software development communities and projects.
EC4	Articles in the form of debates or only available as presentations or abstracts.
EC5	Articles that are books or book chapters.
EC6	Articles with restricted access.

Acronyms used: Identifier (Id.), Exclusion Criteria (EC).

were not considered.

2.4. Relevance and Significance Evaluation Criteria

Evaluating the relevance and significance of primary articles is crucial for minimizing biases and maximizing the internal and external validity of research [25]. Following this premise, and with the aim of maintaining scientific rigor in the investigation, the relevance and significance of the selected primary studies were assessed using an adaptation of the instrument proposed by Kitchenham & Charters [25], Kitchenham et al. [28], and the categories proposed by Dybå y Dingsøyr [29]. Six criteria were defined and grouped into three categories described below (the six criteria in question format are presented in

Table 4. Criteria for evaluating the quality of primary studies.

Category	Id.	Criteria	Scoring for Responses
			+1	0	−1
Content Relevance	1	The study clearly addresses SD in the development of agile software projects from the perspective of happiness and/or unhappiness in agile software development communities.	Yes	Partially	No
	2	The study proposes a set of elements to identify and mitigate unhappiness in agile software development communities.	Yes	Partially	No
Scientific Rigor and Validity	3	The study validates the presented proposal.	Through a case study	Through a focus group	Not validated
	4	The study clearly presents the results obtained after applying the presented proposal.	Yes	Partially	No
Academic Impact and Recognition	5	The study has been published in a relevant journal, conference, or congress. The Scimago quartile rankings “https://www.scimagojr.com (accessed 17 December 2023)” were used for journal classification, and the Computing Research & Education CORE, “https://portal.core.edu.au/conf-ranks/ (accessed 17 December 2023)” rankings for conferences and congresses.	Highly relevant (Q1 for journals and A* for conferences and congresses)	Relevant (Q2 and Q3 for journals and A or B for conferences and congresses)	Not relevant (Q4 for journals and C or unranked for conferences and congresses)
	6	The study has been cited by other authors.		Cited by one to five authors	Not cited

, where the related category for each criterion can also be found):

• Content Relevance: This category evaluates the study’s pertinence in relation to the research topic and its theoretical or practical contribution to the field of study. It focuses on how clearly the study addresses specific aspects of the investigated topic and how these aspects are relevant to the academic or professional community [30,31].
• Scientific Rigor and Validity: This category assesses the methodological soundness of the study and the validity of its results. It emphasizes the rigor of the research design, the appropriateness of the methods used, and the clarity in presenting the results, including how the study’s proposal is validated [30,32].
• Academic Impact and Recognition: This category evaluates the study’s impact within the academic community and its recognition in the field. This includes the quality of the publication (measured through indexes such as Scimago quartiles and CORE rankings) and how frequently the study has been cited by other researchers [33,34].
• Additionally, to assess the quality of the selected studies, a questionnaire was designed with a scoring system of three values: (−1) the study does not address the research questions posed, (0) the study partially addresses each research question, (+1) the study explicitly answers the research questions, based on the evaluation artifact proposed by Kitchenham et al. [25].

2.5. Data Extraction Strategy and Synthesis Methods

Table 5. Summary sheet for studies.

Identification
Title:
DOI:		Number of Citations
Publication Date	Conference/Journal
Authors
Name	Country	University
Abstract
Description
Type of Research (Classification from [11]): ☐ Validation ☐ Evaluation ☐ Solution ☐ Philosophical Study ☐ Opinion Study ☐ Experience Study
Type of Solution(s) Offered: ☐ Conceptual Definition ☐ Causes, Effects, Impacts, and Limitations ☐ Technological Tools ☐ Validation in Industry ☐ Documentation Methodologies
Proposal:
Evaluation of the Proposal:

presents the design of the summary sheet used to facilitate the classification process of information and the key aspects considered for each primary study. This allowed for uniform data extraction and information classification. Additionally, the relationship between the primary studies and the defined research questions (RQ) was established (see Table 1). It is important to emphasize that the summary sheet was designed considering each author’s perspective, the research objectives and questions, as well as the criteria of relevance and pertinence, in order to avoid biases and inconsistencies. The attributes referenced in the sheet allowed for answering each of the formulated research questions, in addition to including some demographic aspects necessary to ensure the relevance and timeliness of the topic.

3. Execution Section

Six (6) iterations were conducted, one for each of the databases used in the search: IEEEXplore, SpringerLink, Scopus, Google Scholar, Science Direct, and Web of Science, as well as gray literature. The search string was adapted according to the specific characteristics of each database (see

Table 6. Adaptation of the search string for each database.

#	Search String	Source	Search Date
1	(“Full Text & Metadata”: “agile software development”) OR (“Full Text & Metadata”: “agile development”) OR (“Full Text & Metadata”: “agile approach”) OR (“Full Text & Metadata”: “agile project”) AND (“Full Text & Metadata”: “debt”) AND (“Full Text & Metadata”: unhappiness) OR (“Full Text & Metadata”: happiness) Filters Applied: Conferences, Journals, Maga-zines, 2013–2024	IEEE Xplore	12 July 2024
2	“agile software development” OR “agile development” OR “agile approach” OR “agile project”) AND “debt” AND (unhappiness OR happiness) within Computer Science, Conference Proceedings, 2013–2024	SpringerLink	12 July 2024
3	TITLE-ABS-KEY ((“agile software development” OR “agile development” OR “agile approach” OR “agile project”) AND “debt” AND (unhappiness OR happiness)) AND PUBYEAR > 2012 AND PUBYEAR < 2024	Scopus
4	(“agile software development” OR “agile development” OR “agile approach” OR “agile project”) AND “debt” AND (unhappiness OR happiness) Specific interval… 2013–2024	Google Scholar	12 July 2024
5	(“agile software development” OR “agile development” OR “agile approach” OR “agile project”) AND “debt” AND (unhappiness OR happiness) Year(s): 2013–2024	Science Direct	12 July 2024

). Additionally,

Table 7. Search results.

#	Data Source	Studies Found	Relevant Studies	Primary Studies Selected
1	IEEEXplore	1335	20	20
2	SpringerLink	35	0	0
3	Scopus	8	1	1
4	Google Scholar	332	6	6
5	Science Direct	4	1	1
6	Web Of Science	0	0	0
TOTAL		1713	27	27

presents the total number of primary studies found, the total number of studies retrieved, and the relevant studies. The compendium of selected primary studies is shown in

Table 8. Compendium of primary studies resulting from the search.

Id.	Article	NC	Year	Ref.
S1	What Is Social Debt in Software Engineering?	123	2013	[11]
S2	Using Experimental Games to Understand Communication and Trust in Agile Software Teams	17	2013	[35]
S3	A Social Complexity Approach to Investigate Trust in Agile Methodology	7	2014	[27]
S4	An Empirical Study into Social Success Factors for Agile Software Development	68	2015	[36]
S5	Sensing developers’ emotions: The design of a replicated experiment	3	2017	[37]
S6	Factors Influencing Productivity of Agile Software Development Teamwork: A Qualitative System Dynamics Approach	66	2017	[38]
S7	Professionals are not Superman: Failures Beyond Motivation in Software Experiments	4	2017	[14]
S8	Software Development Waste	122	2017	[39]
S9	Feeling Analysis for Sadness and Happiness using Google n-gram Database	2	2018	[40]
S10	Hiring Millennial Students as Software Engineers	23	2018	[41]
S11	Linking Personality Traits and Interpersonal Skills to Gamification Awards	14	2018	[42]
S12	Sources of Satisfaction in Agile Software Development	4	2018	[43]
S13	Team Resilience in Distributed Student Projects	7	2018	[21]
S14	Utilizing online collaborative games to facilitate Agile Software Development	25	2018	[44]
S15	Measuring affective states from technical debt: A psychoempirical software engineering experiment	5	2019	[17]
S16	Effective team onboarding in Agile software development: techniques and goals	35	2019	[18]
S17	On the Agile Mindset of an Effective Team—An Industrial Opinion Survey	46	2019	[45]
S18	Social Identity in Software Development	5	2019	[46]
S19	Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance	34	2020	[47]
S20	The Secret of Happy Families Regulating (Re)Productive Labor with Agile Family Management	0	2020	[48]
S21	The influence of Technical Debt on software developer morale	57	2020	[13]
S22	Digital Nudging for Technical Debt Management: Insights from a Technology-driven Organization	3	2020	[20]
S23	Predicting Community Smells’ Occurrence on Individual Developers by Sentiments	3	2021	[49]
S24	The Emotional Roller Coaster of Responding to Requirements Changes in Software Engineering	22	2022	[50]
S25	The Human Side of Software Engineering Teams: An Investigation of Contemporary Challenges	23	2022	[51]
S26	The Pandora’s box of social, process, and people debts in software engineering	2	2022	[15]
S27	Burnout in software engineering: A systematic mapping study	22	2022	[16]
S28	Creating Happier and More Productive Software Engineering Teams through AI and Machine Learning	0	2024	[52]

Acronyms used: Id = Study Identifier, NC = Number of Citations, Ref. = References.

, along with their titles, serving as a reference for readers to conduct a more in-depth search.

3.1. Demographic Analysis

Figure 2 presents the distribution of publication types for the primary studies. It shows that 50% (S3, S5, S6, S8, S9, S11, S12, S13, S14, S17, S22, S24, S25, and S28) of the related studies were presented and published at conferences, followed by 21.4% (S1, S2, S4, S7, S10, and S18) presented at workshops, 14.3% (S20, S21, S26, and S27) published in international journals, 3.6% (S16) presented at symposiums, 3.6% (S19) in scientific journals, 3.6% (S15) as a master’s thesis, and 3.6% (S23) published in a scientific web repository.

On the other hand, Figure 3 shows that the demographic distribution of the primary studies spans 18 countries and 4 continents as follows (references have been omitted for readability, please refer to Figure 3 for country-specific references): Oceania with 7% (2 articles, two countries: New Zealand and Australia), Asia with 11% (3 articles, 2 countries: Bangladesh and China), America with 14% (3 articles, 2 countries: USA and Canada), and Europe with 68% (16 articles, 12 countries: including the Netherlands, Poland, and the UK). The data suggests that Europe has the highest concentration of publications with 66.7% of the studies, indicating a significant research focus on this continent compared to others like America, Asia, and Oceania, which have much lower representation.

This disparity could be driven by various factors, such as the level of development in these countries, research funding, access to resources, or language barriers in publishing. The reader is encouraged to explore these variables in-depth, considering aspects such as publication impact, quality, and relevance within the field, as well as citation metrics.

Table 8 presents the citation count for each primary study, revealing variable significance and impact in the academic community. Some studies, like “What Is Social Debt in Software Engineering?” (S1) with 123 citations, and “Software Development Waste” (S8) with 122 citations, have garnered considerable attention, indicating widespread interest in these topics. While it is possible to find articles related to SD, a niche focus segment such as happiness and unhappiness remains smaller but has been gaining a larger number of studies and increased attention from the scientific community in recent years. Overall, the data reflect a disparity in the attention given to research on happiness and unhappiness in software development, which may be influenced by factors such as topic novelty, methodology, or perceived practical relevance in Software Engineering.

In summary, the NC column in Table 8 provides a clear view of the most influential topics and articles in the research on happiness and unhappiness in software development. The findings suggest that themes related to SD, productivity in agile teams, and developer morale are of particular interest and have sparked significant scientific debate. Although citation count is a useful metric for gauging impact, it should not be the sole criterion for determining the relevance or quality of an article. Other factors, such as methodological rigor, data recency, and journal reputation, should also be considered for a comprehensive evaluation. The next section will evaluate the relevance and pertinence of the primary articles using a set of established criteria.

3.2. Relevance and Pertinence Evaluation

Table 9. Evaluation of the studies based on relevance and pertinence criteria.

Id.	Criteria for Evaluating Relevance and Pertinence						Total
	C1	C2	C3	C4	C5	C6
S1	−1	−1	1	1	−1	1	0
S2	0	−1	1	1	1	1	3
S3	0	−1	1	1	−1	1	1
S4	−1	−1	1	1	−1	0	−1
S5	0	0	1	1	−1	0	1
S6	1	1	1	1	−1	1	4
S7	0	0	1	1	0	0	2
S8	0	−1	−1	1	−1	1	−1
S9	0	−1	1	1	−1	0	0
S10	0	−1	1	1	−1	1	1
S11	0	0	1	1	−1	1	2
S12	0	0	−1	1	0	0	0
S13	0	−1	1	1	1	1	3
S14	0	0	−1	0	−1	1	−1
S15	1	1	−1	0	−1	0	0
S16	1	−1	1	1	1	1	4
S17	1	0	1	1	−1	1	3
S18	0	−1	1	1	−1	0	0
S19	0	1	1	1	−1	1	3
S20	0	−1	1	1	−1	0	0
S21	0	0	−1	1	0	1	1
S22	0	−1	1	1	−1	0	0
S23	0	0	1	1	1	0	3
S24	0	1	1	1	1	1	5
S25	0	0	1	1	1	1	4
S26	1	0	1	1	0	0	3
S27	0	0	1	1	1	1	4
S28	1	0	1	0	−1	−1	0
Total	4	−8	18	25	−10	15

Acronyms Used: Quality Criterion (C).

presents the results of the evaluation of the studies according to the relevance and pertinence criteria established. Based on the six quality criteria defined in Table 4, each article can receive a negative (minimum) score of −6 points or a positive (maximum) score of 6 points. The total score for each article is obtained by summing the individual values for each of the criteria evaluated. Figure 4 shows the grouping of primary articles according to their total individual relevance and pertinence scores, where it can be observed that 4% of the studies (S24) have the highest score of 5 points, 14% of the studies (S6, S16, S25, and S27) have 4 points, 21% of the studies (S2, S13, S17, S19, S23, and S26) have 3 points, 7% of the studies (S7 and S11) have 2 points, 14% of the studies (S3, S5, S10, and S21) have 1 point (plus 1 point), 29% of the studies (S1, S9, S12, S15, S18, S20, S22, and S28) have 0 points, and 11% of the studies (S4, S8, and S14) have −1 point (minus 1 point). Table 9 presents the results of the evaluation of the studies based on the relevance and pertinence criteria outlined. According to the six quality criteria in Table 4, each article could receive a score ranging from −6 (minimum) to 6 (maximum). The total score for each article is the sum of individual scores across all criteria. Figure 4 groups the primary articles based on their overall relevance and pertinence score, where 4% of the studies (S24) achieved the highest score of 5 points, while 11% (S4, S8, and S14) scored −1 point (minus 1 point). Based on the analysis conducted, Figure 5 presents the scores obtained for the relevance and pertinence criterion, it is observed that criterion 4 achieved the highest score with 25 points, followed by criterion 3, which obtained 18 points, this allows us to conclude that, in the evaluated articles, the results and validation of the proposals are presented clearly and well-documented. On the other hand, criterion 2 scored −8, while criterion 5 reached −10 points. These findings highlight the need to publish and share the results in scientific events or conferences, as well as to deepen strategies for mitigating SD.

4. Results

The results obtained to answer each of the defined research questions are presented below in

Table 10. Compendium of the research questions addressed by each primary study.

Research Questions
Articles	RQ1	RQ2	RQ3	RQ4	RQ5
S1	1	1	1	0	1
S2	1	1	1	0	0
S3	1	1	1	0	0
S4	1	1	1	1	0
S5	1	1	1	1	1
S6	1	1	1	1	0
S7	1	0	0	0	0
S8	1	1	1	1	1
S9	1	0	0	0	0
S10	1	1	1	0	0
S11	1	1	0	0	0
S12	1	1	0	0	0
S13	1	1	1	1	1
S14	1	1	1	1	0
S15	1	1	1	0	0
S16	1	1	1	1	0
S17	1	1	0	0	1
S18	1	1	1	1	1
S19	1	1	1	0	0
S20	1	0	0	0	0
S21	1	1	1	0	1
S22	1	0	0	0	0
S23	1	1	1	1	1
S24	1	1	1	1	1
S25	1	1	1	1	1
S26	1	1	1	1	1
S27	1	1	1	0	1
S28	1	1	1	1	1
Total	28	24	21	13	13

Acronyms used: RQ = Research Question.

. These results are referenced to facilitate further in-depth study by the reader or interested parties. Most of the selected primary articles provided a significant contribution to addressing the research questions posed in this SLR; however, it is worth noting that although there are contributions regarding challenges and future work, the number of such contributions is low. In Figure 6, the scores obtained in response to the formulated research questions are detailed, with the following results: Question 1 achieved the highest score, with 28 points (100%), indicating that the type of research, according to Wieringa et al. [19] is clearly defined in the selected primary articles. On the other hand, Question 2 scored 24 points (87.5%), showing that the selected articles address the causes of happiness and unhappiness in software development teams. It is important to highlight that the lowest scores were obtained for Questions 4 and 5, emphasizing the need to delve deeper into strategies to mitigate the effects of happiness and unhappiness, as well as to contribute to the formulation of challenges and future research directions. It is worth noting that Questions 4 and 5 received the lowest scores, suggesting the need to delve deeper into strategies to mitigate the effects of happiness and unhappiness, as well as to contribute to the formulation of challenges and future work.

4.1. Q1: What Type of Research Was Conducted?

To answer this question, the classification scheme proposed by Wieringa et al. [19], as used, which defines six types of research according to their characteristics: (i) validation, studies where the investigated techniques are novel and have not yet been implemented in practice, such as experiments; (ii) evaluation, studies where the techniques are implemented and evaluated; (iii) solution, studies where a solution to a problem is proposed, which may be either novel or a significant extension of an existing technique; (iv) philosophical studies, studies that describe a new perspective on existing things by structuring the field taxonomically or within a conceptual framework; (v) opinion studies, studies that express a personal opinion on whether a technique is good or bad, or how things should be done, and finally; (vi) experience studies, studies that explain what and how something has been executed in practice based on personal experiences. Figure 5 presents the type of research (see right quadrant) conducted for each primary study. It was observed that 43% of the studies are evaluations (S3, S7, S8, S10, S11, S12, S15, S16, S19, S22, S24, and S25), 28.6% are validations (S2, S4, S5, S9, S20, S21, S23, and S28), and the remaining 28.6% are philosophical studies (S1, S6, S13, S14, S17, S18, S26, and S27). The left quadrant of Figure 7 also presents the grouping of the distribution of solution types, which is addressed in the next section.

Main findings (Research Question Q1)

The analysis shows that 43% of the studies focus on the evaluation of implemented techniques, 28.6% on the validation of new techniques, and 28.6% on philosophical studies that provide new perspectives. This suggests a significant focus on practical evaluation and conceptual exploration in the area studied.

4.2. Q2: What Is the Type of Solution Proposed?

Figure 8 (see left quadrant) presents the grouping and distribution of the different types of solutions proposed in the studies. According to the results, it can be observed that: 17 studies (60.7%) propose validations in the industry (S2, S3, S4, S5, S10, S11, S12, S13, S14, S15, S16, S17, S19, S21, S24, S25, and S28) through interviews (S15 and S21), models (S4, S5, and S28), surveys (S12, S13, S17, S24, and S25), experiments (S3, S8, S15, and S2), proposal evaluations (S10, S14), and data collection and analysis (S11 and S16); 5 studies (17.9%) propose conceptual definitions (S1, S8, S20, S26, and S27) aimed at providing a clearer overview of the subject matter; 3 studies (10.7%) describe causes, effects, impacts, and limitations (S6, S7, and S18) related to happiness and unhappiness in communities within the context of software engineering; 1 study (3.6%) proposes a method or evaluation technique (S9) to identify happiness or unhappiness through words; 1 study (3.6%) proposes a technological tool (S22) to support decision-making regarding technical debt management; and 1 study (3.6%) proposes a prediction model to identify potential “smelly” development communities (S23).

Although the primary articles focus on establishing a state of knowledge regarding the happiness and unhappiness of agile software communities through studies that focus on conceptual or theoretical aspects, as well as a proposed method, other types of solutions, such as processes, techniques, or practical models to address this issue in different ways, are not evidenced. Furthermore, although a tool has been developed to support decision-making, no studies were identified that propose methodological solutions or tools to diagnose software development communities and identify potential causes of unhappiness, and thus, take actions to mitigate or contain the emergence, risk, or threat, or to promote improvements in happiness indices in order to enhance the well-being of agile software development communities.

Additionally, based on Figure 8, there is a clear trend towards industrial validation as the predominant focus in the evaluated studies, which suggests a strong orientation toward practical application in the industry in recent years. However, the number of studies in other categories remains limited, which could indicate potential areas for future research to deepen the theoretical or methodological aspects of the solutions presented. This pattern highlights the academic emphasis on developing directly applicable solutions, although there is still room for the exploration of new tools and methods.

Main findings (Research Question Q2)

A total of 60.7% of the studies focus on practical validations in the industry, while 17.9% propose conceptual definitions. Despite some practical solutions, there is a lack of tools and methodologies to improve welfare in agile software communities. The trend towards industrial validation highlights opportunities for future theoretical and methodological research.

4.3. Q3: What Are the Causes That Generate Happiness and/or Unhappiness in Agile Software Development Communities?

Figure 9 is based on the information presented in

Table 11. Happiness causes identified in the primary studies.

#	Cause	#Ap	Reference Id.	Type
1	High satisfaction.	1	S21	Social
2	High motivation.	2	S6, S21	Social
3	Sense of progress.	2	S21	Social
4	Recognition.	2	S18, S21	Social
5	Good interpersonal relationships.	3	S14, S18, S21	Social
6	Teamwork.	2	S20, S21, S28	Social
7	Mutual aid.	2	S17, S21	Social
8	Developer pride as a result of continuous improvements in the software.	1	S21	Social
9	Ability to incrementally deploy engineered solutions.	1	S21	Procedural
10	Believe that the solution is simple.	1	S21	Procedural
11	Effectiveness of the implemented solution.	1	S21	Procedural
12	Knowledge of organizational culture.	1	S16	Procedural
13	Acceptance by people in the organization.	1	S16	Social
14	Efficacy.	1	S16	Social
15	Clarity of the role played.	1	S16	Social
16	Confidence.	4	S10, S16, S3, S2	Social
17	Mentoring.	1	S16	Social
18	Socialization among team members.	1	S16	Social
19	Awareness of the developer as a person.	3	S10, S16, S25	Social
20	Experience and skills of the team.	1	S6	Procedural
21	Processes used (software tools and methods).	1	S6	Procedural
22	Good team management.	1	S6	Procedural
23	Increased customer satisfaction.	1	S6	Social
24	Good communication.	4	S6, S13, S18, S2	Social
25	Good coordination.	1	S6, S13	Social
26	Adaptability.	1	S6	Social
27	Feedback.	1	S6, S28	Social
28	Leadership.	1	S6	Social
29	Self-management.	1	S6	Social
30	Mutual trust.	1	S17	Social
31	Cooperation.	1	S17	Social
32	Direct communication.	1	S17	Social
33	Sincerity.	1	S17	Social
34	Mutual respect.	1	S17	Social
35	Listen to each other.	1	S17	Social
36	Seeking solutions instead of culprits.	1	S17	Social
37	Joint responsibility.	1	S17	Social
38	Continuous improvement and learning.	1	S17	Social
39	Openness to change.	1	S17	Social
40	Positive attitude.	1	S17	Procedural
41	Openness to others.	1	S17	Social
42	Transparency.	1	S17	Social
43	Self-organization.	1	S17	Social
44	Ability to collaborate.	3	S17	Social
45	Maintain a constant pace of work.	1	S14, S17, S18	Social
46	Believe that the solution is simple.	1	S17	Procedural
47	Share knowledge and results.	1	S17	Procedural
48	Asking when there is not enough knowledge.	1	S17	Social
49	Implementation of agile development methodologies.	2	S12	Social
50	Implementation of collaborative processes.	1	S12, S14	Procedural
51	Self-organized teams.	1	S12	Procedural
52	Collective ownership of code.	1	S12	Procedural
53	Correct management of distributed teams.	1	S12	Procedural
54	Expertise.	1	S18	Procedural
55	Team spirit.	1	S18	Social
56	Resilience.	1	S13	Social
57	Forming a community.	1	S13	Social
58	Generate skills in developers.	1	S13	Social
59	Generate connections.	1	S13	Procedural
60	Commitment.	1	S13	Social
61	Consideration.	1	S13	Social
62	Proactive attitude.	1	S14	Social
63	Self-awareness of emotions.	1	S24	Social

and

Table 12. Causes of unhappiness identified in primary studies.

#	Cause	#Ap	Reference Id.	Type
64	Technical Debt (Discomfort with technical debt, frustration with technical debt, Being aware of technical debt).	4	S8, S21	Technique
65	Lack of progress (Feeling of stagnation, Feeling of little contribution or contribution).	3	S5, S10, S21	Procedural
66	Legacy code.	1	S21	Procedural
67	Lack of communication skills (poor communication, ineffective communication, asynchronous communication).	8	S16, S18, S8, S4, S25, S26, S27	Social
68	Build functionalities or products that are not required.	1	S8	Technique
69	Poor product backlog management.	1	S8	Procedural
70	Rework.	1	S8	Procedural
71	Work on many features at the same time.	1	S8	Procedural
72	Unnecessarily complex solutions (High code complexity).	2	S8, S23	Technique
73	Strange cognitive load.	1	S8	Technique
74	Silos of knowledge.	1	S8	Procedural
75	Suboptimal development communities.	2	S21, S23	Social
76	Waste of time.	1	S21	Procedural
77	Lack of motivation.	2	S21, S25	Social
78	Economic disadvantages.	1	S21	Social
79	Developer skills and habits.	2	S21, S25	Procedural
80	Emotions, moods, and feelings.	3	S21, S23	Social
81	Difficulty in showing the real value.	1	S21	Procedural
82	Unequal distribution of tasks.	1	S5	Procedural
83	Wrong estimation of the size and time required to complete a task.	1	S5	Procedural
84	Difficulties in solving a specific cognitive task.	1	S5	Procedural
85	Learning curve of a technology or programming language.	1	S5	Procedural
86	Awareness of time pressure.	3	S5, S25, S26	Procedural
87	Unexpected departures.	1	S5	Procedural
88	Unexpected use of libraries.	1	S5	Procedural
89	Documentation not available.	1	S5	Procedural
90	Poorly designed or executed (new developer) integration experiences.	2	S16, S26	Social
91	Social ingenuity.	1	S16	Social
92	Poor (new developer) integration.	1	S16	Social
93	Team management (lack of support for managing agile teams).	3	S6, S25	Procedural
94	Cultural differences.	3	S6, S25	Social
95	Motivation.	1	S6	Social
96	Equipment effectiveness.	2	S6, S4, S28	Procedural
97	Customer satisfaction.	1	S6	Social
98	Capabilities not aligned with the industry.	1	S10	Procedural
99	Toxic software community.	1	S10	Social
100	Overwhelming amount of work.	1	S10	Procedural
101	Inexperienced supervisors.	1	S10	Procedural
102	Personality (of the developers).	2	S11, S23	Social
103	Emotional intelligence.	1	S11	Social
104	Lack of sleep or rest.	1	S19	Social
105	Sleepiness.	1	S19	Social
106	Fatigue.	1	S19	Social
107	Mental fatigue.	1	S19	Social
108	Underdeveloped social identity.	1	S18	Social
109	Immaturity (group immaturity).	2	S18, S1	Social
110	Misunderstanding.	1	S18	Procedural
111	Social debt.	1	S1	Social
112	Changing the structure of the development community.	2	S1, S25	Procedural
113	Change of the development process.	1	S1	Procedural
114	Distributed collaboration.	1	S1	Social
115	Lack of confidence.	1	S1	Social
116	Erratic frequency of open-source contributions.	1	S1	Procedural
117	Duplicate work.	2	S8, S26	Procedural
118	Insufficient number of user stories ready.	1	S8	Procedural
119	Imbalance between feature development and bug fixes.	1	S8	Procedural
120	Rejected user stories.	1	S8	Procedural
121	Definition of “fact” not clear.	1	S8	Procedural
122	Poor testing strategy.	1	S8	Procedural
123	Complex or extensive user stories.	1	S8	Procedural
124	Inefficient tools (poor tools).	2	S8, S23	Technique
125	Unnecessary context switching.	1	S8	Procedural
126	Inefficient development flow.	1	S8	Procedural
127	Poorly organized code.	1	S8	Technique
128	Low morale of the team.	1	S8	Social
129	Interpersonal or team conflicts.	1	S8	Social
130	Slow or unreliable tests.	1	S8	Procedural
131	Unreliable acceptance environments.	1	S8	Procedural
132	Missing information, personnel, or equipment.	3	S8, S25	Procedural
133	Team rotation.	2	S8, S25	Social
134	Teams that are too big.	1	S8	Procedural
135	Inefficient meetings.	1	S8	Procedural
136	Team members who do not contribute.	1	S13	Procedural
137	Type of project.	1	S13	Procedural
138	Type of customer.	1	S13	Procedural
139	Unhealthy organizational structure.	1	S23	Procedural
140	Impolite comments.	1	S23	Social
141	Harassment.	2	S23, S25	Social
142	Excess of positive comments.	1	S23	Social
143	Propensity to error.	1	S23	Procedural
144	Non-aligned teams.	1	S4	Social
145	Misunderstandings.	4	S4, S25, S26	Social
146	Differences of thought regarding goals and objectives.	1	S4	Social
147	Last-minute changes in requirements.	1	S24	Procedural
148	Lack of experience.	2	S25, S26	Technique
149	Lack of leadership.	1	S25	Social
150	The communication plan is not considered.	2	S25	Social
151	Business needs are not considered.	1	S25	Procedural
152	Lack of openness to new software, infrastructure, and processes.	1	S25	Procedural
153	Insufficient collaboration.	3	S25, S26	Social
154	Lack of analysis before starting a task.	2	S25	Procedural
155	Subjective interpretations of tasks.	2	S25	Procedural
156	Work is not solution-oriented.	2	S25	Procedural
157	Conflicts of interest in management.	1	S25	Social
158	Certain people dominate discussions.	1	S25	Social
159	Lack of respect in the workplace.	4	S25, S26	Social
160	Lack of acceptance of different lifestyles.	1	S25	Social
161	Slow decision-making.	1	S25	Procedural
162	Conflicting work styles.	1	S25	Procedural
163	People getting angry at meetings.	1	S25	Social
164	People crying at meetings.	1	S25	Social
165	People who don’t report problems in time.	2	S25	Procedural
166	Overconfidence.	2	S25	Social
167	Exaggerated search for problems in the project.	2	S25	Procedural
168	The customer doesn’t know what he wants.	1	S25	Procedural
169	Lack of interest in the project on the part of the client.	1	S25	Procedural
170	Lack of IT expertise on the part of the client.	1	S25	Technique
171	Lost technical knowledge on the part of the customer.	1	S25	Technique
172	Exaggerated expectation of quality on the part of the customer.	1	S25	Technique
173	Conflicts of interest on the part of the client.	1	S25	Technique
174	The client is unable to specify functional requirements.	1	S25	Procedural
175	The client is unable to specify non-functional requirements.	1	S25	Procedural
176	Lack of prioritization by the customer.	1	S25	Procedural
177	Delays due to third-party dependencies.	1	S25	Procedural
178	Carelessness.	1	S26	Social
179	Poor processes.	1	S26	Procedural
180	Non-systematic quality verification.	1	S26	Procedural
181	Incompetence.	1	S26	Technique
182	Competences of the process.	1	S26	Procedural
183	Lack of commitment to development.	1	S26	Social
184	Lack of follow-up evaluation.	1	S26	Procedural
185	Lack of software culture.	1	S26	Technique
186	Suboptimal process design.	1	S26	Procedural
187	Lack of innovation.	1	S26	Social
188	Gender bias.	1	S26	Social
189	Lack of curiosity.	1	S26	Social

, which list the causes of happiness and unhappiness identified in the primary studies, respectively. The information in the tables is organized as follows: (i) cause number; (ii) cause name; (iii) number of times the cause appears in the primary studies; (iv) identifier of the primary study (see Table 8); and (v) type of cause. These causes can be:

Social cause: referring to causes related to psychology, emotions, mood, social skills (For example: communication, active listening, assertiveness, eye contact, sincerity, empathy, negotiation, leadership, and non-verbal language), mental, physical, and spiritual health, work performance, personal and interpersonal development, well-being, and the environment in which professionals in software development communities operate and are part of, and which, in some way, may affect their interactions with other professionals.

Procedural cause: referring to causes related to the processes or procedures employed by professionals in software development communities, which, together with social and technical aspects, enable the achievement of proposed goals and objectives.

Technical cause: referring to causes related to the skills or abilities possessed by professionals in software development communities that allow them to perform their tasks and meet the objectives set for them. This involves knowledge of programming languages, tools used, and best practices.

Considering the above, Figure 9 presents the distribution of causes of happiness and unhappiness categorized into three defined types: social, procedural, and technical. A total of 189 causes were identified, with a clear predominance of factors contributing to unhappiness (65.95%) compared to happiness (34.5%). Furthermore, it can be observed that happiness in work communities stems from two key aspects: (i) the development of strong soft skills that foster a work environment focused on motivation, recognition, and constant collaboration; and (ii) the ability of companies to define clear, structured, and organized processes that promote communicative, collaborative, and assertive work environments, enabling team members to feel valued.

Furthermore, it can be observed that social causes represent almost half of the total (49.46%), being the main contributor to unhappiness, which suggests that social dynamics are critical areas to address in order to reduce dissatisfaction. In this regard, it is important to mention Google’s Project Aristotle [53], which revealed that a team’s effectiveness does not depend so much on the team’s composition from a technical and/or intellectual point of view, but rather on how its members interact, collaborate, and perceive their work. In this sense, it is not only about intellectual quotient (IQ) but also about emotional quotient (EQ) or emotional intelligence. Additionally, Project Aristotle highlighted that psychological safety—an environment in which members feel safe to take risks and express their ideas without fear of repercussions—is a critical factor for the success of the team and, consequently, the project in which they participate. Moreover, factors such as reliability, clarity in structure and roles, a sense of purpose, and the impact of the work were identified as key elements for team effectiveness [53]. These findings are supported by research on group dynamics, which has shown that cohesion and open communication within a team are crucial determinants of its performance and success [54].

On the other hand, Figure 9 also shows that procedural problems have a significant impact on unhappiness (34.57%), while technical causes, though smaller in proportion, tend to contribute more to unhappiness than to happiness. The studies that can be conducted based on this are diverse. For example, a hypothesis derived from this analysis could suggest that a focus on improving social relationships and equity in processes could significantly reduce unhappiness. Moreover, while technical improvements are important, their optimization may not directly translate into increased happiness but rather a reduction in dissatisfaction. At this point, it is important to remember that effectiveness is related to the ability to produce a desired effect. In this sense, a work team in a company must be effective, and that effectiveness must ultimately lead to customer satisfaction. Likewise, one could consider that if interventions are implemented in social and procedural areas, a more favorable balance between the causes of happiness and unhappiness could be expected, with a possible increase in the contributions of social causes to happiness if a positive social environment is fostered with a balanced level of emotional quotient/intelligence. This analysis highlights the importance of a balanced approach that prioritizes human and organizational elements along with technological improvements.

Finally, a few causes related to technical aspects were identified in the primary studies (6.91% in total). This is interesting, given that technical debt in software development is one of the most widely discussed topics in Software Engineering. However, due to the focus of this study, not many articles were found that connected this type of debt with SD and “smelly” communities, highlighting the need for more studies that suggest such relationships. On the other hand, it was observed that unhappiness in communities is caused by various factors, mainly: (i) the lack of soft skills among team members, resulting in friction and internal conflicts within the team; (ii) personal conflicts, problems, or difficulties faced by each team member, leading to a decrease in individual and collective morale in the work communities; (iii) the lack of clear procedures in companies, fostering disorganized work environments with a high probability of scope, objective, and time failures, which lower the morale of work communities; and (iv) the lack of hard skills, which result in the use of bad practices and anti-patterns that may lead to inadequate solutions affecting the team’s speed and performance, potentially fostering a chaotic and unstructured work environment.

To facilitate the analysis of the information in Table 11 and Table 12, Figure 10 has been designed, which presents the contribution of the primary studies regarding the identified causes. This figure uses a convention to classify the causes according to their type; i.e., social, procedural, and technical, as follows: (#social), [#procedural], and {#technical}. To ease readability, Figure 10 organizes the contribution of the studies into two quadrants: (i) the left quadrant shows the distribution of causes related to unhappiness in each primary study, and (ii) the right quadrant shows the distribution of causes related to happiness. The total number of causes identified by each primary study is displayed on the right edge of the figure, where, for example, article S25 identified 42 causes in total. In some articles, such as S7, S15, S22, and S27, no causes were identified.

Table 13. Definitions of some causes of unhappiness identified in primary studies.

#	Cause	Definition	Id
63	Technical Debt (Discomfort with technical debt, frustration with technical debt, Being aware of technical debt).	Definition 1: Technical Debt is made up of a debt, which is a technical solution suboptimal that entails a short-term benefit, as well as the future pay Technical Debt refers to the risks of delaying necessary technical work, taking technical shortcuts, usually to meet a deadline of interest, which is the extra cost due to the presence of Technical Debt [S21]. Definition 2: Technical Debt refers to the risks of delaying necessary technical work, taking technical shortcuts, usually to meet a deadline [S8].	S8, S21
64	Lack of progress (Feeling of stagnation, Feeling of little contribution or contribution).	Definition 1: Employee progress is mainly explained in terms of their perception about the amount of work being done and the amount of unnecessary waste [S21]. Definition 2: If technical debt is not reduced, development will stagnate at some point; Maybe we’re walking now, but we could run, but the drag will come if we don’t pay off the technical debt, so we’ll get fewer and fewer features [S21].	S5, S10, S21
65	Legacy code.	Definition 1: Code that contains a large amount of Technical Debt [S21].	S21
66	Lack of communication skills (poor communication, ineffective communication, asynchronous communication).	Definition 1: The cost of incomplete, incorrect, misleading, inefficient, or absent communication [S8].	S16, S18, S8, S4
67	Build functionalities products that are not required.	Definition 1: The cost of creating a feature or product that doesn’t meet the requirements of the user or company needs [S8].	S8
68	Poor management of the product backlog.	Definition 1: The cost of duplicating work, speeding up features of lower user value, or delaying necessary bug fixes [S8].	S8
69	Rework.	Definition 1: The cost of altering the work delivered that should have been done correctly [S8].	S8
70	Work on many features at the same time.	Definition 1: The cost of downtime, often hidden by multitasking [S8].	S8
71	Unnecessarily complex solutions (High code complexity).	Definition 1: The Costs of Unnecessary Expenditure of Mental Energy [S8].	S8, S23
72	Strange cognitive load.	Definition 1: The Costs of Unnecessary Expenditure of Mental Energy [S8].	S8
73	Silos of knowledge.	Definition 1: The cost of reacquiring information that the team knew before [S8].	S8

presents the definitions found in the primary articles for only 11 of the identified causes. These are listed below according to their order of appearance and identifier, as per the table, to facilitate their consultation: (62) Technical Debt, (63) Lack of Progress, (64) Legacy Code, (65) Lack of Communication Skills, (66) Building Unnecessary Features or Products, (67) Poor Management of the Product Backlog, (68) Rework, (69) Working on Many Features Simultaneously, (70) Unnecessarily Complex Solutions, (71) Extraneous Cognitive Load, and (72) Knowledge Silos.

Main findings (Research Question Q3)

A total of 60.7% of the studies focus on practical validations in the industry, while 17.9% propose conceptual definitions. Despite some practical solutions, there is a lack of tools and methodologies to improve welfare in agile software communities. The trend towards industrial validation highlights opportunities for future theoretical and methodological research.

4.4. Q4: How Does Happiness or Unhappiness Impact Software Development?

Figure 11 is based on the information presented in Table 11 and Table 12 (which consider the types of causes used in the previous section). This figure presents a classification of the consequences that generate happiness and unhappiness in software development communities based on three main categories: social, procedural, and technical. In total, 96 consequences were identified, of which 63.73% are associated with happiness, while 26.37% correspond to unhappiness. Additionally, most happiness-related consequences are linked to social factors (28.13%), while procedural and technical consequences are less represented in this category (5.21% and 3.13%, respectively).

Regarding unhappiness, the dominant consequences remain those related to social factors (37.50%), followed by procedural (19.79%) and technical (6.25%). It was found that work environments fostering aspects such as satisfaction, motivation, and morale increase the members’ capacity to work proactively, collaboratively, communicatively, and in alignment with business goals, which enhances productivity, quality, and value delivery [13,44]. On the other hand, happiness in the communities results in the execution of company-defined processes in more transparent and structured ways, increasing effectiveness and performance in development processes. Finally, the happiness of community members shows a tendency to apply strategies that enable the continuous improvement of hard skills, motivated by the need to provide high-quality solutions and improve individual skills. This results in the application of best practices during the project lifecycle. This pattern suggests that social factors play a predominant role in software communities, as they can influence both happiness and unhappiness, though with a significantly greater impact on happiness, success, and the well-being of a software community.

On the other hand, technical consequences, although less frequent, seem to have a greater negative impact than positive, while procedural consequences are relatively balanced between both emotions. These results highlight the importance of considering social factors when evaluating the causes of happiness and unhappiness and suggest that technical interventions, although necessary, may require a more balanced approach to avoid undesired negative impacts. Additionally, these data reveal the importance of conducting studies that analyze the positive impact that technical aspects can have because of more positive and emotionally balanced work environments (or communities). It is also observed that the unhappiness of communities can bring consequences in terms of scope, time, and failure to meet community goals, which can be due to various factors, such as: (i) a decrease in community morale caused by personal conflicts; (ii) lack of soft skills among community members, leading to internal conflicts; (iii) chaotic processes that prevent the establishment of clear work strategies and lower community morale; and/or (iv) lack of clarity in community objectives, goals, and guidelines. One of the most interesting aspects was observing that, while community happiness is not directly related to technical aspects or hard skills, unhappiness has direct consequences on the technical aspects of agile software development communities, significantly reducing non-functional aspects of solutions in terms of maintainability, scalability, performance, increasing technical debt, and gradual degradation of the solutions proposed by the community. Moreover, this is reflected in software quality, manifesting in incomplete requirements and/or their misinterpretation, lack of understanding of stakeholder needs, software development that does not meet client expectations, suboptimal modularization structures, inefficient code patterns, poor programming practices, excessive workload, and defective components that may impact maintenance [55].

Based on this, it can be established that unhappiness in communities directly affects how team members apply their hard skills to address project needs and software development.

Another important aspect to highlight is that the lack of management of the causes that generate happiness and unhappiness among members of software development teams leads to social, procedural, and technical consequences and effects, which are reflected in project management, organizational culture, team dynamics, and the technical quality of the software. These consequences include:

Impact on team dynamics: Poor communication can lead to the formation of organizational silos, the perception of a dark cloud over the team, and the creation of bottlenecks, reducing effective collaboration and affecting task execution [56,57,58].

Reduced productivity and increased turnover: Lack of team integration decreases efficiency and hinders goal achievement, generating negative attitudes among colleagues, such as distrust, irritation, stress, and internal conflicts [10].

Difficulties in collective decision-making: Unhappiness impacts the team’s ability to process information, identify challenges, and address them effectively, which can lead to opposing attitudes among members, lack of responsibility, unclear roles, and frustration due to communication and leadership issues [59].

Challenges in project management: Lack of coordination and planning slows down software development, hinders adaptation to changes, and may compromise the size, complexity, and feasibility of the project, affecting its success and sustainability [60].

Delays in product delivery: Disorganization causes delays in activity execution and goal achievement, impacting overall project planning [57].

Code errors and critical failures: Poor programming practices resulting from a deficient organizational culture can hinder code comprehension, maintenance, and evolution, increasing workload due to the need for constant corrections and maintenance of defective components [61,62].

Deterioration in communication and leadership: Divisions within the team weaken cohesion, undermine leadership authority, and foster a toxic organizational culture that demoralizes not only team members but also partners, clients, and employees [60].

Difficulties in project management: Leaders may face challenges in coordinating work and aligning efforts with organizational objectives.

Divergence in the interpretation of organizational values and norms: The lack of consensus on organizational principles may lead to disagreements within the team, affecting strategic alignment and decision-making [62].

It can be concluded that poor management of happiness and unhappiness in software development teams can compromise performance, cohesion, product quality, and project success. To mitigate these negative effects, it is crucial to foster effective communication, strengthen leadership, establish clear processes, and promote a healthy and collaborative work environment.

In order to facilitate the analysis of the information in

Table 14. Consequences of happiness identified in primary studies.

#	Consequences	#Ap	Ref.	Type
1	Increased developer productivity.	4	S5, S6, S21	Procedural
2	Increased software quality.	1	S21	Technician
3	High morale of the developers.	4	S21, S28	Social
4	Developer well-being.	1	S5	Social
5	Increased perceived progress.	1	S5	Social
6	Increased satisfaction.	1	S3, S16	Social
7	Greater commitment.	2	S14, S16, S28	Social
8	Increased performance.	1	S16, S28	Procedural
9	Activism.	1	S16	Social
10	Respect.	1	S16	Social
11	Acceptance.	1	S16	Social
12	Acquisition of hard skills.	1	S10	Technician
13	Acquisition of soft skills.	1	S10	Social
14	Increased motivation.	1	S10, S28	Social
15	Increased interest.	1	S10	Social
16	Success in the development of specific tasks.	1	S17	Procedural
17	Greater effectiveness of the team.	1	S12	Procedural
18	Greater satisfaction.	1	S14, S18	Social
19	Successful development team.	2	S3, S14, S28	Procedural
20	Better communication.	1	S14	Social
21	Increased creativity.	1	S3	Social
22	Better expectations.	1	S3	Social
23	Promote collaboration among the team.	1	S3	Social
24	Increased customer loyalty.	1	S3	Social
25	Maintaining successful relationships between organizations.	1	S3	Social
26	Reduction of social complexity.	1	S2	Social
27	Improved team independence.	1	S2	Social
28	Reduction of the effort required to manage the equipment.	1	S2	Social
29	Increased confidence.	1	S2	Social
30	Increased problem-solving skills.	1	S25	Technician

and

Table 15. Consequences of unhappiness identified in primary studies.

#	Consequences	#Ap	Ref.	Type
1	Deterioration of the speed of the equipment.	1	S22	Procedural
2	Low product quality (code).	5	S19, S13, S23, S22, S21	Technician
3	Inability to add new functionality.	1	S22	Procedural
4	Premature loss of a system.	1	S22	Procedural
5	Unforeseen additional costs.	6	S1, S19, S15, S23, S22	Procedural
6	Constant pressure on the development team to finish tasks quickly.	1	S22	Social
7	Productivity problems.	6	S15, S16, S23, S22, S21	Procedural
8	Fragile systems.	1	S22	Technician
9	Low motivation.	4	S19, S23, S22, S21	Social
10	Technical debt.	1	S15	Technician
11	Longer time to resolve incidents.	4	S23, S21	Procedural
12	Code with bugs.	2	S21	Technician
13	Low cognitive performance.	1	S21	Procedural
14	Retirement from work.	1	S21	Social
15	Download code.	1	S21	Technician
16	Reopening Issues.	1	S21	Procedural
17	Increased effort to solve problems.	1	S23	Social
18	Waste of time.	1	S23	Social
19	Frustration.	1	S23	Social
20	Feeling helpless.	1	S23	Social
21	Low morale.	1	S23	Social
22	Individual productivity problems.	2	S23	Social
23	Rework.	2	S23	Procedural
24	Loss of development time.	1	S23	Procedural
25	Loss of maintenance time.	1	S23	Procedural
26	Low self-esteem of developers.	1	S23	Social
28	Poor work performance.	1	S5	Procedural
29	Detriment to the software development process.	2	S5, S13	Procedural
30	Exhaustion.	1	S5	Social
31	Unwanted rotation.	1	S5	Social
32	Anxiety.	1	S16	Social
33	Poor coordination.	1	S16	Procedural
33	Reduced confidence.	2	S10, S16	Social
34	Conflicts between team members.	1	S16, S4	Social
35	Disappointed employers.	1	S10	Social
36	Unhappy employees.	1	S10	Social
37	Low reputation of higher education in software engineering.	1	S10	Procedural
38	Decreased performance.	3	S19, S13	Procedural
39	Bewilderment of the activities of decision-makers.	1	S19	Procedural
40	Decreased working memory.	1	S19	Social
41	Decreased creativity.	1	S19	Social
42	Decreased multitasking ability.	1	S19	Social
43	Decreased response time.	1	S19	Social
44	Decreased concentration.	1	S19	Social
45	Mental fatigue.	1	S19	Social
46	Decreased reaction to stimuli.	1	S19	Social
47	Sudden mood swings.	1	S19	Social
48	Loss of situational perception.	1	S19	Social
49	Reduced Knowledge Acquisition	1	S19	Social
50	Impairment of divergent thinking.	1	S19	Social
51	Perseverance of ineffective solutions.	1	S19	Social
52	Short-term memory loss.	1	S19	Social
53	Stress.	1	S13	Social
54	Decreased team resilience.	1	S13	Social
55	Reduction of team size.	1	S13	Social
56	Unexpected releases.	1	S1	Procedural
57	Social debt.	1	S1	Social
58	Failed projects	1	S4	Procedural
59	Integration issues.	1	S26	Technician
60	Risk of physical or mental illness.	1	S27	Social
61	Depression.	1	S27	Social

, Figure 10 has been designed, which presents the contribution of the primary items with respect to the identified consequences, the figure uses a convention to classify the causes according to their type; i.e., social, procedural and technical, as follows: (#social), [#procedural] and {#technical}. For ease of reading, Figure 12 organizes the contribution of the items in two quadrants: (i) the left quadrant presents the distribution of the number of consequences related to unhappiness in each of the primary items, and (ii) the right quadrant presents the distribution of the number of consequences related to happiness. The total number of consequences identified for each primary item is presented on the right edge of the figure, where it can be seen; for example, item S19 showed 18 different types of consequences. In some articles, such as S7, S8, S9: S7, S8, S9, S11 and S20, no consequences were evidenced.

Figure 13 summarizes and classifies the causes and consequences of happiness and unhappiness in software development communities identified and classified into three dimensions: social, procedural, and technical. A total of 189 causes (mostly related to unhappiness) and 96 consequences are identified, highlighting that social and procedural factors predominate in both categories. The social dimension encompasses human interactions and soft skills; the procedural, processes, and methodologies; and the technical, competencies, and development tools. This visual representation highlights the importance of addressing social and procedural factors to improve well-being and performance in these communities.

Main findings (Research Question Q4)

The analysis shows that in software development communities, happiness is mainly associated with social factors, such as motivation and well-being of members, which improves productivity and quality of work. In contrast, unhappiness, while also affecting social factors, has more negative consequences on technical aspects, such as code quality and technical debt. Social factors have a significant influence on both emotional states, being crucial for the well-being and success of the community. Likewise, unhappiness can reduce performance and generate problems such as low morale and internal conflicts, while happiness improves effectiveness and continuous improvement of technical skills.

4.5. Q5: What Are the Challenges/Future Work Proposed in the Studies Analyzed?

Table 16. Challenges and future work proposed in the studies analyzed.

#	Challenge	No. Appearances	Ref.
1	Lack of studies that explore technical debt from an individual perspective by focusing on its social and psychological aspects.	1	S21
2	Provide a better and deeper understanding of the relationships between appearances and the management of technical debt in developer morale.	1	S21
3	Conduct a more detailed study of the impact of the agile mindset on the effectiveness of agile teams.	1	S5
4	Explore the emotions of developers during the development of activities other than programming in a working day.	1	S17
5	Use other approaches to identify what features a software system has as a measure of effectiveness.	1	S18
6	Study different types of projects in different organizations in order to reveal new types of waste or better understand existing categories.	1	S18
7	Uncover new sources of stress and indicators that show weaknesses in distributed team performance.	1	S13
8	Identify the effects of stress on changes and adaptation mechanisms in distributed teams.	1	S13
9	Formalize the concept of social debt by looking at the software life cycles of real industries.	1	S1
10	Interpret the interaction of positive and negative emotions with social debt.	1	S23

presents the challenges and future work outlined in the analyzed studies, focusing on providing a deeper definition and conceptualization of terms related to SD, such as: (i) happiness, (ii) unhappiness, (iii) motivation, (iv) well-being. Additionally, there is an emphasis on exploring and understanding technical debt from a more human perspective, valuing software developers not only for their work but also as individuals influenced by their environment, emotions, and interpersonal relationships. The goal is to standardize and formalize these concepts to establish a common language for further study.

Main findings (Research Question Q5)

The studies propose to further investigate technical debt from a human perspective, considering the social and emotional aspects of developers. They seek to standardize concepts such as happiness, motivation and well-being for a common language in research. It is also suggested to explore the impact of the agile approach on the effectiveness of teams, to study the emotions of developers in activities other than programming and to analyze new sources of waste in different projects. In addition, it is proposed to formalize the concept of SD and study its interaction with emotions in software life cycles.

5. Discussion

The following is an analysis based on the results obtained thanks to the collection of the information presented in this SLR.

5.1. Key Observations

This SLR was developed with the aim of understanding the current state of the literature regarding happiness and/or unhappiness in software communities in agile projects. From this, the following observations can be deduced:

• Happiness and/or unhappiness in the communities of professionals involved in software projects is a topic being studied within the context of SD. It is one of the relatively new variables currently being researched. This may explain why there are few studies to date, as most existing literature so far addresses project debt from contexts such as technical debt and process debt, rather than from a social and well-being perspective of professionals in software development communities. However, researchers’ interest in this topic is growing over time, gaining relevance due to the impact and consequences of poor management of unhappiness in software projects. Additionally, some authors have shown interest in studying other socio-emotional aspects, such as well-being, motivation, and satisfaction in software communities, which are interesting aspects to explore from both collocated and remote community perspectives.
• The contributions found focus on the identification of causes and consequences as well as other aspects related to happiness (e.g., satisfaction, motivation, among others) and unhappiness (e.g., low morale, low productivity, among others). Additionally, it was possible to identify alternatives aimed at mitigating unhappiness and enhancing happiness within software development communities. Although a significant number of causes (189 in total) and consequences (96 in total) were identified, many of them lack formal definitions that would allow for clearer understanding, with only 11 causes of unhappiness defined in the primary studies. However, it is important to continue with more exhaustive, in-depth, and rigorous individual studies for each identified cause and consequence to improve their understanding, documentation, and specification. It is important to highlight that a large portion of both causes and consequences are tied to social aspects. These aspects are mainly related to feelings and emotions, such as motivation and developers’ attitudes, or to interpersonal interactions, such as communication, respect, and coordination.
• It is important to highlight that a large portion of both causes and consequences are tied to social aspects. These aspects are mainly related to feelings and emotions, such as motivation and developers’ attitudes, or to interpersonal interactions, such as communication, respect, and coordination.
• Although the authors of the primary articles included in this SLR mention or list different types of SD, after a detailed analysis, it was identified that the proposed types of SD refer to causes that generate SD or consequences resulting from it. Moreover, these causes and consequences are related to other classifications, such as procedural or technical aspects, which can contribute to the decline in the well-being of software communities and consequently lead to unhappiness due to issues like poor backlog management and rework, among others. This can ultimately result in SD.
• Regarding application domains, while the impact of unhappiness on certain characteristics and/or activities related to product and software project development is mentioned, such as maintainability, scalability, performance, increasing technical debt, and the gradual degradation of the solutions proposed by the software development community, there is still a need to explore in more detail how certain causes can be threatening and detrimental to other software lifecycle activities (e.g., requirements elicitation, automation, and testing). Additionally, it is essential to examine how the absence or low level of happiness affects collocated or remote communities, the latter of which might have an even greater impact due to the lack of physical contact between software community members, as well as differences in time zones, geographical locations, languages, customs, and other factors present in global software development environments.
• Software development presents a series of challenges, complexities, and rigor, both technically and socio-emotionally, the latter being the least studied in academia and the software industry. It also relates to the soft skills of professionals to perform tasks where social interaction and communication among project stakeholders are expected to be cooperative. However, many professionals with highly technical profiles tend to overlook the development of these skills, even though this is a significant challenge in their career development [63]. In this sense, it is possible to establish that one factor contributing to unhappiness in software communities could be the partial or total lack of one or more of these skills. Therefore, reducing SD could begin by verifying these qualities, which would allow for the creation of valuable and high-quality documentation for all stakeholders.
• It is important to understand that unhappiness, in general terms, represents a debt and a cost that can significantly impact the software community, other interacting communities, projects, and even the product. In this sense, it is necessary to plan for the payment of its “interest” before it manifests in the long term in the project and product. If this is not considered, organizations may face reduced competitiveness and high turnover due to low morale, tranquility, happiness, and motivation of their professionals. Therefore, establishing an acceptable threshold for SD, similar to technical debt, is essential before it becomes unmanageable or significantly and negatively affects the organization.
• Another key factor in software development teams is gender diversity, a relevant topic that can have a positive impact on multiple aspects of teamwork. Various authors indicate that diversity enhances team creativity as it allows for the generation of more innovative solutions. Additionally, it positively influences decision-making by incorporating multiple perspectives, which helps reduce biases. Furthermore, gender diversity fosters a more inclusive and participatory work environment, promoting a culture based on communication, collaboration, and team cohesion. It also enables teams to better understand user needs from different perspectives, leading to the development of more inclusive and accessible products. However, if gender diversity is not properly managed, negative effects may arise. The lack of inclusive policies can create barriers to accessing leadership roles, as well as communication challenges and cultural misunderstandings, which may hinder team integration and performance [64,65,66].
• Es importante señalar que la distribución geográfica de los equipos conlleva la necesidad de abordar problemas de comunicación, coordinación y control, así como desafíos derivados de las diferencias culturales entre los distintos equipos equipos [67]. Estas dificultades pueden generar una comprensión deficiente del proyecto entre los miembros del equipo, especialmente cuando es necesario utilizar un idioma común no nativo, lo que puede dar lugar a malentendidos que afecten la comunicación, la cooperación y la coordinación del trabajo. Esto, a su vez, podría representar un riesgo para los proyectos [68] o incluso generar desconfianza entre los participantes [69].
• Asimismo, según García et al. [70], el Desarrollo Global de Software (DGS) implica diversos desafíos, entre ellos: la coordinación de tareas entre equipos distribuidos, la optimización de la productividad y la eficiencia, las barreras de comunicación derivadas de diferencias de horarios e idioma, la baja cooperación, que puede afectar los resultados del proyecto, los conflictos culturales y la falta de transparencia. En este sentido, una de las principales proyecciones de las empresas que trabajan con equipos distribuidos es superar estos desafíos y, al mismo tiempo, facilitar una comunicación efectiva entre sus miembros. Para lograrlo, es fundamental compartir el conocimiento generado, implementar buenas prácticas, contar con una base teórica sólida, definir roles y responsabilidades, asignar actividades de desarrollo y proporcionar actualizaciones periódicas sobre el estado del proyecto [67].
• Finally, being able to quantify and estimate the cost of unhappiness based on a set of defined causes and metrics would provide the software industry with mechanisms to more clearly understand how to mitigate, contain, and/or manage risks and threats preventively. This would reduce the cost of SD, which can trigger other types of debt, such as technical and process debt.

Takeaway messages:

SD is gaining relevance: Happiness and unhappiness in software communities are being investigated as part of SD, an emerging field that reflects the impact of not managing unhappiness well. The causes and consequences are primarily social: Factors such as motivation and interpersonal interactions are key to unhappiness in teams, highlighting the need to address them. Unhappiness can generate other debts: Unhappiness contributes to technical and process debt, negatively affecting software quality. Soft skills are essential: Lack of soft skills in technical teams increases unhappiness, underscoring the importance of developing them. Unhappiness has a high cost: Failure to manage unhappiness can reduce competitiveness and increase staff turnover, affecting motivation and productivity. Quantifying SD is crucial: Measuring unhappiness with clear metrics would allow better risk management and reduce its impact on software development.

5.2. Biases and Limitations

The results of this systematic review may have been affected by several threats to validity, such as:

• Biases in research questions: It is possible that the research questions defined for this review did not cover all aspects of happiness and unhappiness in software development communities. To mitigate this threat, three review cycles were conducted, allowing adjustments to the purpose of the questions. Additionally, some relevant studies may not have been retrieved. To address this second threat and strengthen the external validity of the review, a strict search protocol was defined based on the protocols proposed by established research guidelines Kitchenham & Charters [25], and Kitchenham et al. [28].
• Biases in the search string: It is possible that relevant and necessary terms were not used in the search string, which may have increased the risk of excluding valuable articles focused on the topic of this work. To assess the impact of this risk on the review, some manual tests were conducted using the terms defined in the basic search string before executing the search protocol. As a result, many generic results were obtained from different combinations of the string, confirming that search engines produce similar results across different variations. However, it is not possible to guarantee that manual searches were 100% accurate. Despite this, the activity helped to understand how to use the terms during the search.
• Biases in study selection: One of the main limitations presented in this SLR comes from the search engines used, which did not allow for collecting a wider range of contributions, in addition to the little incursion into the literature about the central theme of this article. On the other hand, contributions were included only in English, which may result in certain relevant studies written in another language not being considered.
• Biases in data extraction: It is complex to ensure that the primary articles were properly analyzed and selected. To mitigate this threat, the classification and extraction of the information from each article was carried out by the main author and confirmed by the other authors. Another important limitation is related to the technique defined for data extraction based on summary cards, which biased the extracted information since the classification was carried out under the opinion and knowledge of those involved in the search.

5.3. Significance for Research and Practice

This SLR yielded relevant and transcendent results for those who wish to investigate the social aspect present in happiness and/or unhappiness in agile software development communities. The main objective of addressing this area of research is to highlight the importance of members within software communities, not only from a technical or process perspective, but also from a human perspective, considering the impact that aspects such as the well-being and socio-emotional state of the members of software communities generate within software projects. Those who investigate this area will be able to propose solutions such as methodologies, processes, models, or tools that help mitigate negative social consequences such as unhappiness and that enhance positive changes such as happiness in software professionals and, therefore, the success and reduction in the associated costs in the development of the projects.

6. Conclusions and Future Work

This mapping allowed us to identify, compile, and categorize a broad set of causes and consequences that were found in the literature related to happiness and/or unhappiness in agile software communities. The growing interest in this topic in recent years is noteworthy; however, it is also observed that although the importance of the study of aspects related to well-being, motivation, social, and psychological aspects within software communities is of utmost importance, the literature evidence is relatively little compared to other types of debt such as technical. This does not detract from the interest that has been given to this topic in the literature in recent years; on the contrary, it establishes a work opportunity for research.

In the selected primary articles, different causes and consequences related to the happiness and unhappiness of software communities were found; however, these causes and consequences lack a formal and deeper definition or conceptualization. In addition, most of the primary articles lack proposals that allow to systematically address and manage the prevention and mitigation of unhappiness in software communities; i.e., there is a great interest in what causes unhappiness? What effects does unhappiness have? But it leaves aside: how can we solve it?

The information and results collected throughout this review demonstrate the importance and impact of this topic on the cost overrun of software projects, and therefore, it is pertinent to continue researching and proposing relevant solutions, therefore, the following future work is proposed.

To deepen and provide a deeper conceptualization as to the causes and consequences of happiness and unhappiness that generate SD in software development communities.

Propose methodologies or approaches that allow the prevention and/or mitigation of unhappiness within software communities.

Conducting a causal analysis linking the causes and consequences identified in software development communities is essential to gain an in-depth understanding of how these dynamics affect not only work performance but also the physical and mental health of professionals. This approach would allow the identification of risk triggers such as asthenopia, anxiety, and depression, as well as assess their impact on overall emotional well-being. Understanding these relationships is key to implementing effective mitigation strategies, fostering healthy work environments, and preventing long-term health problems, including establishing personality traits, physiological factors, and job burnout, among others. In addition, this type of analysis can serve as a basis for developing organizational policies that promote a better quality of life in these groups, improving both productivity and the overall well-being of the teams.