Software organizations of all sizes are affected by the Technical debt phenomenon. Large organizations, however, are more prone to their non-technical aspects due to a large number of teams of different sizes, heterogeneity of expertise, and the need for continuous management and communication. This is even more emphasized in large agile software development contexts due to a focus on personal interactions and team collaboration, which consequently poses a challenge due to a significant increase in communication pathways. The goal of this study is to investigate non-technical aspects of technical debt in the context of large-scale agile software development. To achieve this objective, a case study involving four international companies was conducted. During the study, 24 experts were interviewed, and their responses were analyzed using a qualitative research approach. The analysis resulted in five non-technical aspects, which are: social dynamics, process, people, documentation, and requirements aspects, and their indicators, which are specific in a large-scale agile context. The study findings suggest that lack of communication, collaboration, and cooperation are the key contributors to identified debt aspects, technical debt accumulation through these non-technical aspects, and that many of the causes stem from a culture of not developing rules, protocols, or guidelines.

Scaling agile approaches in large company context is prone to technical debt due to large number of teams of different size, level of expertise and their need for management and communication. The goal of this study is to investigate the phenomenon of non-technical debt related issues in the context of large-scale agile software development. To achieve this goal, eleven experts from two multinational companies were inter-viewed as part of the the case study. The analysis results revealed four non-technical aspects of technical debt that are present in large-scale agile context. These are people, social, documentation and process debt aspects. Furthermore, the findings suggest that lack of communication, collaboration and cooperation are the key contributors to identified debt aspects, and that many of the causes for debts are stemming from a culture of not developing rules, protocols, or guidelines. Implementing ground rules to improve quality seems to mitigate several of the identified debt types.

Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED). We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nation-wide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.

Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes. Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept. Method: We conducted a national-wide survey to collect feedback from industry practitioners. The survey is a part of InsighTD-an international initiative to investigate causes and effects of TD. Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework. Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.

Software companies that develop embedded systems following the principles of service-oriented architecture can anticipate various benefits from choreography modelling. Current choreography modelling languages, however, have a limited applicability in embedded systems development since they are not expressive enough to capture all the choreography-relevant aspects that are typical in this domain. We tackled this problem by analysing the needs of embedded systems for choreography modelling language. Our analysis was guided by design science and relied on expert interviews, company-specific documents and the relevant literature. The main results of the analysis presented in this paper are a) design requirements addressing the limitations of choreography modelling languages for embedded systems development and b) proposals for modelling language implementation technologies. The feasibility of these results is evaluated by redesigning an existing choreography modelling language and by implementing a prototype editor for the redesigned language.