Large-Scale Agile Project Management in Safety-Critical Industries: A Case Study on Challenges and Solutions

ABSTRACT

While agile project management offers benefits such as faster time to market and improved collaboration, scaling it to larger projects presents challenges, particularly in safety-critical industries. This research provides insights into the resistance to agile adoption due to regulatory constraints and other barriers. The findings contribute to information systems literature by identifying four challenges (organizational, technological, behavioral, regulatory) and complementing solutions to show how large-scale agile can work in safety-critical industries.

KEYWORDS:

• Large-scale agile
• case study
• project management
• safety-critical industry

Introduction

Rapid technological advances such as artificial intelligence, the Internet of Things, and cloud computing amplify the uncertainties businesses face in a dynamic competitive environment (Verhoef et al., 2021). In times when there is an increasing need for flexibility to remain competitive, traditional project management is deemed to be slow and inflexible. Inspired by small agile teams, organizations started adopting agile project management principles as a remedy (Boehm, 2002; Dikert et al., 2016). Agile project management has seen quick adoption in organizations over the past few years, and the scaling of agile across the organization has become a central topic (Rigby et al., 2018). Although software development and IT departments remain the most active users of agile methods with up to 90%, agile increasingly spreads throughout the organization toward operations, marketing, governance, supply chain, security, or sales (Janssen & Van Der Voort, 2020; Naseer et al., 2021; State of Agile, 2022; White et al., 2005).

Agile project management is defined by 12 principles that build its core (cf. Table 1). These principles have originally been introduced for small-scale software development teams (Boehm & Turner, 2005). In the recent decade, people have appreciated the style of work and flexibility that comes with agile. As a result, they want to apply agile to larger-scope projects to harvest its benefits (Abrar et al., 2019). In particular, digitalization initiatives and programs have begun to be managed and executed in an agile manner with the intention of faster execution (Fuchs & Hess, 2018). Although projects are often complex and differ in resources, using agile for large-scale projects might offer benefits for companies. These benefits include, inter alia, faster time to market, higher team productivity and morale (Rigby et al., 2018; Rodríguez et al., 2012), increased flexibility and adaptability (Hoeseb & Tanner, 2020), and improved collaboration with higher-quality organizational outcomes (Dybå et al., 2014).

Table 1. Agile principles (Fowler & Highsmith, 2001).

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Nevertheless, agile project management is not a panacea. Studies showed that scaling agile is difficult (Dikert et al., 2016; Kalenda et al., 2018), and challenges must be addressed to reap agile benefits. These challenges include coordination issues (Batra, 2020), the complexity of flexibility (Dybå et al., 2014), change resistance, and other organizational or technological barriers. Like other industries, safety-critical industries are engaging in digitalization projects. Organizations in safety-critical industries see the need to become more flexible to react to the uncertainties and dynamics of the market quickly (Fitzgerald et al., 2013). For example, Airbus CEO Tom Enders stated that:

The possibilities of the digital revolution must be put to good use. That involves designing, developing and manufacturing our products much more efficiently and much faster. In the aerospace industry, we are currently seeing a level of competition that we have never experienced before. (Bloching et al., 2015, p. 11)

Agile project management has been put forward in aerospace and industry (Fitzgerald et al., 2013). However, the production and manufacturing processes in safety-critical industries have a low fault tolerance, so that systems require significant effort in the design, development, and testing (Chang et al., 2013; Mendi et al., 2022). Requirements of regulated industries such as processes, tools, documentation and planning contradict agile’s values of individuals, interactions, collaboration and continuous change (Fitzgerald et al., 2013). Therefore, the path to agile is not without obstacles in large, heavily regulated industries such as aerospace. Beyond the “normal agile challenges,” additional difficulties introduced through regulatory requirements can significantly hinder agile digitalization projects. These difficulties highlight the tension between agile’s iterative, flexible nature and the rigid, detailed requirements of legal regulations.

These tensions raise the question of whether large-scale agile can work in industries characterized by high regulation and safety standards. As a result, we put forward the research question:

What are the challenges of large-scale agile project management for safety-critical industries, and how can they be overcome?

This research question is examined by a case study comprising 12 interviews with high-level experts at a management consultancy working for a large international aerospace company. The aerospace industry is known to be highly regulated, which can provide insights into the resistance to agile adoption due to regulatory constraints. While there are already studies on the implementation of agile in this particular industry, they have focused on general agile implementation and less on large-scale factors (Gunasekaran et al., 2002; Presley et al., 1995; VanderLeest & Buter, 2009). Our paper contributes original theory along the four dimensions of behavioral, technological, organizational, and regulatory challenges and mitigations of large-scale agile in safety-critical industries. Implications include the development of four challenges and solutions when implementing large-scale agile. We find that regulatory challenges are most difficult to overcome. Future research can investigate which components of agile project management are applicable to different external and internal environments. Moreover, we derive practical implications for organizations on how to respond to the challenges and how to implement the solutions.

Related work

Agile literature

Agile is an umbrella term for multiple approaches originating from software engineering, e.g., Scrum or extreme programming (XP), which substitute traditional “waterfall” project management (Abrar et al., 2019; Dingsøyr, Moe, Fægri, et al., 2018). Whereas traditional project management follows the plan, design, execute, and validate pattern, e.g., PMI, Prince2 (Abrar et al., 2019; Bick et al., 2018), agile suggests that upfront and long-term planning are not useful. Long-term plans provide insufficient flexibility and cannot deal with a dynamic market environment and changing customer demands (Bick et al., 2018). According to agile principles, short-term planning and continuous control of requirements are superior to long-term plans (Abrar et al., 2019; Cohn & Ford, 2003; Dingsøyr et al., 2014; Dybå et al., 2014). For agile, planning is tacit and in the heads of the people (Boehm, 2002). Only minimal specifications are explicated over detailed and explicit scoping (Dybå et al., 2014). The implicit scoping is iteratively refined with the customers through continuous communication and collaboration, embracing feedback and change (Boehm & Turner, 2005; Dybå et al., 2014). Collaboration and leadership enable continuous governance of the emergent outcomes instead of top-down command and control (Dingsøyr, Moe, Fægri, et al., 2018; Mahadevan et al., 2015). Agile collaboration requires informal communication (Boehm & Turner, 2005). Self-management and autonomy are core values with little oversight through scrum masters or product owners (Dingsøyr, Moe, Fægri, et al., 2018). Scrum masters only ensure that self-management processes are correctly implemented, and product owners oversee the trajectory of the product and bridge communication to the customer (Dingsøyr, Moe, & Seim, 2018).

Therefore, agile offers several opportunities for organizations. Through informal communication and tacit knowledge without extensive upfront planning, agile teams can build systems faster and bring them to market quickly (Mehta et al., 2023; Rigby et al., 2018; Rodríguez et al., 2012). Increased flexibility and adaptability allow reacting to ambiguous and changing customer demands in turbulent environments (Hoeseb & Tanner, 2020). Self-managed and autonomous teams can achieve effective collaboration through short communication pathways, informal communication, and avoiding overhead costs (Dybå et al., 2014). Informal communication with continuous and iterative quality controls promises higher system quality and customer satisfaction. The collaborative nature and self-management make employees happy (Venkatesh et al., 2020). Nevertheless, agile is not a cure-all. Agile or traditional approaches can be suitable depending on the nature of the project – for example, project size, scope, stakeholders, and regulations (Boehm, 2002). Agile project management is defined by 12 principles that build its core (cf. Table 1).

Large-scale agile

Agile principles were initially introduced for small-scale software development teams with tacit knowledge and short communication pathways (Boehm & Turner, 2005; Meso & Jain, 2006). The success of agile in small software development projects has led to an interest in translating the success to large-scale agile projects (Dingsøyr, Moe, Fægri, et al., 2018). What is “large” in large-scale agile (Batra, 2020; Dingsøyr et al., 2019)? Large-scale agile can refer to a project with a single big team or large multi-team projects. Various rules of thumb have been proposed to demarcate large-scale agile projects from others. For example, Batra (2020, p. 66) looks at the number of people and comes up with “a cutoff of 20 for large and 50 for very large projects.” Conversely, Dingsøyr et al. (2014) consider the number of teams and define a project with more than 10+ teams as very large. Others distinguish size by budget and consider projects beyond the >€10 million budget as large (Jorgensen, 2019). These numbers for large-scale agile projects shake up the underlying assumptions of agile. Managing informal communication and tacit knowledge becomes increasingly challenging with a growing project size (Abrar et al., 2019). As a result, various frameworks have been suggested, for example, large-scale Scrum (LeSS), the Scaled Agile Framework (SAFe), the Nexus framework, the Disciplined Agile Delivery (DAD), the agile portfolio management, or Scrum-of-Scrum (SoS) (Bick et al., 2018; Dingsøyr et al., 2019; Rolland et al., 2016) with the most popular framework being SAFe in 2022 (State of Agile, 2022). Despite the promises, the rapid increase of agile across business functions and industries has uncovered novel challenges (Bick et al., 2018). The basic principles of agile might not work in large-scale projects (Dingsøyr, Moe, Fægri, et al., 2018) and previous research identified different categories of challenges related to coordination, employee perceptions, management commitment, knowledge and training, or regulations.

First, large projects entail more people than agile in small teams, leading to coordination issues (Hannay & Benestad, 2010). Large-scale agile requires coordination across multiple teams and departments, which can be challenging (Kalenda et al., 2018; Rolland et al., 2016), specifically if communication and knowledge sharing should be informal between teams (Bick et al., 2018; Smite et al., 2019). Self-management is associated with impaired coordination in large-scale projects (Dingsøyr, Moe, Fægri, et al., 2018). For effective coordination, different modes, e.g., group, individual, or impersonal coordination, and team roles are required, e.g., mentors, translators, and champions (Dingsøyr, Moe, & Seim, 2018; Hoda et al., 2013). Successful large-scale projects are characterized by an upfront robust architecture design to achieve their outcomes, which runs counter to agile principles (Dingsøyr, Moe, Fægri, et al., 2018). Scope problems can occur in large-scale agile due to the absence of upfront planning and documentation. Typically, large projects follow established process standards, which stakeholders must sign off (Boehm & Turner, 2005). Resource allocation, slack, and timekeeping can become problems due to a lack of control. Roles, responsibilities, resources, and costs must be assessed, which is more difficult without explicit planning and only tacit knowledge (Boehm & Turner, 2005). Large-scale projects have more internal and external stakeholders, so intentional communication is required over informal pathways (Dingsøyr, Moe, & Seim, 2018). Agile methods can be ineffective when meeting overloads occur and informal knowledge exchange no longer works (Paasivaara et al., 2012). Overall, coordination becomes more complex with larger teams, suggesting explicit management may remain superior over agile approaches (Hobbs & Petit, 2017).

Second, introducing agile in incumbent organizations is problematic because it necessitates changing established processes and pushing for more team responsibility and autonomy (Cohn & Ford, 2003). Existing organizational processes and technological architectures prevent the iterative and planless agile approach (Hobbs & Petit, 2017). It is particularly challenging for organizations transitioning from traditional management approaches. A common error is a too-fast rollout, leading to change resistance (Kalenda et al., 2018). Change resistance is a behavioral challenge (Conboy et al., 2018; Dikert et al., 2016) that occurs at multiple levels of the organization, being stronger at the middle and higher levels of management (Long & Starr, 2008; Moe et al., 2019). It can result from the increased transparency incurred by the agile way of working. The increased transparency contradicts established organizational arrangements, such as top-down mandates (Dikert et al., 2016; Kalenda et al., 2018), and trigger fears of power loss. Concomitant with a lacking trust into their teams’ judgments, managers fearing for power loss may end up micromanaging their team, jeopardizing the agile purpose (Moe et al., 2019; Paasivaara & Lassenius, 2016a, 2016b). Conversely, employees can be resistant if the agile way of working is enforced through management (Lansmann et al., 2023). Enforcing agile creates ressentiments if employees lack knowledge about agile methods (Paasivaara, 2017).

Third, according to Kalenda et al. (2018), a root cause for other challenges is the lack of knowledge and training in agile concepts. Management lacks investment in training and development and underestimates the required effort to change the project management approach successfully. Qualified coaches are rarely sought (Hajjdiab et al., 2012; Kalenda et al., 2018). Because of this, employees are trained improperly, and agile beginners may take over the role of coaching, which ultimately leads to an insufficient or incorrect understanding of the agile approach (Dikert et al., 2016; Silva & Doss, 2007). Examples of this misunderstanding are the presentation of unfinished increments in reviews that violate the agile principle of only showcasing finished increments or neglecting customer involvement in system development (Paasivaara & Lassenius, 2016b; Schatz & Abdelshafi, 2005).

Finally, the level of regulation varies between industries, with some industries subject to detailed scrutiny, such as aerospace, defense, or pharma. System failure in these industries comes with severe consequences – for example, the cases of Therac-25 failure (Leveson & Turner, 1993) or the Ariane 5 failure (Dowson, 1997; Nuseibeh, 1997). Regulations complicate adopting agile approaches (Nuottila et al., 2022). Agile emphasizes keeping documentation to a minimum and thriving in communication with stakeholders and customers. These values contradict the compliance requirements for highly regulated industries (Heeager & Nielsen, 2018). For example, in the case of Nuottila et al. (2022), the regulation forbids sharing specific information with stakeholders, while in the case of Heeager and Nielsen (2018), medical devices need sufficient documentation for traceability purposes.

Agile in safety-critical industries

Software and digitalization are essential in almost any industry, and naturally, companies from safety-critical industries engage with software development methodologies, for example, in aerospace, pharmaceuticals, food, or medical (Bloching et al., 2015; Heeager & Nielsen, 2018). They see the need to become more flexible to react quickly to the uncertainties and dynamics of the market and adopt agile principles as part of their digitalization projects (Fitzgerald et al., 2013).

Safety-critical generally means that system failure has severe consequences for humans, including human harm (Heeager & Nielsen, 2018). As a result, the safety and security of systems are imperative in safety-critical industries. Systems development typically happens in large-scale projects with long lifetimes (Heeager & Nielsen, 2018). Since the consequences of failure in these safety-critical systems are severe, the industries are under strict regulations with enforced procedures and standards, e.g., ISO 9000 (Hoyle, 2005). The regulations prescribe how to perform formal quality assurance to ensure quality and safety requirements are correctly implemented (Fitzgerald et al., 2013; Heeager & Nielsen, 2018). Quality and safety must be considered from the start and may contradict an iterative, change-embracing approach (Fitzgerald et al., 2013; Rolland et al., 2023).

Typically, extensive documentation demonstrates compliance with the “formal standards, regulations, directives and guidance” (Fitzgerald et al., 2013, p. 864). Documentation provides traceability, which is key for safety-critical systems and is required by the regulations. Traceability evidences that the formal processes have been followed as regulated (Heeager & Nielsen, 2018). Beyond the traceability of the process, audits, that is, formal verification of outcomes are often needed to bring systems to market (Bianco et al., 2010). For example, the food industry has procedures for verifying and validating foods, and medical devices require traceability and audits to show their efficacy (Mehrfard & Hamou-Lhadj, 2011; Mehrfard et al., 2010).

Changing requirements can severely impact safety characteristics and complicate standard processes and safety verification (Heeager & Nielsen, 2018). Received approvals must be requested again pending design changes to a system. Informal requirements from continuous customer engagement must be translated to formal requirements that stand the tests of regulation and strict audits (Heeager & Nielsen, 2018). The iterative nature of always having a running prototype (Cohn & Ford, 2003) clashes with the complexity of safety-critical projects. Typically, these projects follow a V-model with extensive quality management. Transitioning to iterative models is challenging and costly when changing requirements must be tested and audited multiple times (McHugh et al., 2012; Paige et al., 2008).

Safety-critical systems are rising in number and complexity with more information technology-based components due to the digitalization (Heeager & Nielsen, 2018). So far, there is little but growing adoption of agile practices in safety-critical industries (Cawley et al., 2010; State of Agile, 2022). Agile project management contradicts the regulatory needs of planning and documentation (Pfleeger et al., 1994). Both traceability (process) and audits (outcome) are challenging to implement with agile approaches. As a result, organizations in these industries adopt only selected practices of agile that are commensurable with regulation and formal approval processes (McHugh et al., 2012). Alternatively, they do not adopt agile at all (Hajou et al., 2014), as traditional project management caters precisely to these needs with its extensive planning and documentation (Boehm & Ross, 1989; Heeager & Nielsen, 2018; Zultner, 1993). Documentation requirements have been dubbed “a main obstacle” for agile adoption (Heeager & Nielsen, 2018, p. 28). Despite these challenges, practitioners from safety-critical industries want to use agile (Bloching et al., 2015), because traditional large-scale projects in these industries are plagued by project failure, e.g., cost or time overruns, and difficulty in managing (Flyvbjerg, 2014).

Research on agile in safety-critical industries is only emerging but direly needed (Conforto et al., 2014; Hobbs & Petit, 2017), because current knowledge remains contradictory (Heeager & Nielsen, 2018). Previous research focused on agile in small-scale software development or information technology industries. It is unclear if the success factors of small-scale agile, such as cooperative organizational culture, proactive change management, experienced team members, or hybrid modes (Conforto et al., 2014; Mahadevan et al., 2015; Moe et al., 2019), hold for large-scale agile in safety-critical industries. On the one hand, nascent research showed that agile may not be “incommensurable” with regulated environments (Fitzgerald et al., 2013, p. 870). It has been ideated how organizations could assure quality, safety, traceability, and verification via continuous compliance and tool support (Fitzgerald et al., 2013). Similar ideas have been put forward by Heeager and Nielsen (2018), who suggest how contradictory regulatory requirements can be integrated with agile practices. On the other hand, skeptics claim that large-scale agile projects may be infeasible in regulated industries (Hobbs & Petit, 2017; Rolland et al., 2016; Williams & Cockburn, 2003). Williams and Cockburn (2003, p. 40) state that agile for safety-critical systems is a bad idea: “the agile value set and practices best suit colocated teams of about 50 people or fewer who have easy access to user and business experts and are developing projects that are not life-critical.” Conversely, Dingsøyr, Moe, Fægri, et al. (2018, p. 491) state that organizations must merely “find a ‘sweet spot’ between traditional and agile development based on the level of risk that the project is willing to take.” Given little evidence and the lack of knowledge on agile in highly regulated and safety-critical industries, more research is needed. This controversy is exacerbated by the case-based nature of previous research. The cases are partially outdated and use old or none of the current frameworks (Batra, 2020; Rolland et al., 2023). As a result, “advice on large-scale agile development is still in a nascent state,” specifically for safety-critical industries (Dingsøyr et al., 2019, p. 37).

Materials and methods

Research approach

This research is in line with previous research on agile project management and uses a case-based method to address the research question (Batra, 2020; Ozkan et al., 2023; Yin, 2018). One author was working for the case company at the time of data collection and this intimate knowledge was crucial, as agile implementations are always adapted (“cherrypicked”) and idiosyncratic to an organization (Hron & Obwegeser, 2022). The case study approach facilitates observing the phenomenon of large-scale agile in situ (Benbasat et al., 1987). The sustained contact with the participants in case research allows identifying the “lived experiences that otherwise might be overlooked or concealed in a questionnaire or interview-based research” (Jörden et al., 2022, p. 528). These lived experiences are paramount to “resolve conflicts between espoused and applied theories” (Avison et al., 1999, p. 95). Given the contextual nature of agile, Rolland et al. (2016, 2023) clarified that it is crucial to uncover the underlying assumptions of agile in the organization. A qualitative approach can access employees’ tacit knowledge. The insights into their tacit knowledge allow for unpacking the underlying assumptions and the human perceptions, attitudes, behaviors, thoughts, and motivations in the context of their daily work with agile. These insights are essential to investigate and theorize the challenges of large-scale agile project management in safety-critical industries.

Case context

This case study was conducted at the companies AEROCOMP and CONSULTCOMP. AEROCOMP is a multinational aerospace corporation that designs and manufactures commercial aerospace and defense equipment, for example, commercial and military aircraft. It is one of the largest aircraft manufacturers with offices and assembly plants worldwide. AEROCOMP’s business is characterized by an industry 4.0 transformation, a radical transformation of how systems are designed and manufactured. AEROCOMP must deal with market needs and customer expectations rapidly changing in the industry while maintaining the highest standards of quality and performance. To remain competitive in the future, digital transformation initiatives commence across their entire system lifecycle, including agile project management approaches.

CONSULTCOMP is a leading management consulting company in Europe that assists AEROCOMP with implementing multiple large-scale agile projects. CONSULTCOMP specializes in safety-critical industries. Their primary domain is aerospace, but they also work in medical and automotive manufacturing. They have longstanding experience with the design and development of safety-critical systems and support their clients in operational efficiency and crafting innovative business. CONSULTCOMP helps AEROCOMP to optimize the digital transformation of their aircraft business. They understand digitalization as a continuing process requiring new project management approaches and focus on agile using the SAFe framework. At the time of data collection, one author worked at CONSULTCOMP on a large-scale agile transformation project procured by AEROCOMP. This setting of AEROCOMP and CONSULTCOMP provides an ideal case for investigating large-scale agile in the safety-critical industry.

Data collection

For this research project, semi-structured interviews were chosen as the primary data collection method. Semi-structured interviews are a suitable method because they allow for balancing open-ended ideas from the interviewees with the need to address the research question (Myers & Newman, 2007). During semi-structured interviews, the conversation can be adjusted based on the flow of the interview while remaining consistent toward the research question (Goldkuhl, 2019). The interviews are explanatory in nature as they are used to explore the challenges and solutions of large-scale agile in safety-critical industries (Recker, 2021). To guide the interviews, we created an interview guideline that covered the areas of (1) professional introduction of the interviewee; (2) introduction of the large-scale agile project by providing characteristics such as scope, industry, headcount, and other metrics; (3) the challenges experienced in agile at scale; (4) and the solutions used for the respective challenges (see appendix A Interview Guide). The development of the interview guideline was informed by the related work on large-scale agile in safety-critical industries and fused with the subject matter knowledge from the author working for the case company at the time of data collection (Brinkmann & Kvale, 2018; Rowley, 2012). We designed the questions to encourage the interviewees to reflect on best practices and challenges for large-scale agile, thereby addressing our research question (Rowley, 2012; Schultze & Avital, 2011). This design resulted in a mix of direct and probing questions (Brinkmann & Kvale, 2018). The number of direct questions aligns with established practices (around 12) and allows for flexible follow-ups with probing questions (Rowley, 2012). The wording of the questions was brief, simple, and based on the appropriate jargon to minimize social dissonance during the interviews (Brinkmann & Kvale, 2018; Myers & Newman, 2007). Finally, the questions should avoid common pitfalls, e.g., implicit assumptions, two questions in one, or being too invasive, and all authors agreed on the final interview guideline (Rowley, 2012).

The interviews were conducted with employees from CONSULTCOMP working for AEROCOMP. Through the recommendations of experts in the companies, interview participants were identified. The interviewees were experts who specialized in agile methods, at least senior consultant-level or higher and had extensive experience working on large-scale agile projects. According to CONSULTCOMP’s company regulations, the title “expert” is awarded based on job descriptions, job responsibilities, and tenure at the company. A senior consultant is an expert in a particular service area (here: agile transformation) and is responsible for successfully implementing individual projects. A manager is an expert in multiple areas (here: agile transformation) and a domain (here: safety-critical aerospace), with responsibility for single or multiple projects and personnel responsibility. A senior manager is an expert with program responsibility (i.e., an extensive line of projects) in their domain (here: safety-critical aerospace), with leadership in coordinating and managing the most challenging projects. A vice president is a senior leader of the company (Table 2). The interviewees from CONSULTCOMP have been working on multiple large-scale agile transformation projects for AEROCOMP. The headcount of AEROCOMP personnel working on a solution or product affected by a large-scale agile transformation project ranged from 100 to 10,000 people. Typically, the large-scale agile projects spanned multiple business units and countries, and once even an entire subsidiary of the client organization. Project runtime was between one and five years, with 10 to 50 consultants from CONSULTCOMP working on each large-scale agile project.

Table 2. Interviewees’ characteristics.

Code	Position	Company Tenure (years)
P1	Manager	4
P2	Senior Consultant	3
P3	Senior Consultant	3
P4	Manager	4
P5	Senior Design Engineer	11
P6	Senior Consultant	2
P7	Vice President	8
P8	Senior Consultant	2
P9	Senior Consultant	3
P10	Manager	5
P11	Manager	5
P12	Senior Manager	5

We deliberately chose to focus on a few seasoned experts to access their intimate knowledge and insights on large-scale agile in safety-critical industries (Yin, 2018). Limiting ourselves to experts with long tenure allowed us to benefit from their experience and uncover the details of agile management for large safety-critical projects. The author conducting the interviews was working for the case companies at the time, enabling close association with the interviewees and enhancing the validity of the fine-grained, in-depth insights (Crouch & McKenzie, 2006). In total, 12 interviews were conducted with participants (Table 2), with a total of 360 minutes of recorded interviews. Earlier research has shown that 12 interviews can be sufficient to reach an appropriate level of data saturation (Guest et al., 2006). The last few interviews did not provide any additional information, and therefore, did not merit more interviews as we achieved theoretical saturation (Saunders et al., 2018).

The interviews were conducted between March and May 2023 via Microsoft Teams due to the case companies’ international and geographically dispersed nature. Online interviews have the additional benefit of reducing bias during interviews (Schöbel & Tingelhoff, 2023), because interviewees feel safer and more comfortable to “be themselves” (Lo Iacono et al., 2016). The interview language was English. Technical issues did not occur, and all interviews were fully recorded and transcribed. All interview participants were thoroughly informed before they participated in the research. The research project was explained clearly and in appropriate detail, including what data will be collected and how it will be anonymized, stored, and distributed. Participation was voluntary and offered without coercion, bribery, or misinformation. The participants consented to the publication of anonymized results. The research adhered to the international research ethics guidelines in information systems (AIS Code of Research Conduct). Ethical review and approval were not sought for this study because the research entailed a non-interventional study, posed no greater than minimal risk to participants, and ethics approval was not legally required in the country where the research was conducted. The original data is stored securely and remains confidential. Legal requirements on data protection are adhered to.

Data analysis

Case research and interviews provide rich textual data. For theorizing from these rich textual descriptions of large-scale agile project management, we make use of grounded theory (Corbin & Strauss, 1990, 2008). The grounded theory approach allows contextualizing the observations, which is needed because of the unique implementation of agile and the need to unpack the assumptions underlying agile. The author, working in the company, coded the materials due to conducting the interviews and having an intimate understanding of what the coworkers meant by their statements. The codes were then discussed with the remaining authors. First, an open coding of the interview transcripts was conducted to identify first order concepts. The first order concepts remain close to interviewees’ words and are illustrated with selected representative quotes. In a second step, axial coding was performed to identify second-order themes from the first-order concepts. Finally, the second-order themes were reduced to aggregate dimensions, upon which our report of the findings is based (cf. Figure 1). The reporting of the first-order concepts, second-order themes and the aggregates dimensions follows Gioia et al. (2013).

Figure 1. Data structure.

Results

The results of this study are depicted along the four aggregate dimensions of behavioral, technological, organizational, and regulatory challenges. These dimensions were derived by aggregating the domains of the second-order themes at a higher level. Afterward, solutions to these challenges are reported and mapped to the challenges and four dimensions (cf. Table 3).

Table 3. Challenges and solutions.

Challenges	Solutions
Behavioral
Change Resistance	Classic change management measures, incorporating gamification, assigning additional responsibilities, actively celebrating successes
Integration of non-development functions	Cross-functional team training and collaboration
Lack of knowledge about agile	Investment in training and coaching, acquisition of knowledge from experts
Technological
Complications in tool adjustments and selection	Gaining management attention to provide budget for infrastructure and experience
Progress measuring	Development of dashboards to display project progress
Organizational
Issues with workload estimation	Introduction of different maturity levels for requirements, correction of team availability calculations
Task prioritization	Acquisition of knowledge
Underestimation of effort of the agile implementation	Acquisition of knowledge, preferably from external sources
Incorrect implementation of agile	Acquisition of knowledge, preferably from external sources
Regulatory
Additional documentation required by regulations	Adjusting the sprint cycle to account for the required time to create extensive documentation
Increased confidentiality requirements	Proxy developers, separated backlogs
Resistance to the agile way of working due to regulations	Awareness and necessary changes from the beginning, adjusting the agile way of working to not harm team atmosphere

Challenges

Behavioral challenges

Resistance to change occurred before starting a project but also when a project was already ongoing. The interviews uncovered three primary reasons people resist change toward agile project management. First, one consultant explained that people constantly question why they are supposed to work agile: “Explain why are we doing it now in an agile way with SAFe? Why are we doing things the way we do? For instance, only focusing on the so-called MVP minimum viable product? There were always discussions here, but we need this requirement and this requirement, otherwise the end customer, so in this case the business, won’t be happy” (P8). People disliked the concept of the minimum viable product (MVP), because they only understood it as an unfinished and rudimentary product. Second, the employees are “[…] used to the process and you did that for 20 years, it’s very hard for the people to change really and adapt to a new way of working” (P1). Some interviewees pointed out that there was a demographic trend in this behavioral resistance, as it was dependent on the “[…] generation involved. Younger employees tend to be more interested in adopting this new way of working” (P2). Third, people lacked knowledge as they do not understand how agile can work for non-software development projects: “they understand that it works for software where you constantly deliver new software, new updates, patches and so on, but, for example, for something that is coming from a hardware perspective, or for a concept, or for whatever you you’re not programming, they do not understand how this concept of agility would work for them” (P11). The integration into the agile way of working proved to be particularly hard for such non-software development functions as they “[…] stumble upon the fact that they have to change the way of working, and they don’t understand why this is a large factor […]” (P11). People do not understand the need for changing their ways of working. This lacking understanding can be caused by several different reasons such as lack of communication through management, lack of knowledge about agile, or an aversion to change.

Technological challenges

Safety-critical industries are not only hardware-focused, but they are also heavily involved in software applications, either for the manufacturing process or the final product. Hence, software and its development play a significant role in their digital transformation. Agile software development involves a high number of releases through continuous integration and continuous delivery (CICD). However, CICD requires skills and a suitable infrastructure. The interviewees reported that on their respective projects, CICD posed significant challenges: “[…] the whole CICD environment and pipeline was not really set up well and also the team was just inexperienced and managing it at the beginning. It got much better in the end, but in the beginning, there were huge challenges” (P12). This challenge is mostly caused by a lack of investment into IT/IS infrastructure and personnel training. Such investments require management commitment to develop the knowledge of performing CICD. Lacking commitment and knowledge about CICD caused trouble at the beginning of the projects. Deployment and integration work was faulty, which led to bugs in the deployed software. These bugs required fixes and added additional workload and pressure to the schedule. It was mentioned that when asking for additional CICD infrastructure “[…] a lot of clients hesitate on this, but they say we can get more developers and we can get more product teams that maximize our throughput in the product systems” (P8). The interviewee indicates that there is indeed budget available but the management is not aware of what CICD is, how it works, and why it is needed.

Organizational challenges

The organizational challenges can be distinguished into (1) lack of knowledge and experience of agile methods, (2) lack of management commitment, and (3) the size of the project.

When it comes to the lack of leadership commitment, interviewees complained that management overruled the decisions of the agile teams. One of the interviewees stated that:

[…] the leadership, commitment and the understanding of an agile transformation is always a very big aspect. […] Customers or clients that don’t really know at the high level or understand the agile framework. It is a very abstract way of working, a totally new way of working and in comparison to all traditional ways and this adds up complexity […]. (P1)

It is crucial that the management and leadership fully understand and support the agile values and approach. This was not the case for two projects at AEROCOMP, where the managers went ahead and overruled decisions that were already made by the team. Overruling decisions demoralized the team. It shows that the manager does not trust the team’s decisions. In another case, the manager was simply unaware that decisions are to be made by the team according to the principles of agile. The manager reverted to a traditional way of working, following a top-down management approach.

Project size creates challenges for implementing agile. One interviewee stated: “I think the biggest challenge at this client is and the large-scale transformation over all different business units who have a different culture, different way of working” (P1). Large-scale agile projects concern many aspects of a company. AEROCOMP is spread across multiple countries and time zones, resulting in different ways of working, cultures, and legislations. The geographic dispersion increases the complexity of the agile project management, as agile presupposes a unified culture of values, communication, and shared approach to manage all aspects of the project and the organization. An organization having different internal subcultures, thus, is faced with unifying the subcultures toward the agile culture, rendering the adoption of agile more difficult. Another factor is that agile aims for continuous face-to-face communication, which can be difficult when people are in different countries.

The largest number of challenges are created by a lack of knowledge and experience with agile. Lacking knowledge creates challenges in the transition toward but also in the execution of agile. During transition, companies lack a clear purpose for why they want to switch to agile. In one of the interviews, a senior agile expert stated that:

The first challenge I’m facing basically at all the clients is that they did not really understand or define the actual purpose why they’re using agile methods or practices. So, for all of them, it’s either, let’s say it’s given a natural that they are using agile because it’s a project management or product development trend right now; or a lot of successful companies in the technology area or start-ups, such as Spotify, and so on are using it very successfully. But in most of the cases, I experienced that they did not really. They are not able to explain the reasoning behind why they are actually using agile. (P11)

Companies tend to follow the agile trend but lack a clear purpose for transitioning toward agile. They underestimate the effort required to perform a project management transition, causing insufficient staff training or a lack of allocated budgets. One interviewee mentioned that “[…] the role of the product owner and the role of the scrum master are sometimes assigned to the same person. That creates problems because in the agile framework, this is not the way it’s supposed to work” (P2). Duplicate roles are not desirable in agile, as these two roles have two different, partially contradictory purposes. During execution, the teams faced issues with workload estimation during planning, task prioritization, and tool customization. In terms of workload estimation, the teams consistently underachieved and did not reach their set workload. The main issue was the way agile wants to estimate workload, since an estimate should be made on complexity and not purely on effort in relation to the other open tasks. Inexperienced teams faced scope creep as they wanted to add too many features for an minimum viable product (MVP), which complicated workload estimation.

The meeting structure of agile with its frequency and different formats of face-to-face encounters proved to be too high, such that employees were unable to complete their day-to-day tasks. People found it difficult to find “[…] the right balance between having enough touchpoints for regular alignments, and on the other side still having enough time for productive work” (P9).

Regulatory challenges

Many interviewees agreed that regulation makes working agile more difficult. Regulations were industry-specific:

You have a lot of governmental regulations and when it comes to the product that you’re producing, because it a certain point you can put people at risk, right? So, the product that you’re developing needs to be off top quality needs to be top notch. And therefore, there is a strict process and they also have probably very strict governance that they have to apply. (P6)

In all cases, the regulation resulted in additional efforts for the agile implementation. CONSULTCOMP required additional personnel in the form of an entire development team, which were called “proxy developers” who had the security clearance of AEROCOMP to work on the agile project. These additional resources resulted in an additional backlog, documentation in two versions, and extra coordination efforts within the teams. One interviewee stated:

[…] there are a lot of software verifications that needs to be done in a very complex way that is described and demanded by the different authorities that the industry and the company operates in. So it was not just us developing and testing our software, but also doing very extensive documentation of the development itself and of the testing. So, prior to each major release we had like weeks, I think four to six weeks of software validation that we had to run through. This was really hindering us in working agile and releasing more frequently as well. (P12)

The recent diesel gate scandal in the automotive industry using illegal software to cheat emissions tests and deceive regulators about the true levels of nitrogen oxide emissions from their diesel vehicles have resulted in additional frameworks such as Aspice: “Aspice is a framework to document every requirement from the concept, to the development, to testing and it follows a sequential way” (P10).

Another interviewee mentioned that regulation can be a reason for not introducing agile or, alternatively, customizing the agile way of working, as the “standard” approach could harm the team atmosphere:

Agile is not the solution for all kinds of topics. If you have a very regulated industry like the finance sector, the public sector, or also sectors like pharma […]. Then I think you can take certain practices from agile but I think it’s not 100% perfect to fully apply an agile framework in that sort of environment, so I always would recommend to use agile practices where it’s beneficial, where it makes sense, but not push it in situations where you think, it might just harm even the way of working or the motivation of your team members and employees. (P11)

While the interviewees considered that regulation has a large impact, most of them stated that everybody was aware of it from the beginning of each project. Some interviewees thought that agile can work despite regulations, if the necessary changes to the agile approach are made, for example, adjusting the sprint cycle to account for the required time to create extensive documentation. Other interviewees mentioned that due to regulations, people were convinced that working agile was not possible. Such beliefs served as a reason for discarding the agile way of working. A senior agile expert explained:

But on the other side, like a side effect, was that some people seem not to have completely understood what the regulation really is about and then they kind of said, OK because of the regulation, we cannot do it in this agile way. Although that was not completely true as they merely didn’t see how it could work. (P10)

Solutions

Behavioral solutions

To improve the acceptance and spirit toward agile, various measures were implemented. The first measure was a common change management instrument. The organization was “performing an awareness session, providing a sufficient documentation, so really doing everything that people are the best enabled in order to perform the job” (P3). Other measures included “having continuous town halls with additional communication measures and providing the possibility of Q&A sessions and give free freedom to provide feedback and concerns” (P2). In one case, stakeholders within the organization wanted to claim responsibility for their processes and requirements, because “making people responsible is a very effective lever. […] Giving them a role that makes them the owner of certain tasks, so that whenever they are in in the situation that the progress of their own topic is asked, they are responsible or in charge for demonstrating that they have made some progress” (P9). The different stakeholders were assigned responsibility for certain product features, which changed their attitude toward the agile way of working. The additional responsibility led to higher involvement. Another team gamified the agile way of working: “Just get a designer and get some logos each team decided their name on their own and they have a nice logo, they can use it in the team’s background. […] That’s quite nice just to get some team spirit” (P8). The increased team spirit improved their attitude toward the agile way of working. The last measure to push agile was the celebration of success. One interviewee stated that “it was very, very important for me, that you celebrate the success, and you also critically reflect on those topics that that did not go right in the programme, in the teams and so on” (P11). Reflection on critical issues is a core tenet of the agile way of working. However, actively celebrating success was not explicitly planned, originally. With a high frequency of releases, one has more celebrations compared to a traditional project management approach. The celebration of success makes people realize agile’s positive aspects and creates a positive atmosphere. However, in a few cases, individual’s change resistance proved to be so hard that it was considered a risk for project success. These individuals were replaced by different personnel in the agile project.

Technological solutions

The technological challenges were addressed by gaining management attention. By highlighting the issues, the management became aware of their urgency and provided a budget to acquire infrastructure and training. To solve the issue of continuous integration and continuous delivery (CICD), automated testing was introduced, which consumed time, but proved valuable for preventing and fixing bugs. CICD ultimately resolved the integration issues by running the tests automatically whenever a new piece of software was published. To fix the overruling of managers, the teams developed dashboards that displayed the progress of the project: “In the context of dashboarding, to give them the feeling that they have more control of things like in the classical way that they see what is happening” (P10). The dashboards allowed the managers to see the actual progress and build trust into the team through transparency.

Organizational solutions

The primary measure to overcome the challenges was investment in training and coaching through the acquisition of knowledge from agile experts. One interviewee stated: “I think the most important aspect is to have very good and well-trained agile coaches and scrum masters to really make the employees realize that they work more efficiently when they’re in an agile setup” (P9). In many cases, this knowledge was brought in from outside the organization. This measure aimed to have experts lead the agile way of working while simultaneously training new staff to take over the role in the future. The interviewees pointed out that it would be unsustainable to permanently fill the scrum master or product owner’s role with an external source. This measure ensures that the agile principles are applied correctly and the benefits and concepts are fully understood.

To mitigate management overrule, the teams implemented a decision-making dashboard that allowed managers to follow the team’s decision-making process. This approach was described as “[…] a hybrid agile classical way” (P10) and gave the managers the opportunity to be part of the decision-making process, with the teams still having authority for making the primary decision.

The workload estimation and requirement collection were improved using two measures. To collect the requirements, the team introduced different maturity levels. In their opinion, teams naturally want to “[…] give out the 110% solution […] but the 90% is sufficient in our opinion and saves a lot of time, a lot of money […]” (P8). Thus, the requirements only contain the ones that were necessary, and the others are mapped to a different maturity level. To tackle the issue of missing targets per program increment (PI planning), the team realized that they calculated the availability of the entire team incorrectly. They did not properly account for vacations or the hours that everyone was allocated to the project. Once their error was corrected, they also saw that people tend to overestimate their output, which is why they added a work-in-progress limit (WIPL), which stated that each team could only have a maximum number of story points per program increment or backlog task, ultimately eliminating the ability to overestimate their output. Based on these changes, they could increase their progress from 25–30% of the planned progress to 95%. In a different project where the team also struggled with workload estimation, they relied heavily on the measure of effort, as the measure of complexity was difficult for the teams to grasp.

The challenge created by meeting frequency and structure in agile was mitigated by communicating the purpose and benefits of agile to the teams. As a result, people had a understood why the meetings were useful. While this was sufficient in most cases, in one case, the teams reduced the number of meetings and instead created a new form of meeting. In this new meeting, the release train engineer (SAFe framework role) offered a voluntary slot for all scrum masters to attend and communicate their needs and issues. The meeting was scheduled for 3 hours, and each team had a dedicated 15-minute timeslot. The product owner sits with the team representative and “they share what they have to share, express some needs, maybe they need support with unblocking a situation or they complain about something and then they leave” (P5). Although the beginning was slow, most of the teams took the opportunity and joined their time slots in the end. This created a new form of collaboration as other teams joined, providing another dedicated time slot to quickly resolve questions between the respective teams. Ultimately, this new meeting was described as: “we increase the communication. We increase the acceptance of this new way of working by simplifying and reducing the number of meetings and simplifying the communication” (P5).

Regulatory solutions

Addressing the regulatory challenges was difficult and the only mentioned approach was to account for these regulations early in the planning phase. The agile teams added a buffer and slack time to perform the necessary documentation or other tasks:

Therefore, it is necessary to integrate that [the regulatory requirements] in. For example, the definition of ready. Did you integrate specific legal requirements? Did you look at the regulations and so on and so on? I have to include them early also you have to include them in the definition of done that you have clearly looked at those aspects that need to be reflected, and I saw that in the public sector where you have a lot of regulations, and those regulations need to be brought into the backlog very early. So it’s not helpful to look at it only for the next, let’s say sprints or program increments as you would normally plan out your agile cycles, but it’s really relevant to have a look at it very early and so you need to have a function which can help you with those requirements. (P11)

The statement suggests that when it comes to regulation, it is necessary to plan and consider any legal or regulatory implications early on, because it is not enough to only think about regulations during a sprint or program increment. Another approach is to modify the agile way of working. “I think you can take certain practises from agile but I think it’s not 100% perfect to fully apply an agile framework in that sort of environment” (P11). A customized approach to agile methodology that considers regulatory requirements can be a solution for projects that face such constraints. The interviewee highlights that, in certain scenarios, opting for a non-agile approach may instead be the best decision to avoid the challenges of regulation.

Discussion

This research uncovered challenges in four different areas (behavioral, technological, organizational, and regulatory) for the implementation of large-scale agile in safety-critical industries. This section relates the recognized challenges and solutions to existing research on agile projects, assessing the generalizability of the findings. Afterwards, it evaluates whether the solutions taken to mitigate the challenges remain consistent with agile principles.

Behavioral challenges and solutions

The most frequent challenge in our empirical results is change resistance, which occurred in seven out of twelve interviews. Change resistance has previously been reported with similar frequency by Kalenda et al. (2018). Although the reasons vary among studies, a lack of purpose for transitioning toward agile has been commonly cited (Dikert et al., 2016; Ebert & Paasivaara, 2017). This lack of purpose leads to missing buy-in from affected employees. Especially senior employees with long tenure in the organization remain resistant to change if a convincing purpose is missing (Bourne, 2015).

Another reason for change resistance was the concept of minimum viable products (MVPs). Employees in safety-critical industries without experience in agile principles perceived MVPs as unfinished and rudimentary. Instead, they preferred polished systems. This finding contradicts Bass and Haxby (2019), who found that the concept of MVPs can reduce change resistance. MVPs are an agile practice to gain user feedback on a product through iteration. If people do not understand how continuous delivery processes work, they might have incorrect expectations regarding a system’s capabilities and maturity. Such an observation was reported by Dennehy et al. (2019), where the purpose of MVPs was misunderstood, and employees deemed the quality of software more important than the continuous learning achieved through iterating MVPs. Different cultures in safety-critical industries compared to software development explain these differences. It is important to coach employees extensively to the purpose of MVPs. Investigating the role of MVPs and firm culture in the agile adoption process can trigger future research that investigates under which circumstances adding responsibility may increase or decrease the adoption intentions of agile.

Kalenda et al. (2018) found that new responsibilities for employees were a factor that increased change resistance. On the contrary, our results showed that people were eager to take on more responsibility, motivating them to adopt agile practices. Our results are in line with established theories on employee motivation (Kanfer & Chen, 2016). However, the introduction of agile and adding responsibility must be accompanied by a clear purpose, and employees must be trained on their new responsibilities and tasks. Otherwise, task ambiguity and uncertainty reduce employee motivation (Roberts & Glick, 1981).

Our results show three different measures to overcome change resistance. The first is a common change management measure, i.e., to improve communication and employee participation (Dikert et al., 2016; Kalenda et al., 2018). Second, the interviews suggested the gamification of agile can aid its adoption, which recently was reported in the literature (Marques et al., 2020, 2023). Our findings corroborate Marques et al. and show that gamification increases agile adoption. Third, the active celebration of successes during retrospective meetings was a success factor, according to our interviewees. This confirms previous propositions stating that celebration of success can enhance team performance (Parker et al., 2015; Ranganath, 2011; Tsoy & Staples, 2021).

Technological challenges and solutions

Technological infrastructure plays a vital role in working agile (Morris & McManus, 2002; Sekitoleko et al., 2014). It affects development and non-development functions because digital transformations affect the entire organization. Our results showed that a lack of infrastructure reduces team performance (Sekitoleko et al., 2014). This validates that working agile on large-scale projects produces additional complexities for coordination, which cause integration problems (Dingsøyr & Lindsjørn, 2013). In large-scale agile, a dozen teams continuously deploy features that need to be integrated, which creates complexity. Thus, high-quality code, coordination, and alignment are required to ensure a seamless integration. While our research was influenced by the fact that most people were new to the CICD methodology, implementing CICD remains challenging even for experienced professionals in large-scale projects due to their size and complexity. CICD tool support is essential, and more experienced teams have an advantage over less experienced teams in making large-scale agile a success (Abrar et al., 2019), especially in safety-critical industries.

The technological challenges were addressed using two primary measures. First, to acquire management attention, the lack of CICD infrastructure was clearly outlined and presented, which resulted in an investment in new infrastructure. Second, issues related to the integration of new software were tackled by test automation. Both measures are well-known and covered in the literature. In particular, the use of agile, combined with continuous integration and deployment, is popular as it increases project efficiency. Arachchi and Perera (2018) developed a framework that enables agile based CICD projects by leveraging test automation.

Organizational challenges and solutions

The majority of challenges were related to organizational issues. One reported issue was the lack of management commitment caused by insufficient knowledge and familiarity with agile. One symptom of the challenge manifests itself as managers overruling their teams – as identified by Paasivaara and Lassenius (2016b). The lack of knowledge about agile concepts was the root cause for the challenges identified. For example, the inexperienced teams in our case study took issue with workload estimation, task prioritization, and progress measuring. Management underestimated the required effort for transitioning from traditional to agile project management, and the added challenges related to the integration of non-development functions (Kalenda et al., 2018). Since the reported challenges are symptoms caused by lack of knowledge, acquiring knowledge about agile and transferring it to the focal organization should be considered a high priority. The integration of non-development functions has already been problematized by Dikert et al. (2016) and is more severe in the safety-critical industries as our results indicate.

The lack of management commitment, especially the issue of missing trust and micromanagement, was tackled by developing decision-making dashboards. Dashboards and metrics are typical components of both agile and traditional project management techniques (Schwalbe, 2018). As the organizational challenges were caused by a lack of knowledge or experience with agile, the primary remedy was to acquire this knowledge by adding experts in crucial roles, such as scrum master or product owner, or by investing in coaching to train the personnel (Kalenda et al., 2018).

Our results showed that the general meeting structure proposed by the agile approach was infeasible for the organization because it consumed too much time in light of the regulatory requirements. Therefore, the case organizations decided to reduce the number of meetings and introduce alternative meeting structures. Informal communication is critical for agile and self-managed teams. Further research should investigate how to manage this informal communication while maintaining agile principles in a safety-critical context.

Finally, our results showed the creation of cross functional teams that are called “Biz Dev Ops Teams” which are compiled of development and non-development functions, as a critical success factor. Cross functional teams enable effective communication and ensure system validity at different levels. When considering the lack of experience and the challenge of integrating non-development functions, this approach could be helpful in tackling integration challenges, because developer functions are used to work agile and could therefore serve as mentors and coaches. This mentorship can reduce the investment required for external knowledge. This claim is also supported by existing research, as cross-functional teams enhance knowledge sharing in general contexts (Lundene & Mohagheghi, 2018).

Regulatory challenges and solutions

Finally, there are challenges created by the regulations from within and outside the organization. These regulations require additional documentation and mandate increased confidentiality, complicating tool adjustments and selection. Our findings corroborate findings from the agile obstacles in government institutions (Nuottila et al., 2022). Auditing and traceability are impeding agile project management (Fitzgerald et al., 2013). Agile is not suitable in the case of strict audit and traceability requirements. Our results show that traditional project management caters for these requirements because the main solution was to anticipate regulatory challenges upfront by long-term planning instead of iterative cycles. Only selected parts of agile were cherrypicked that work in spite of the requirements. This approach was described during the interviews as a “hybrid agile classical” solution. This finding partially corroborates research that favors hybrid approaches over pure agile or waterfall project management (Conforto et al., 2014; Gemino et al., 2021). For safety-critical industries, our results suggest that either exclusively traditional or hybrid approaches are feasible but not a 100% agile approach (Dingsøyr, Moe, Fægri, et al., 2018).

On top of that, our findings show that employees cite regulations as a reason to avoid the agile way of working and actively stop the adoption of agile. This issue presents a major obstacle for safety-critical industries such as aerospace. Companies must recruit additional trained personnel and produce extensive documentation for their systems. Some solutions to large-scale agile issues are incommensurable with the regulations. For example, the literature considers adding knowledge through internal or external sources and using tools and infrastructure to be success factors in implementing large-scale agile (Moe et al., 2019; Schnitter & Mackert, 2011; Vallon et al., 2013). The strict regulatory requirements in safety-critical industries obstruct the implementation of these success factors. For example, sophisticated efforts to acquire personnel clearance are needed; or documentation must be persistent and traceable and cannot be transient (Nakayama et al., 2024).

Ultimately, despite being seasoned experts in agile and the safety-critical domain, the interviewees could not offer compelling solutions to the challenges imposed by regulation. The advice was to include legal and regulatory considerations early and account for them in the planning phase – contradicting agile’s principles. Again, this emphasizes that 100% agile is infeasible in safety-critical industries, and traditional project management or hybrid approaches are needed. These approaches warrant further research to disentangle the interdependencies between legal requirements and the implementation of hybrid agile.

Alignment with the agile principles

The classic change management measures adopted in the case study, prioritizing communication, and employee participation, align with agile’s core value of empowering individuals and informal interactions, underscoring the critical role of human elements in successful project execution (Fowler & Highsmith, 2001). The use of experts in central roles, such as scrum master or product owner and the investment in coaching to train personnel further enhances team interactions, which are the key aspects of agile methodologies. However, relying too heavily on these experts could potentially undermine the principle of a self-organizing team and its continuous learning journey. The introduction of gamification can support agile’s commitment to creating a supportive and engaging work environment, fostering team spirit and promoting creativity (Marques et al., 2020; Schöbel et al., 2020). Previous research claimed that the strategy of adding responsibilities embodies agile’s endorsement of self-organizing and motivated teams, but did not lead to superior results and supposedly increased resistance to agile adoption instead (Kalenda et al., 2018). Our findings contradict these claims, because employees were eager to receive added responsibility and cherished agile as a result. Finally, the active celebration of successes correlates with agile’s principle of continuous improvement and serves as a form of positive reinforcement that fosters a culture of striving for excellence and ongoing learning. Combining development and non-development functions is in line with agile manifesto’s emphasis on self-organizing teams. It encourages cross-functional collaboration, a key agile principle, and encourages effective communication between business and IT people. The mentoring aspect, in which experienced developers mentor others, is in line with the principle of providing motivated individuals with the environment and support they need. Securing management investment in CICD infrastructure enables agile’s principle of continuous delivery and improvement. The team identified a gap, reflected on its effects, and took action to improve its effectiveness by changing the IT/IS infrastructure. The case study employed test automation to resolve software integration issues, attending to the technical excellence principle by ensuring higher code quality. Facing regulatory constraints, acquiring external expertise is costly because of the required clearances in safety-critical industries. To deal with regulation, it was suggested to plan the regulatory requirements upfront and long-term. Extensive documentation to demonstrate traceability and keeping the number of audits low to save excessive auditing costs clearly contradict agile principles. In summary, this section demonstrates that the solutions to behavioral, organizational, and technological that arise from large-scale agile project management comply with the agile principles. However, the solutions to the regulatory challenges, necessary to accommodate the safety-critical industry, contradict agile principles and encourage a traditional or hybrid project management approach instead.

Implications for research and practice

Theoretical contribution

This study presents important theoretical implications for implementing agile. First, we show that large-scale agile can work, although more people are involved, and structures and responsibilities must change. We identify four challenges for implementing large-scale agile (i.e., behavioral, technological, organizational, and regulatory) that must be overcome for successful large-scale agile project management. To this end, we offer solutions to the challenges associated with large-scale agile that focus on change management, appropriate tool support (in particular, CICD), and cross-functional teams. Our findings show that the regulatory challenges are most difficult to overcome, and regulatory requirements such as traceability and audits present major barriers to adopting large-scale agile in safety-critical industries. The proposed solutions to overcome the regulatory challenges, specifically upfront planning, violate agile’s principles and basically constitute a fallback to traditional, waterfall-style project management. As a result, pure agile does not work in safety-critical industries characterized by high regulations, and regulations remain a reason to avoid the agile way of working (Heeager & Nielsen, 2018). Despite this, we show that selected ideas from agile can work in safety-critical industries if combined with upfront planning. These hybrid modes of project management include components from traditional and agile project management. Future research is needed into how safety-critical industrial companies can effectively balance the need for flexibility with the need for traditional upfront planning to meet regulatory requirements. Additional research can investigate how organizations can determine which components of agile project management are viable in their environment, depending on their project requirements. Furthermore, novel process research can elucidate how companies can implement the cherry-picking of agile ideas.

Managerial implications

This research shows that companies are open to work agile but are currently hindered by regulations to utilize it fully. Managers should consider that change resistance is prevalent on both small and large scales. It is crucial for practitioners to be aware that they must allocate an adequate budget for change management. Having the required IT/IS infrastructure is crucial; managers should not only focus on developer personnel but also understand the value of a proper CICD pipeline. CICD requires skilled and capable developers and may entail additional resource expenditures. Regulation creates challenges when working in an agile manner, as it requires additional resources and investments. Managers must be aware of the regulations and legislation in place for their industry, as this impedes or even blocks the adoption of agile, ultimately harming project outcomes. Finally, the lack of understanding of agile principles is the most common source of error in agile implementation. Hence, it is important to acquire knowledge and personnel training in order to increase the chances of project success. In particular, we highlight the role of the minimum viable product, which is a central element to implementing agile yet often misunderstood. Executive support is critical to facilitate the necessary success factors for large-scale agile.

Considering the statement made by the former Airbus CEO Tom Enders and the dynamic market environment, having a more flexible way of working that ideally has accelerated lead times is a high priority for leading safety-critical companies such as Airbus (Bloching et al., 2015). As a result, agile is highly sought after. Although pure agile is not recommended in large-scale safety-critical projects, hybrid approaches or cherry-picking agile principles for non-safety-critical areas can add substantial value. Therefore, managers keen on implementing agile should actively weigh the benefits and challenges and design a customized hybrid approach.

Limitations

Naturally, our study has limitations. Because of our focus on rich, detailed insights from a few senior employees, our findings revolve around large-scale agile in the aerospace industry. Although the issues related to safety-critical regulations are generalizable to other industries that share similar traceability and auditing requirements, transferring the insights to less scrutinized domains must be cautious. Most of the projects within the two case companies employed the SAFe framework as an approach for scaling agile. Nevertheless, we believe that the depicted challenges can be generalized to other agile scaling frameworks because the results indicated that the root cause concerns a lack of knowledge and understanding, which goes beyond a specific agile framework. This study should be viewed as a starting point for further research. Future research could explore large-scale agile in other safety-critical industries and design novel mitigation approaches to the extensive regulatory requirements. Given our inductive approach to developing theory from interviews, future research can also quantitatively validate our findings.

Conclusion

In conclusion, this study advances the literature on large-scale agile project management in safety-critical industries by uncovering new challenges and solutions in an aerospace company. It contributes an in-depth understanding of the challenges involved in large-scale agile transformation projects in safety-critical industries, including recommendations that guide practitioners. Large-scale agile suffers from additional challenges that are dealt with using a variety of measures, from change management, technical aids such as dashboarding, or organizational solutions such as acquiring external knowledge. Additionally, this study presented new approaches to mitigating the challenges, such as agile-waterfall hybrid project management, cherrypicking agile principles, or introducing gamification. After assessing the measures used to address large-scale agile challenges, it was discovered that the behavioral, technological, and organizational measures align with the agile principles, while the regulatory solutions do not. Regulation can significantly impact working in an agile way, and as of now, practitioners do not have suitable solutions to overcome these challenges. Therefore, practitioners should consider their needs and cherry-pick those agile principles that add the most value without compromising their regulatory requirements. One safety-critical industry that can benefit from such hybrid agile is the aerospace industry, which faces an urgent need for more efficiency owing to the dynamic market environment. The current landscape of research only provides cursory results on large-scale agile in safety-critical industries. This creates a need for additional research to examine novel approaches to hybrid agile approaches of the future that are effective and comply with regulatory challenges. Future research should investigate the equilibrium between managing obstacles and upholding agile principles.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Notes on contributors

Joschka A. Hüllmann

Joschka A. Hüllmann is assistant professor of Information Systems at the University of Twente in the Netherlands. His research addresses the interface between the development and organizational use of management information systems and their impact on work and the workplace. He is a recognized expert in the analysis and theorizing of digital traces. The results of his research have been published in IEEE Transactions, Information Technology & People, Deutscher Wirtschaftsdienst, and in the proceedings of all leading information systems conferences. Before his academic career, Joschka Hüllmann worked as a software developer in the fields of renewable energies and public transport.

Kariko Kimathi

Kariko Kimathi is a master’s student in Business Information Technology at the University of Twente, with a specialization in Data Science & Business. Through work experience at a leading telecommunications company and a top management consultancy he has developed an understanding of agile practices in large enterprises, a topic that is central to his current research. His interest in data science is complemented by a passion for entrepreneurship. He aims to apply analytical rigor to innovative business strategies.

Pauline Weritz

Pauline Weritz is an assistant professor for Organizational Behavior, Change Management, and Consultancy in the Industrial Engineering and Business Information Systems Section at the University of Twente in the Netherlands. She completed her Ph.D. (cum laude) at Ramon Llull University in Spain and has been a visiting researcher at Boston College. With her background in Psychology and Management, Pauline’s research focuses on the interface of Organizational Behavior and Information Systems. Her work has been published in journals such as the European Journal of Information Systems, Information Systems Journal, and Business Strategy and the Environment.

Appendix

A Interview Guide

This research project aims to create knowledge on the identified challenges of agile at scale. More specifically, it uses interviews with practitioners who work on large-scale agile transformations to determine if the identified challenges appear in their projects and what is done to address them. Therefore, participants will be asked questions about their role, their experience with the challenges of agile, and their mitigation methods. The interviews will be audio recorded and used for analysis afterward. The data will be anonymized afterward. Finally, there will be an analysis that aims to create generalizable knowledge about large-scale agile. Mainly it aims at providing insight into the main question:

What are the challenges of large-scale agile project management for regulated industries, and how can they be overcome?

The interviews and generated insights will be used to create a written scientific report. It is intended to publish this report in the end. Before that, there will be rounds of reviews to ensure that the required confidentiality remains.

Are we allowed to record this? If yes, we will start recording now.

General part

1. What is the industry you are working in?

2. How long have you been in this industry?

3. What is the role you are working in?

4. How long have you been in this role?

5. What is the project you are working on?

a) Probe: Is it a digital transformation project?

b) Probe: Is it agile?

c) Probe: What industry?

d) Probe: Geographic location?

6. How is the project managed?

a) Probe: How is it planned?

b) Probe: How are the responsibilities distributed?

c) Probe: How do you plan the project?

d) Probe: How do you ensure that milestones are achieved?

e) Probe: Team size?

f) Probe: Team skills?

7. What is the size of the project?

a) Probe: Large scale, small, mid-sized?

8. What is your role in the project?

a) Probe: Internal? Client-facing?

9. How long have you been working on the project already?

10. How many projects of this kind have you already worked on?

11. Did you experience any challenges while working agile on large scale?

a) Probe: Difficulty of implementation?

b) Probe: Integrating non-development functions, e.g., procurement?

c) Probe: Change resistance?

d) Probe: Requirements engineering challenges?

e) Probe: Hierarchical management and organizational boundaries?

If challenges are mentioned

1. How did the particular challenge present itself?

2. How did you deal with it?

a) Probe: Mitigated? Accepted? Transformed?

b) Probe: Does it still align with the agile values?

c) Probe: More documentation?

d) Probe: More planning?

3. How well did the solution work?

a) Probe: Increase or decrease of something? Measurable?

4. Do you think they are more likely in specific industries?

a) Probe: More regulated? Less regulated?

5. Would you say that the mitigation methods still align with the core principles and values of agile?

If no challenges are mentioned or recognized

1. Why do you think these challenges do not occur in your case?

a) Probe: Frameworks? Mechanisms? Project management?

2. Do you think it might be industry specific?

Other aspects of agile and closing

1. Is there any other aspect of agile that you would like to mention?