Psychological safety, a pivotal factor in team dynamics, has been proposed as a crucial determinant of success in agile software development (ASD) teams and learning. However, the extent of its influence within the domain of large-scale agile (LSA) software development teams remains underexplored. This research investigates the multifaceted dimensions of psychological safety within LSA teams, examining both its precursors and outcomes. This study conducted semi-structured interviews with software professionals actively involved in LSA projects within a Swedish software consultancy company. The findings underscore the intricate nature of establishing a psychologically safe environment within LSA teams, revealing it as a multidimensional construct necessitating a proactive leadership approach, fostering open communication, and cultivating an ecosystem of constructive feedback. The study highlights the critical importance of intentionally shaping teams to facilitate continuous learning, ensuring remuneration safety, and implementing a comprehensive onboarding process for incoming team members. By fostering psychologically safe settings, LSA teams enhanced teamwork dynamics, heightened job satisfaction, and facilitation continuous learning and development. Notably, the absence of such an environment exacerbates the phenomenon of brain drain, exposing the tangible consequences of overlooking this fundamental aspect of organizational culture. This study proposes avenues for future research directions, aiming to further unravel the nuances of psychological safety and its cascading effects within the realm of contemporary LSA software development context.

In software engineering, technical debt (TD) has been widely investigated, but debt regarding social issues, people, and processes has not been explored as much. It should be noted here that we use nontechnical debt (NTD) as an umbrella term to cover social, process, and people debts. Although the number of studies on NTD in software is increasing, the majority of them are descriptive rather than rigorous, and there is no systematic development of cumulative knowledge. As a result, identifying the fundamental causes of NTD and the associated mitigation techniques in software engineering is challenging. Therefore, this study investigates the scientific evidence regarding NTD till date by conducting a systematic mapping review of software engineering research between January 2000 and October 2021. The search strategy resulted in 175 studies, 17 of which were identified as unique and relevant primary papers. The primary studies show that NTD and TD are inextricably linked. In addition, this study also captured a plethora of causes and mitigation strategies for managing NTD and thus makes four important contributions: (i) highlighting state-of-the-art NTD research; (ii) identification of the reported causes and mitigation strategies in the primary papers; and (iii) determination of opportunities for future NTD research.

This research paper examines the implementation and impact of customised roles in large-scale agile software development teams, specifically within the Scrum framework. This is a single case study based on 15 practitioners’ interviews from a Swedish software company to review the dynamics of role customisation. The two customised roles of Product Guardians and Security Masters are crucial for addressing complex secure software development, maintaining product quality and security, and fostering team self-organisation. The study also uncovers challenges associated with role customisation, such as the potential overburdening of individuals and disruption of self-organisation. The findings contribute to the discourse on agile methods' adaptability and provide practical insights for organisations considering similar role customisations. Furthermore, the research opens the door for future exploration of organization-wide roles that promote self-organisation.

Agil projektledning övningsbok innehåller flera olika slags övningar: instuderingsfrågor- praktiska övningar- diskussionsövningar- scenarioövningar. Agil projektledning övningsbok riktar sig till studenter i projektledning samt yrkesverksamma projektledare som vill börja arbeta agilt eller förbättra sin agila förmåga.

Boken har utsetts till Årets Projektledarbok 2008 av Svenskt Projektforum!



Motiveringen från juryn var följande: "Författaren - Tomas Gustavsson - har hittat ett intressant ämne som han beskriver på ett enkelt och lättbegripligt sätt. Detta är inte en "frälsningsbok" utan en mycket nyanserad beskrivning av begreppet "agila metoder", dvs projekt med föränderliga både krav och mål."



Agile är engelska och betyder smidig eller vig. I projektledningssammanhang har ordet översatts till lättrörlig för att peka på förändringsmöjligheterna med detta synsätt. Men det finns andra fördelar med Agile. Den, i mitt tycke, största fördelen består i möjligheten i att kunna slutföra projekt. Att slutföra projekt är en konstart som många eftersträvar men få behärskar.



De agila teknikernas lösning för att hantera denna konst är att delleverera små resultat ofta. Genom att planera, genomföra och leverera en mindre del av projektet får vi möjlighet att uppleva en del av slutresultatet tidigt och kan därefter ställa konkretare krav på resten av projektet. Vi kan dessutom stanna upp, utvärdera och enkelt förändra projektet under vägen. Metoderna (med namn såsom Scrum, XP, DSDM) härstammar från IT-projekt men går att appliceras på många projekt oavsett bransch eller miljö



Detta är en praktiskt bok! Med praktisk bok menas att den innehåller de checklistor, mallar och verktyg som krävs för att med boken som stöd kunna börja arbeta agilt.

Inter-team coordination has been recognized as one of the most important challenges in large-scale agile development settings. Except specific practices, such asScrum of Scrums meetings, certain roles are oftenreported to be responsible for areas of coordination incase studies. Although agile values state thatcoordination should be dealt with face-to-face byindividuals, two commonly used prescriptive frameworksfor large-scale agile development suggests contrastingways of coordinating regarding roles and theirresponsibilities. One propose additional coordinating roles leaving less mandate and autonomy to the single team while the other propose no additional roles, compared to the original roles of Scrum, allowing more autonomy to the teams. This literature review is an analysis of roles assigned with the responsibility for inter-team coordination in 42 case studies of large-scale agile development settings. The review shows that only four of the analyzed organizations appoints roles according to the large-scale agile frameworks. Rather, a wide range of different additional roles with different role tailoring is displayed where the majority is focusing on vertical coordination rather than horizontal coordination. In three of the cases, the role setup has specificallytargeted coordination for architectural issues. The study shows that the prescriptive frameworks are seen as toolboxes leaving the responsibility for tailoring to the single organization. This implies a stronger need for theoretical support on what to use as basis for tailoring of roles and their responsibilities.

In the last fifteen years we have witnessed a vast spread of new methods for managing projects within software development. In 2001, the Agile Manifesto stated the common values and principles of these methods, all aimed at producing better software. Several of these values and principals are specifically expressed for designing and programming software products. Since then, the benefits of these methods have led to a widespread use of agile project management even in non-software development contexts. But, how does these values and principals affect projects in non-software areas since some values and principals are not applicable? Do they perceive the same benefits? This paper presents a systematic literature review aimed at identifying benefits in projects adopting agile methods in non-software development contexts. Out of the 21 case studies analysed, most reported projects were from manufacturing companies but even from areas such as library management and strategy management. The most frequently reported benefits were related to team work, customer interaction, productivity and flexibility. The main parts of the benefits were corresponding to the first value in the Agile Manifesto: Individuals and interactions over processes and tools.

The benefits of agile ways of working in small teams have inspired larger organizations to implement large-scale agile frameworks. To manage dependencies between teams, there is a need for routines to plan and divide work between teams as well as routines to manage emerging dependency issues. These routines are often changed over time, but how tailoring is performed is not much studied. This study aims to fill that gap by presenting the tailoring of a planned coordination routine in three organizations over a period of one and a half year. By visiting planning sessions, 379 h of observation data were collected. Investigating details of this routine gives a much more dynamic view, compared to the static description presented in the framework. Different logics for tailoring could be seen in the three cases. For deciding on a cadence for the planning period, three diverse logics were used as the basis for the decisions: knowledge, time, and resources.

Software development organizations are adopting values, principles, and frameworks to implement agile ways of working today. But the agile methods were initially designed for use in small, single-team projects and routines for coordination between several teams have not been adopted in the same way as routines for coordination within the team. The Scaled Agile Framework has become the most common way to implement organizational routines for inter-team coordination, but critiques claim it to be too strict and formal, without leeway for adaption. This study investigates the dynamics of inter-team coordination routines at three organizations and provides thick descriptions of tailoring. Data collection was performed by 379 hours of observations and 28 interviews. The main findings highlight the variety in ostensive and performative aspects of coordination routines and how they change over time. Contrary to earlier findings, the ostensive and performative aspects in this study do not have opposing varieties. This indicates that the empirical relationship between ostensive and performative aspects might not be as atypical as previous results suggest. An important practical contribution is the described possible tailoring options when scaling up agile ways of working which contradict the view of the framework being too rigid.

Agile ways of working are nowadays used in many software development departments even in larger organizations. When scaling up agile ways of working, new practices for coordinating teams become necessary. Instead of inventing practices on their own, many organizations are implementing the Scaled Agile Framework but the impacts on team performance due to these practices are not much studied. Data was obtained by means of a survey questionnaire that was answered by 111 team members from two organizations, one from the automotive industry and one of the major Swedish banks. The study suggests that efficient inter-team coordination does not have a positive relationship to team performance. But, as shown in several other contexts, a high level of psychological safety has a significant positive impact on team performance in a large-scale agile software development setting. © 2018 CEUR-WS. All rights reserved.

Transforming into agile ways of working in large organizations can be performed in different ways. Many organizations choose a defined large-scale agile software development framework but how the transformation is carried out could be based on different sorts of logics. This paper investigates institutional logics at play in large-scale agile transformations. By studying two case organizations, the paper aims at improving our understanding of large-scale transformations by viewing software development as an institution. The findings displays diverse impacts due to two differing institutional logics when transforming into large-scale agile software development by implementing the Scaled Agile Framework. One contribution of this paper is to show the possibilities of using two institutional logics, Agile toolbox logic and Agile rulebook logic, for analyzing impacts of agile transformations.

Software development organizations worldwide are adopting values, principles, and frameworks to implement Agile ways of working. The advantages of Agile ways of working are seen in teams that are allowed a high level of autonomy. The Agile methods were initially designed for use in small, single-team projects, and routines for coordination between several teams have not been adopted in the same way as routines for coordination within the team. With several teams coordinating, autonomy must, to some extent, be sacrificed in the individual team. Work needs to be coordinated with other teams, and a project is often part of a portfolio or program. The purpose of this research is to investigate routines for inter-team coordination: how they are performed; if, how and why they are tailored, and the impacts of these added routines in relation to Agile values and principles, in particular team autonomy.

This thesis is based on empirical studies at three organizations with disparate business logics. One is a product development department in the automotive industry, one is a business bank, and one is an IT department at a Swedish government agency. Data has been collected from 379 hours of on-site observations, 28 interviews, and 201 answers to a survey questionnaire.

Insights from these cases build on coordination theories as well as institutional logics (new institutional theory). One contribution of this thesis is the rich descriptions of tailoring of inter-team coordination routines. Another contribution is the identified perceived impacts of the implemented inter-team coordination routines, especially regarding perceived changes to team autonomy. An important theoretical contribution is the identified and defined institutional logics (Agile toolbox logic, Agile rulebook logic, Flow efficiency logic, and Resource efficiency logic), which can be used for analysis of large-scale Agile software development projects.

Scrum and eXtreme programming, the first agile development frameworks, were designed with very few advice on coordination for work in larger scale were several teams cooperate toward a common goal. This lead to both wrong assumptions regarding the usefulness of agile ways of working in larger organizations as well as much individual tailoring with coordination practices in organizations. Now, the Scaled Agile Framework is gaining much attention in software development. This study contains an analysis of inter-team coordination practices prescribed in the framework and how they have been implemented in three organizations. Previous research on coordination has been criticized for having a static view on coordination with not enough focus on how to manage emerging dependency issues. The result of this study shows that the Scaled Agile Framework have four practices that cover both planning and emerging issues and three practices solely aimed at managing these emerging dependency issues.

Agile ways of working are nowadays used in many software development departments in larger organizations. When scaling up agile ways of working, new practices for coordinating teams become necessary, and many organizations are implementing the Scaled Agile Framework. The added practices for coordinating teams could have an impact on team performance, but they have not been much studied. In this study, data were obtained by means of a survey questionnaire that was answered by 201 employees from three organizations: one from the automotive industry, one government agency, and a business bank. The study suggests that efficient inter-team coordination does not have a positive relationship to team performance, which is contrary to previous studies. However, results suggests that a high level of psychological safety has a significant positive correlation to team performance. © 2022, The Author(s), under exclusive license to Springer Nature Switzerland AG.

Large-scale agile frameworks suggest several practices for coordination between teams in software development projects. These prescribed coordination practices are often described as how to be performed in detail but without explaining the intended impacts. At the same time, agile values emphasise the need for tailoring practices that are not helpful. This study examines how three agile coordination practices influence accountability, predictability, and common understanding, which are important conditions for coordination. A qualitative research strategy was used to investigate three case organisations that implemented the scaled agile framework (SAFe): one bank, one government agency, and one department within the automotive industry. The empirical data consists of 28 semi-structured interviews and observations. The findings show the differing impacts of three investigated agile coordination practices and how the tailoring of practices affects coordination. 

As agile ways of working are implemented in larger settings,inter-team coordination becomes increasingly important. Somedependencies between teams can be identified in advance, butmuch of the dependencies in software development emerge as thesystem evolve. A way to identify, manage, assess, and evaluatethe status of dependencies is to visualize dependencies betweenteams. New artifacts and routines for visualizing dependencies aresuggested from the increasingly popular Scaled Agile Framework,SAFe. This multiple case study focuses on how inter-teamcoordination is visualized by providing a rich description of twoyears of implementation and tailoring of the boundary objectcalled the program board at the (anonymized) organizations AGovand B-Bank. A total of 183 hours of observations and 14interviews were used for triangulation purposes. The findingspresent the difficulties of keeping visualizations up to date. Byinventing and tailoring the routines of managing the ProgramBoard, the current situation of dependencies could be visualizedand kept track of. The findings also indicate the importance ofhow dependencies are defined.

Forming autonomous, self-organizing, cross-functional teams in software development is becoming more common even in larger organizations, and many organizations are implementing the Scaled Agile Framework. When autonomous teams need to work together, they must sacrifice some level of autonomy since work needs to be coordinated with other teams, which could be a threat to team performance. This study presents how perceived autonomy has changed by listening to the voices from the teams in three large organizations. Although several respondents did not express any experienced changes to autonomy at all, others put forth important changes. The practices where several teams gather in joint events are important arenas in both positive and negative aspects. The arenas give teams a better overview and a sense of being empowered in using their veto right to stop overload of planned work. However, more detailed planning in every single team could cause less ability to switch work between teams and a sense of suffocation due to detailed routines and practices.

Software development organizations are adopting values, principles, and frameworks to implement agile ways of working today, even in larger organizations. When several teams need to cooperate, and development needs to scale, many organizations are implementing the Scaled Agile Framework. At the same time, both researchers and practitioners have raised critical voices towards this framework, and the impacts are not much studied. This study aims to fill that gap by providing perceptions of benefits and drawbacks experienced in three different organizations: one in the automotive industry, one government agency, and one bank in Sweden. The analysis of survey answers from 154 respondents showed that the most commonly perceived benefits from implementing the Scaled Agile Framework were increased visibility, overview, and transparency. Authors of the framework claim massive productivity gains in every single team but, regarding perceived drawbacks, a lack of productivity, focus, and efficiency were most commonly reported.

Large-scale transformations of agile ways of working have received more attention in the industry in recent years. Some organizations have developed their own solutions for scaling, whereas many have chosen trademarked frameworks. In large-scale agile software development, many developers and development teams carry out work simultaneously. When autonomous teams need to coordinate toward a common goal, they must sacrifice some level of autonomy. Development, testing, and integrations need to be coordinated with other teams and aligned with an organization's programs or portfolio. Through the conducting of 28 interviews and 17 on-site visits, this multiple case study explored how team autonomy changed in three agile software development organizations that implemented the Scaled Agile Framework (SAFe). The positive changes to team autonomy that they experienced as a result included getting a better overview, making better long-term decisions, giving and receiving help, and signaling limitations. We found two negative impacts on team autonomy: limited feature choice and enforced refinement. The study extends previous research on large-scale agile software development and improves our understanding of impacts on team autonomy.

Den här boken handlar om systemutveckling. Den handlar inte om programmering utan i stället om allt annat som du behöver veta om du vill arbeta med systemutveckling, exempelvis utvecklingsmetodik, projektledning, processorienterat arbetssätt,testverksamhet, säkerhet och att få system att bli robusta,driftsäkra och enkla att förvalta.

Det är en bok för både programmerare som arbetar i utvecklarteam eller projektgrupper och för produktägare, testledare eller projektledare som arbetar med mjukvara. Kort sagt, alla typer av roller som berörs av systemutveckling.

Boken är lämplig för undervisning i kurser för systemutvecklare,processutvecklare, kravanalytiker, testledare eller projektledare och är även ett användbart verktyg för den yrkesverksamme som vill få en helhetsbild.

Ledarskapsdagboken är en handbok för din personliga utveckling: utveckling genom att skriva, reflektera och träna.

På mindre än två timmar kan du vara igång med att lära dig en enkel och kraftfull metod för att skriva Ledarskapsdagbok.



Verktygslådan

I Ledarskapsdagboken finner du även Verktygslådan. Lådan innehåller "formler för ledarskap", tekniker som kan hjälpa

dig inför förhandlingar, svåra samtal och presentationer.



Ledarskapsdagboken och Verktygslådan vilar på fyra grundstenar:

Tänka på papper

Arbeta med mål

Träna - för att bli bättre

Reflektera över sig själv och omvärlden

Companies in the IT industry today often use agile project management methods to govern their projects. Agilemethods value high transparency, self-organizing teams and a process to inspect and adapt. Some of the tools and disciplines from these agile methods are purely aimed at software development. The hypothesis of this paper is that the agile project management methods are suitable in other areas as well. This paper presents preliminary findings and conclusions about using agile project management methods in public event projects.



The case study, carried out with an action research methodology, investigates the Swedish company Galaxen

who have organized public music and culture events since 1992. This research indicates that several techniques and principles, originally developed for software programmers, can be adopted also in the area of public events. Time-boxed iterations and visual tools for planning, collaboration and follow up are being used with great success

This paper presents the design of a tool for recurring quantitative self-assessment of IT Service Management (ITSM) process maturity in a financial institution implementing agile software development as a new way of working. This change brought on an increased need to monitor ITSM process performance, and a Design Science Research (DSR) project was launched to create an ITSM maturity assessment tool. Continual improvement of ITSM processes can be measured by performing a process maturity assessment, comparing the organization’s process performance against a best-practice reference set of processes. This paper reports a development project for a quantitative measuring survey-based tool. Due to the increasing use of agile methods, there is an increase in research attention to the coexistence of agile and ITSM maturity assessment tools. The results show that a company-wide ITSM process maturity assessment can be established as a survey-based self-assessment in an agile software development context. The aggregate scores from this self-assessment present a good indicator of the organization’s process performance, especially when complemented by a reference score. A key learning is that the iterative DSR methodology made it possible to create a tool that in good way measure ITSM process maturity in an agile context. 

Agile companies are not uniform. Consequently, agile transformations are conceived broadly, ranging from adopting agile methods and practices in software development teams or functions to building all-encompassing enterprise agility. Moreover, the targeted effects of agility may vary, and the success of transformations and the attainment of agility are measured in various ways. In this paper, based on a recent industrial survey study, we scrutinize holistically why companies want to transform, what types of agility they are aiming at, and how they gauge transformations. The survey data was collected during the COVID-19 pandemic in 2020. Most of the respondents were in large or very large companies in Finland and Sweden in diverse industry domains. The main findings indicate that there are many reasons for companies to transform both to improve external outcomes (fore mostly responsiveness) and to develop internal capabilities (adaptability, organizational learning). Companies seemed to have aims and goals with respect to all types of agility, including business agility. As the nature of transformations and the companies’ aims and goals vary, the transformations follow various means and measures. As a conclusion, for the hybrid era, we advise companies to consider how agility has benefited during the pandemic era, how hybrid work possibly affects the goals for agile transformations and the different facets of agility, and how to sustain agility in hybrid work.

In 2020, the global COVID-19 pandemic affected almost every company in some way also in the Nordic countries. Depending on the different industry sectors of the companies, the impacts have varied from minor risks to severe disruptions but also even booming businesses. In all, agility and resilience have been required to continue and even to survive. In 2018, we started conducting large-scale agile surveys in Finland and Sweden. For the 2020 survey round, we included questions about the current pandemic situation impacts and how agility has helped to respond. The respondents represented software professionals from different industries, not limited to information and communication technology (ICT) companies. The results indicate that although the perceived impacts have mostly been negative (53%), it is not all so. One-third (33%) reported positive impacts such as increased business and better well-being. The majority (55%) of the responses indicated that agility has helped to respond to the pandemic situation. Remarkably, 59% reported that their companies have improved agility during the past year. Improved agility appears to be positively related to the ability to respond to the pandemic. We did not discover significant differences between the Finnish and Swedish respondent cohorts.

Software development encompasses various factors beyond technical considerations. Neglecting non-technical elements like individuals, processes, culture, and social and organizational aspects can lead to debt-like characteristics that demand attention. Therefore, we introduce the non-technical debt (NTD) concept to encompass and explore these aspects. This indicates the applicability of the debt analogy to non-technical facets of software development. Technical debt (TD) and NTD share similarities and often arise from risky decision-making processes, impacting both software development professionals and software quality. Overlooking either type of debt can lead to significant implications for software development success. The current study conducts a comprehensive multivocal literature review (MLR) to explore the most recent research on NTD, its causes, and potential mitigation strategies. For analysis, we carefully selected 40 primary studies among 110 records published until October 1, 2022. The study investigates the factors contributing to the accumulation of NTD in software development and proposes strategies to alleviate the adverse effects associated with it. This MLR offers a contemporary overview and identifies prospects for further investigation, making a valuable contribution to the field. The findings of this research highlight that NTD's impacts extend beyond monetary aspects, setting it apart from TD. Furthermore, the findings reveal that rectifying NTD is more challenging than addressing TD, and its consequences contribute to the accumulation of TD. To avert software project failures, a comprehensive approach that addresses NTD and TD concurrently is crucial. Effective communication and coordination play a vital role in mitigating NTD, and the study proposes utilizing the 3C model as a recommended framework to tackle NTD concerns.

Background: Agile methodologies emphasise iterative development, customer collaboration, and flexibility in software development. However, challenges arise when agile practices are adoptedin larger projects. Process inefficiencies and redundancies, knownas process debt, result from the compounded complexities of expanding agile processes and workflows. However, strategies tounderstand and tackle it remain markedly inadequate.Aims: This study investigates process debt types, causes, andeffects in large-scale agile development and its connection withtechnical debt.Method: In this case study, we conducted fifteen semi-structuredinterviews with a Nordic IT company, primarily focusing on telecomrelated products like 5G secure solutions, testing tools, and basestation software. We performed a thematic analysis to examine thedata qualitatively.Results: The thematic analysis identified five process debt typeswith 28 sub-types: documentation (3), roles & responsibilities (5),synchronization (5), inefficiency & unsuitability (12), and infrastructure debt (3) identified causes and effects of process debt andidentified the correlation of process debt to technical debt based ondescriptions from interview data and researchers’ insights.Conclusions: Process debt, stemming from flawed agile practices in large-scale development, causes inefficiencies, reduces quality, and extends timelines, risking technical debt. Its managementis essential for the success of these projects

We conducted a case study to examine the challenges encountered in large-scale agile development (LSAD) within two Swedish software companies. While agile methodologies have proven successful in small and medium-sized projects, their implementation in large-scale software development projects can be problematic. To identify these challenges, we employed thematic analysis, which revealed a total of 26 distinct challenges. These challenges were categorized into three main themes: Processes and practices, Teams, and Organizational-level challenges in LSAD. By recognizing and addressing these challenges, projects operating in similar contexts can synchronize their activities and harness the advantages of agile methodologies at a large scale. The article delves into comprehensive discussions on these challenges, offering valuable insights and directions for future research endeavors.

Earlier research has focused on technical debt (TD). While numerous issues connected to non-technical aspects of software development (SD) that are equally worthy of”debt” status are neglected. Simultaneously, these types of debts regularly develop significant challenges to be addressed, demonstrating that the debt metaphor may be used to reason about elements other than technical ones. It motivates us to create the new umbrella term”Non-Technical Debt” (NTD) to investigate people, processes, culture, social, and organizational concerns under its cover. All types of debt are similar in some ways, and they are often caused by making risky decisions. Therefore, ignoring any one dimension of debt can have severe consequences on the successful completion of SD projects. This study investigates recent literature on the current state of knowledge about NTD, its causes, and mitigation strategies. By using a thematic analysis approach, we found five NTD types (i.e., people, process, culture, social, and organizational). We further identified their accumulation causes and discussed remedies for mitigation. 

Agile methodologies have emerged as transformative paradigms in the ever-evolving software development landscape, emphasizing iterative development, customer collaboration, and adaptability. As the scope and complexity of projects and organizations expand, applying agile principles within the context of Large-Scale Agile Development (LSAD) encounters distinctive challenges. The majority of challenges encountered in LSAD, technical and non-technical, are attributed to the accrual of social debt. However, a conspicuous gap remains in understanding and addressing social debt in LSAD. This study aims to fill this void by investigating social debt in LSAD through an in-depth industrial case study with a leading Nordic company specializing in telecommunications software and services and focusing on producing secure 5G network solutions. The study investigates the causes of LSAD's social debt and examines its impacts on secure 5G telecom software development. By addressing these objectives, this research sheds light on a critical aspect of LSAD's social debt, caused by 3C challenges(communication, coordination and collaboration), social confines challenges, community smells challenges, and organisational social challenges in the telecom sector that have been underrepresented in the existing literature.