The interrelationship between the agile approach and project complexity in product development

Managing complexity is a major issue in product development (Shamsuzzoha et al., 2020). Complexity influences how product development projects are conceived and managed, and should therefore be considered in project management research and practice (Cilliers, 2000; Cooke-Davies et al., 2007). Project complexity is multi-dimensional and escalating in product development across industries. This trend is partly driven by the growing interconnectedness of systems and technologies (Bianchi et al., 2022), resulting in interdependencies between products’ mechanical, software, and electrical subsystems (Isaksson and Eckert, 2020). These interdependencies require extensive and costly coordination among development activities (Berntzen et al., 2023).

Firms are searching for strategies with which to manage project complexity, and studies have suggested that the agile approach helps to manage it (Denning, 2015; Cocchi et al., 2024; Leybourne, 2009). The agile approach is grounded in the values and principles established in the Manifesto for Agile Software Development (Beck et al., 2001) and has gained wider traction beyond software development. Its application into new contexts exposes it to distinct organizational and contextual contingencies, making context-specific applications necessary (Bianchi et al., 2022). Product development studies have demonstrated that organizations adapt the agile approach to align with their specific conditions (Atzberger et al., 2020; Dikert et al., 2016; Conforto and Amaral, 2010; Cooper and Fürst, 2023). The agile approach can therefore be understood as a way of working that comprises shared practices grounded in agile values and principles, which are adapted to organizational and contextual contingencies and shape how work is organized and how individuals and teams interact, communicate, and make decisions.

However, despite the fact that the agile approach helps to manage project complexity in product development, most prior studies have taken a relatively narrow view of what complexity refers to, typically focusing on certain dimensions of complexity such as technological complexity (cf. Odusanya et al., 2021; Little, 2005; Rajagopalan et al., 2016; Butler et al., 2020; Muhammad et al., 2021). These studies tend to overlook other dimensions of project complexity related to organizational context and structures, leadership styles, and roles (Sońta-Drączkowska and Krogulec, 2024; De Oliveira Santos et al., 2024), and have not properly addressed the multidimensionality of project complexity in product development. What complexity means is often vaguely defined and used as an umbrella term for uncertainty-laden, complicated, and dynamic situations (Geraldi et al., 2011; Sohi et al., 2016). Given such vague use of the project complexity construct, knowledge about how and to what extent the agile approach is relevant to managing complexity is difficult to accumulate. It is therefore argued that a multi-dimensional view of project complexity is required to properly analyze its interrelationship with the agile approach.

Following this argument, product development project complexity is defined as a multi-dimensional property of projects that is faced by individuals and organizations carrying out product development efforts and makes projects difficult to understand, foresee, and control (Kim and Wilemon, 2003; Vidal et al., 2011). Building on this definition, this article formulates the following research question: How does the agile approach interrelate with project complexity in product development?

By studying two product development projects, this article examines the interrelationship between the agile approach and project complexity. It highlights the importance of a multi-dimensional examination of project complexity to develop a nuanced understanding of the interrelationship between these two constructs within product development.

The agile approach is founded on the agile values and principles articulated in the Manifesto for Agile Software Development (Beck et al., 2001). These values and principles emphasize motivated and self-organized development teams that embrace changing requirements through adaptive planning, iterative and incremental development, and continuous value delivery to customers (Beck et al., 2001). Building on these values and principles, various agile frameworks have emerged. Although initially designed for single teams, several frameworks have since been developed to support coordination across multiple development teams, including Scaled Agile Framework (SAFe, Scaled Agile, 2022), Scrum@Scale (Sutherland and Scrum Inc, 2022), and Disciplined Agile (Project Management Institute, 2025).

These frameworks comprise a set of agile practices, some of which are shared across frameworks (Moran, 2015). These practices define how development efforts are carried out with the aim of realizing the values and principles established in the Manifesto (Bianchi et al., 2022). Although they have different names across frameworks, examples of agile practices include small, cross-functional teams; roles such as team coach (or team lead), product owner, and system architect; events such as program increment (PI) planning, sprint planning and the daily scrum (also called daily stand-up); and tools such as backlogs, task boards (also called visual or Kanban boards), work packages, and roadmaps (Scaled Agile, 2022; Agile Alliance, 2025; Project Management Institute, 2025).

Although agile frameworks define a set of practices, studies show that organizations often apply a modified agile approach that suits their needs and conditions. Dikert et al. (2016) found that strict adherence to agile frameworks is often unfeasible. Evolutionary and pragmatic customization—combining practices from various frameworks and considering various types of projects, products, processes, and organizational cultures—is regarded as a key factor in applying the agile approach (Dikert et al., 2016; Conforto and Amaral, 2010; Atzberger et al., 2020).

Nevertheless, Sońta-Drączkowska and Krogulec (2024) noted that in some organizations, the application of the agile approach reflects an uncritical imitation of industry peers, rather than a deliberate and mindful application. Similarly, Dikert et al. (2016) and Cooper and Fürst (2023) found that organizations struggle with the poor customization of the agile approach due to limited guidance in the literature and difficulties balancing prescribed practices with excessive flexibility. Such poor customization can lead to the application of the agile approach in unsuitable contexts, undermine agile values and principles, hinder meaningful change, and prevent the realization of the intended benefits (Sońta-Drączkowska and Krogulec, 2024; Dikert et al., 2016; Cooper and Fürst, 2023).

Complexity has implications for the way projects are conceived and managed (Cilliers, 2000; Cooke-Davies et al., 2007). Cooke-Davies et al. (2007) define complexity theory as “the study of how order, structure, pattern, and novelty arise from extremely complicated, apparently chaotic systems and conversely, how complex behavior and structure emerges from simple underlying rules” (p. 52). Complexity can also be seen as arising from continuous dynamic interactions among multiple system elements (Cilliers, 2000; Anderson, 1999; Meso and Jain, 2006; Stacey, 2001). Due its implications for projects, authors such as Cooke-Davies et al. (2007) have called for the incorporation of complexity into project management practice and research.

Project complexity has been explored in the project management literature, serving a diversity of research perspectives (Mikkelsen, 2020, 2021; Bakhshi et al., 2016). The concept of project complexity itself is intricate, with practical and philosophical undertones, which has created a plethora of definitions and a lack of consensus regarding the concept (Vidal et al., 2011; Mikkelsen, 2020; Kiridena and Sense, 2016; Bakhshi et al., 2016). It is often used as an umbrella term for dynamic, uncertainty-related, and ambiguous situations (Brandl et al., 2021). Various authors have proposed frameworks to describe project complexity. Although no widely recognized framework for it exists, a common characteristic among them is project complexity’s multi-dimension nature, which is also referred to as the sources, types, or drivers of complexity, among other terms (Mikkelsen, 2021; Bosch-Rekveldt et al., 2011; Kim and Wilemon, 2009; Schuh et al., 2016).

One of the earliest scholars to distinguish between the various dimensions of project complexity was Baccarini (1996). The author acknowledged a broad range of dimensions of project complexity; however, the author primarily focuses on organizational and technological dimensions due to their prominence in project management research. Moreover, Baccarini (1996) pointed out that these dimensions can appear in two domains: differentiation and interdependency. Differentiation refers to the number of distinct elements within a project, while interdependency captures the degree of interaction between these elements. Building on the organizational and technological dimensions of project complexity, Vidal et al. (2011) conducted a synthesized literature review and identified project size, project interdependence, project variety, and elements of context as criteria with which to measure the organizational and technological dimensions of project complexity.

Drawing on both a literature review and empirical data, Bosch-Rekveldt et al. (2011) developed a framework for characterizing project complexity in large engineering projects. The authors identified and added the environmental dimension of project complexity, introducing the technical, organizational, and environmental (TOE) framework. The technical dimension included project goals, scope, tasks, experience, and risk. The organizational dimension comprised project size, available resources, team dynamics, and trust. The environmental dimension encompassed stakeholder interactions, project location, market conditions, and external risks.

Based on insights derived from complexity theory, Kiridena and Sense (2016) integrated the TOE dimensions of project complexity into a hierarchically organized framework. The framework proposed by those authors showed that these dimensions contributed to project complexity in three categories: projects as complicated systems, which are characterized by the presence of multiple dimensions of project complexity, leading to ambiguity, uncertainty, and unpredictability; projects as complex systems, in which nonlinear interactions between the dimensions of project complexity generate emergent behaviors; and projects as complex adaptive systems, in which these dimensions dynamically evolve in response to environmental changes, enabling self-organization and evolution.

Specifically tailoring their work to product development, authors such as Kim and Wilemon (2003) and Schuh et al. (2016) have proposed frameworks that outline the key dimensions of project complexity. One of the more comprehensive frameworks is proposed by Kim and Wilemon (2003) and encompasses the technological, environmental, marketing, development, organizational, and interorganizational dimensions of project complexity. As indicated by Table 1 these dimensions are confirmed by other studies in literature. These dimensions therefore serve as the analytical lens for the present study.

Scholars have emphasized the need to shift from merely describing the dimensions of project complexity to actively developing managerial responses to them (Baccarini, 1996; Mikkelsen, 2021; Kim and Wilemon, 2009; Odusanya et al., 2021). Kim and Wilemon (2009) conducted an empirical study that explored how practitioners in eight technology-based companies managed project complexity. Notably, that study emphasized the fact that effective management depends on the application of appropriate techniques and tools, enhancements in product development processes, and strengthened teamwork through consistent and effective communication. Kiridena and Sense (2016) highlighted the persistent ambiguity regarding the relationship between the dimensions of project complexity and project management practice. In other words, the authors noted that there is limited clarity regarding the practical implications of project complexity for day-to-day project management, such as how project managers should account for complexity when planning, organizing, and leading projects. The authors advocated for further research on a contingency approach, in which practices, methodologies, leadership styles, and management strategies are adapted to align with project complexity (Kiridena and Sense, 2016; Kim and Wilemon, 2009).

Studies have explored the interrelationship between the agile approach and project complexity in product development. Among these, a few have pointed out the positive effects of the agile approach in terms of managing project complexity. Authors such as Rajagopalan et al. (2016), Butler et al. (2020), and Muhammad et al. (2021) investigated the moderating effect of the agile approach in the relationship between project complexity and project performance or goal achievement. Their studies suggest that agile frameworks and practices mitigate the anticipated negative influence of project complexity on project performance. For example, Rajagopalan et al. (2016) found a significantly positive moderating effect of the agile approach on the relationship between project complexity and goal achievement.

Further insights are derived from studies that classified project by complexity and suggested agile practices accordingly. Little (2005), in a study of a software development company, categorized projects by complexity and uncertainty and suggested core agile practices, which were supplemented with additional practices according to the classification made (e.g. daily stand-up meetings for low-complexity/high-uncertainty projects). Similarly, Pinciroli (2024) provided guidelines for minimizing the impact of project complexity in software development projects. The authors identified key factors for project complexity, which, in conjunction with the Snowden’s Cynefin framework (clear, complicated, complex, and chaotic contexts, Snowden and Boone, 2007), categorized agile practices in relation to project complexity. In their study, the authors also pointed out overlaps in the categorization of key factors affecting project complexity.

Other studies have examined specific dimensions of project complexity. For example, research focusing on the organizational dimension raised concerns about applying the agile approach on a large scale, beyond the team level, in more complex contexts (Sońta-Drączkowska and Krogulec, 2024; Dingsøyr et al., 2018; Ciric Lalic et al., 2022). The agile approach, as first described in the Manifesto for Agile Software Development, aligns with the Mintzberg (1980) coordination mechanism of mutual adjustment. This mechanism is built on informal reciprocal communication between individuals. As complexity increases with the size of both technological systems and its designing organizational entities, mutual adjustment becomes unfeasible as a coordination mechanism (Sońta-Drączkowska and Krogulec, 2024). Nevertheless, the coordination needs remain and, in theory, increase exponentially with the number of coordinating stakeholders and agents (Dingsøyr et al., 2018).

Moreover, Sońta-Drączkowska and Krogulec (2024) identified tensions that emerge when applying the agile approach in large organizations, including challenges regarding maintaining a certain degree of control and governance, which stands in contrast to the agile approach’s decentralized and participatory governance principles, and cultural shifts and mindsets, resulting in resistance and insecurity among managers due to the re-evaluation of their roles and a lack of understanding of agile principles. Similarly, Denning (2015) argued that the agile approach often conflicts with the prevailing ideology of top-down control in hierarchical bureaucracies. That results in power struggles between managers and employees in which individuals are denied the opportunity to make decisions and use their expertise, undermining agile principles. De Oliveira Santos et al. (2024) showed that organizational readiness, encompassing organizational culture, structure, transition frameworks, and strategic management, has a significant mediating role in the realization of agile benefits for business, teams, products, and processes. Nevertheless, the authors pointed out that the mediating role of organizational readiness may be limited by other contextual and project-specific factors.

A survey conducted by Bechtel et al. (2022) highlighted the influence of organizational contingencies, particularly non-agile portfolios, on the application of the agile approach. The study showed that project portfolio management constrains the benefits of the agile approach regarding teamwork quality. According to the authors, portfolio management practices may restrict teams’ freedom, creativity, or use of agile practices and complicate the prioritization between customer satisfaction and organizational strategy.

Studies have also explored the interrelationships between the agile approach and other dimensions of project complexity. Focused on the technological, development, and organizational dimensions, Odusanya et al. (2021) showed that the adoption of new technologies; changes in user needs, scope, or priorities during the project; and poor stakeholder relationships negatively affect project performance. The authors argued that under such conditions, the agile approach can improve project performance. Similarly, Ciric Lalic et al. (2022) found that combining the agile approach with traditional project management approaches has a positive impact on project success (team satisfaction and future preparedness), particularly when projects have broad scope, numerous tasks, and high interdependence. Related to the marketing dimension, the authors found that the agile approach positively influences project success when the product is new to the market, as such novelty limits planning by reducing the accuracy of market data and the time available to finalize product requirements. Moreover, Sońta-Drączkowska and Krogulec (2024) found that dependencies on external parties not aligned with the agile approach tend to prolong decision-making processes and increase the effort required to apply the agile approach.

In sum, the literature suggests that to manage project complexity, the agile approach requires adaptation, for instance by combining practices from various models or frameworks (Bianchi et al., 2021). Pinciroli (2024) argued that, although that point is overlooked, the agile approach requires adaptation to address the contextual reality in which it is applied. The literature review conducted by Cocchi et al. (2024) indicated that hybrid models integrating Stage-Gate with the agile approach are particularly well-suited to managing high-complexity projects, emphasizing project complexity as a key decision variable in determining the suitability of applying the agile approach.

This study uses a case study approach in which cases were selected using a theoretical and purposive sampling technique (Eisenhardt, 1989; Saunders et al., 2007), ensuring that each case illustrated the interrelationship between the agile approach and project complexity in product development. The cases were selected because they involved the agile approach and project complexity in product development. More specifically, the selection criteria included the following:

1. Cases that apply the agile approach within product development projects involving multiple teams or sub-teams. Such product development projects are expected to increase project complexity by generating interdependencies that require mutual adjustment and cross-team coordination (Sońta-Drączkowska and Krogulec, 2024; Dingsøyr et al., 2018; De Oliveira Santos et al., 2024).

2. Cases that exhibit project complexity. This includes cases encountering project complexity in its varying dimensions due to, for example, integrated technological subsystems, the technologies applied, the competencies and expertise required, and the development cycle length (Salvato and Laplume, 2020).

3. Cases that offer complementary insights into the interrelationship between the agile approach and the dimensions of project complexity. To understand this interrelationship, it is essential to recognize that contemporary product development projects are often intended to develop complex products integrating both mechanical and software subsystems (Isaksson and Eckert, 2020). Empirical cases that illuminate these product development projects contribute to a nuanced understanding of the interrelationship under investigation.

Two cases were identified that offered complementary coverage of the various dimensions of project complexity (see Table 2).

• Case A

Case A involves the application of the agile approach in a product development project that is specifically focused on the development of physical (mechanical) products within Company Alpha, a leading large manufacturing company. Historically, the company has been a market leader and faced increasing competitive pressure, shortened time-to-market expectations, and other external demands. The product development project encompasses a product family that includes hundreds of individual products. These products primarily consist of mechanical components that can be configured in various ways to meet diverse customer application requirements. The product development process is typically supported by a range of internally developed technologies, many of which are completed before the start of product development projects. However, in some projects, technology development occurs concurrently with product development, creating interdependencies between the two processes.

The agile approach was used as a second layer within product development projects. Product development projects still follow the company’s traditional product development process model, which resembles a Stage-Gate model. Conformance with the latter ensures alignment with industry-specific quality standards, which is often required by customers. The product development process model includes a steering committee that meets regularly to prioritize projects, make decisions at key milestones, and allocate resources across projects. In addition, the agile approach is employed across three interrelated levels: individual projects, departmental units, and the broader project portfolio. It is anchored in three cornerstones: pulse meetings, visual boards, and team collaboration. The approach encompasses practices such as visual boards for team coordination and accountability, pulse meetings, and sprint-based and results-driven planning. These practices support the management of dependencies and development tasks across and within projects.

Each development project involves a cross-functional team of 20–50 employees drawn from specialized organizational units, which are subdivided into smaller sub-teams that collaborate closely. Moreover, employees may be reassigned across projects based on resource needs. The development timeline for each project ranges from two to five years.

Company Alpha forms part of a broader corporate group with operations spanning multiple countries. Product distribution is coordinated through customer sales centers and scheduled around periodic release dates. The company is a recognized leader in terms of delivering high-quality products to customers across several industries, including the oil and gas, automotive, aerospace, medical, and energy.

• Case B

Case B involves the application of the agile approach in a product development project focused on the development of a software system. It involves two suppliers in the vehicle manufacturing industry. In the project, two organizations co-develop a middleware system, which includes integrating component systems into a platform, which, in turn, is integrated with an operative system developed by a global actor and a user interface developed by the automotive original equipment manufacturer (OEM). The case covers only a small subset of a car, but its project complexity remains considerable and involves great interorganizational complexity. The automotive industry is organized based on a highly modular multitier arrangement of component suppliers; one of the main challenges of the project is to coordinate the work, not only between the two suppliers but also with other actors. One of the suppliers is small (ca 100 employees), and the other one is a large multinational company (100,000+ employees). For this project, most team members are based in the same city, while a few others are located elsewhere but remain within the same time zone.

Both suppliers employ the agile approach on a team level. They describe their team structures as being organized around backlogs and product owners. The agile approach is still not considered the industry norm, and Case B is regarded as an extreme case within its industry in terms of the extent to which the agile approach is applied. The organizations spend considerable and increasing effort aligning their work using various agile practices, such as PI planning. The smaller of the two suppliers must align its process with the large supplier and the customer—the OEM. This alignment is based on daily coordination and aided by their history of working together. Both suppliers, however, must also align with other customers and internal processes, which makes the coordination of work intensive and cumbersome, especially because the teams and individuals involved in the project are not dedicated only to it.

The data collection and analysis followed an iterative process that involved moving between theoretical concepts and empirical data (Dubois and Gadde, 2002). The process began with a review of the previous literature on the interrelationship between the agile approach and project complexity in product development. Subsequently, to adopt a multi-dimensional perspective on project complexity, an analytical framework was developed. The analytical framework draws on the dimensions proposed by Kim and Wilemon (2003), complementing and refining their descriptions with further insights derived from the literature (see Table 1). Subsequently, the empirical data were collected through semi-structured interviews and documents. Semi-structured interviews are suitable for gaining in-depth insights into individuals’ experiences regarding a phenomenon (Bryman and Bell, 2011; Yin, 2018), in this case the application of the agile approach in product development projects and its interrelationship with the dimensions of project complexity.

Interviewees were selected to capture a diverse range of perspectives on the application of the agile approach and their perception of project complexity, and to provide informed and contextually relevant insights into the research question. The selection criteria for interviewees included involvement in the application of the agile approach (e.g. decision-makers and practitioners actively using agile practices) and diversity in terms of roles and experience levels to ensure a comprehensive perception of project complexity, as it is influenced by the participants’ roles (cf. Mikkelsen, 2021). According to these criteria, the initial set of interviewees was identified by the contact person in each case. As the study progressed, additional interviewees were identified and included in the study. The distribution of interviewees’ roles is shown in Table 3.

In total, sixteen interviews were conducted for Case A and fifteen for Case B. For Case A, the interviews were conducted individually, except for one instance in which two interviewees requested to be interviewed together. For Case B, the interviews were also conducted individually; however, one interviewee participated in a follow-up interview. All interviews were audio- and video-recorded and subsequently transcribed. They followed a predefined interview protocol, which was slightly adjusted depending on the role of the interviewee and lasted between 40 and 110 min. Documents were employed as an additional data source to corroborate and enrich the information gathered from the interviews. These documents included confidential internal company materials containing information on organizational structures, formal roles, and management models as well as training materials concerning the application of the agile approach.

In line with ethical guidelines, verbally informed consent was obtained from each interviewee, either directly or through their legal representative. At the beginning of each interview, the participants were informed of the study’s purpose, the measures taken to ensure anonymity, and the procedures for data handling. All interviews were conducted in Sweden ^[1]. In addition, non-disclosure undertakings were established between the research team and the participating organizations; accordingly, the collected data are not publicly available.

The data were analyzed using the process proposed by Miles et al. (2020). In the data condensation phase, codes were assigned to relevant excerpts of the interview transcripts, often using interviewees’ own wording to preserve the closeness to the empirical data. Excerpts with similar meanings were grouped under the same code, with constant comparison across transcripts and codes ensuring consistency. These codes were then related to themes (dimensions of project complexity) as described in the analytical framework. Illustrative transcript excerpts are presented in Section 6. It is important to note that, while the framework informed the analysis, the latter was not constrained by the former (Dubois and Gadde, 2002). The analysis followed an abductive approach that allowed alignment with literature while also enabling emergent insights into the interrelationship between the agile approach and the dimensions of project complexity. In the drawing and verifying conclusions phase, pattern identification and clustering were applied to examine how the agile approach was interrelated with the various dimensions of project complexity, as presented in Section 3.3. Each case was analyzed separately by two researchers. Regular discussions among the researchers ensured consistency during the interpretation and integration of multiple perspectives. Computer-assisted qualitative data analysis software was used as a tool, which ensured version control and traceability throughout the process.

In Case A, technological complexity arose from the diversity and number of technologies involved in product development projects. As one interviewee explained, “It’s also really a lot of different technologies involved (…) So it’s really maybe ten different technologies, you know, depending on the geometry of the [product]” Interviewee A21. These technologies were often developed in house and had to be validated and implemented from a manufacturing perspective before the product development projects could proceed. The implementation of these technologies demanded, among other things, feasibility for large-scale manufacturing and the consideration of additional requirements, such as lead times, resource availability, and training. Collectively, these factors contributed to the technological complexity of Case A.

In Case A, roadmaps played a crucial role in managing technological complexity. These roadmaps provided a five-year timeline perspective, outlining the technologies under development and their expected delivery timelines, which were in alignment with the needs of development projects. As a result, the roadmaps facilitated coordinated decision-making by enabling the planning of dependencies, the prioritization of development efforts, and the allocation of resources. These roadmaps ensured alignment between technology development and product development projects, enhancing overall project efficiency. Interviewee A5 further elaborated on the significance of roadmaps in managing technological complexity, emphasizing their role in fostering coordination and alignment.

Technological complexity was a key aspect of Case B as well, involving organizations operating at the technological function and component level of the ecosystem. Indeed, technological complexity was even greater at the end-product (car) level. Even at the component level, it was quite comprehensive, requiring dedicated expert developers across all participating organizations. These experts, based on technological requirements, coordinated their efforts in large PI planning meetings led by the car manufacturer, who controlled the global project plan. As reflected on by Interviewee B2, “… we have very diverse products [components] too, like a radar where you do the entire software and hardware every time. The things I work with tend to have a hysterical [number] of organizations involved.”

Change propagation was a recurring theme, and the perceived difficulty of foreseeing and managing it was a clear indication that technological interdependence was high. In response, Case B’s organizations attempted to minimize their internal technological complexity by identifying emerging patterns in solutions tailored to various customers. Interviewee B2 continued, “There will always be an adaptation for each project or customer, but the more we can reuse and the less you need to develop new code, the better.”

In Case A, the environmental complexity stemmed from the fact that to remain competitive and retain customers, Company Alpha faces the ongoing challenge of enhancing its product offerings while accelerating time-to-market. Managing a larger portfolio often requires a greater effort to coordinate and synchronize resources across product development projects.

An agile practice that played a crucial role in addressing this project complexity was the use of task boards at the project portfolio level. By implementing this practice, decision-makers gained a comprehensive perspective on ongoing and future projects, enabling them to allocate efforts effectively and prioritize initiatives strategically. Another aspect of the environmental complexity in Case A was the company’s emphasis on high product quality, which is seen as key to maintaining market leadership. Product quality has been demonstrated through certifications, which are also common across the industry. However, such certifications constrain the applicability of the agile approach. For example, compliance with international quality standards requires adherence to the company’s traditional process models and documentation, with steering groups making decisions and allocating resources. Such practices restrict teams’ decision-making to technical aspects and require documentation to be completed at each stage, thereby limiting the iterative and evolutionary development suggested by the agile approach.

Environmental complexity was clearly present in Case B as well. The automotive industry is highly mature, with an equally mature ecosystem of suppliers for parts and components. The constantly evolving demands of industrial scale have led to a best-of-breed supplier market across all technology levels. In Case B, the OEM adopted an externally developed automotive operating system from a global tech firm. As reflected upon by Interviewee B2, updates to this operating system were issued regularly, and any resulting change propagation had to be addressed by both organizations involved in the case: “But, sometimes, there is a new Android version, and things crash. Are there components requiring Android version eleven and Android twelve? That’s the way it is. If Google changed something, there will be work.”

Although such a heavy reliance on external technology providers presented additional challenges in terms of keeping the product functional, over-the-air (OTA) software updates to vehicles provided some relief, negating the previous need for physical visits to the brand garage and thus enabling an agile development practice.

Regarding the marketing complexity of Case A, the company has adopted a periodic product release strategy. Additionally, its products are typically distributed through its distribution centers worldwide. The company enforces a fast-delivery policy, requiring products to be dispatched to customers within a short timeframe. The combination of the periodic product releases and fast-delivery policy imposes constraints on the application of the agile approach in development projects. It defines strict deadlines for project completion, influencing the duration of iterations and prioritizing adherence to due dates over incremental development, as suggested by the agile approach.

In Case B, the marketing complexity was not significant, as the development project fed directly into the customer’s own development. This meant that interaction with the customer was high and no B2B marketing in the traditional sense was required within the scope of the project. Instead, the case was subject to the effects of the agile approach, as it enabled projects to introduce changes at a later stage than traditional Stage-Gate or waterfall models. This transformed the prevailing mindset within the ecosystem, presenting new development options, such as deferring or modifying certain user functions in later updates based on market feedback after cars are sold. Interviewee B3 reflected on the case of the car radio as follows:

Development emerged as a critical dimension of project complexity in both cases. In Case A, for example, development complexity arose from the need to forecast development efforts, manage interdependencies between development stages, support decision-making and problem-solving, and manage overall project duration. All these elements were essential to not only prevent delays in deliveries but also reduce lead times, thereby accelerating product introductions into the market. As Interviewee A17 put it, “It is quite common for them to get delayed during the product development phase. I mean, when you are halfway into—or even in the late stage of—the product development project, every delay becomes quite costly. So, that is one thing. In general, we would like to minimize delays in product development projects, and we would also like to shorten average lead times or throughputs.”

The agile approach supported the forecasting of development efforts in Case A. For example, development efforts were divided into sprints. Sprint planning meetings facilitated effort estimation and the management of overall project duration, as team members found it easier to estimate task-related effort, in terms of time, workload, and interdependencies, over four to six weeks rather than across the entire two-to-five-year duration of the product development project. The forecasting of development efforts was further enhanced by the involvement of self-organizing teams and the use of task boards, which simultaneously contributed to managing interdependence between development stages, decision-making, and problem-solving. On one hand, self-organizing teams recognize team members as the most competent to estimate development effort. Therefore, the responsibility for effort estimation and the planning of activities to be undertaken during each sprint lay with the team members. Interviewee A4 pointed out “With clarity that each team member plans their own work and, by that, demonstrates that they understand the sprint targets that the team needs to resolve.” On the other hand, task boards functioned as tools for identifying or predicting work delays, thereby supporting and streamlining the flow of activities. These task boards made it easier to detect delays in activities, enabling teams to address issues and initiate discussions promptly and thus ensure the achievement of the planned results for each sprint. Moreover, task boards and sprint planning facilitated understanding and communication among team members by clarifying the various activities they needed to perform and how these activities contributed to one another. Interviewee A20 effectively summarized the importance of self-organizing teams and task boards in forecasting development efforts.

The development complexity of Case A also included constraints on available resources. In general, the application of the agile approach across project teams supported flexibility in terms of reallocating resources between projects. Interviewee A20 mentioned that “We should remember that some people switch between projects more frequently than they switch between departments. That is why it is important for us to set a standard so that we can maintain flexibility while ensuring that people still recognize [practices across projects].” Interestingly, Case A also employed task boards at the departmental level, which visualized all activities undertaken by the department to support both ongoing and planned development projects. As a result, even if certain members were assigned to specific projects with defined deliverables, they could integrate those deliverables and activities within the department and receive support from other department members. Additionally, demo meetings proved important in managing the project’s extended duration. As years passed between decision points, demo meetings facilitated frequent engagement with stakeholders and the steering committee by providing them with detailed project information throughout the project’s duration.

In Case B, the development complexity also stemmed from the necessity of resource forecasting. In this case, it was addressed through a contract based on the assumption that unforeseen work, which was not anticipated at the time of drafting, would nonetheless have to be performed. The contract therefore consisted of one fixed part with well-defined content and one loosely or even undefined part—an agile hour bank that could be used wherever it was needed most according to project needs. Furthermore, as projects neared completion or, at least, reached some degree of maturity, the focus tended to shift from team autonomy to a more singular backlog prioritization focus. Interviewee B1 explained as follows:

Organizational complexity was significant in Case A. In this case, complexity arose due to the global distribution of team members across company facilities. It was especially pronounced at handover points during the development project, as designers, production engineers, and engineers at production units, despite their critical need for integration and synchronization, were not co-located. Moreover, production units were geographically dispersed worldwide. As Interviewee A7 explained, “I think the main challenges are the handover points. We have an R&D department designing our products, and then, we have a handover, but they are not located at our production units (…). Then, there is a handover to the production technology department (…) Finally, there is a handover to production.” These challenges were partially addressed through the formation of cross-functional teams comprising representatives from the various organizational units and/or departments involved in the development projects. Collaboration within these project teams was enhanced by using digital task boards, which facilitated remote communication and discussions among geographically dispersed team members.

While cross-functional teams facilitate collaboration within the development team, they also present challenges. Each organizational unit or department pursues its own local improvements, which do not necessarily align with the development project’s prioritization. Consequently, in Case A, complexity arose due to the number and diversity of stakeholders and their varying interests. In this case, the agile approach was employed to manage such complexity, particularly via task boards at the project portfolio level. These task boards provided an overview of the development project pipeline, illustrating the status of ongoing and upcoming projects from a timeline perspective. The project portfolio task board served as a strategic tool for identifying dependencies and ensuring the alignment of project prioritization across organizational units and departments. Additionally, as Interviewee A21 explained, demo meetings also facilitated information sharing within and across project stakeholders.

The organizational complexity of Case A also stemmed from governance structures, decision-making systems, and the distribution of authority and responsibility, as stated in the company’s traditional project management process model. The model and its remnants of the control paradigm constrain the effectiveness and associated benefits of the agile approach. Specifically, team members’ decision-making autonomy was limited by the authority of the steering committee, preventing them from making decisions related to resource allocation, decision points, and other critical factors. This constraint was clearly articulated by Interviewee A4, who explained, “It depends. If it’s minor changes, then the project team handles it themselves—if it does not affect the overall planning (…) But if it’s a more complex issue that requires project replanning, then we essentially need to go back to the planning phase. That means making a new [decision point] pass.” Nevertheless, as the steering committee did not meet frequently, teams had to wait until scheduled decision points, which delayed decision-making. This also undermined empowerment and self-management, as advocated by the agile approach, thereby diminishing the associated benefits, such as the teams’ sense of responsibility and motivation.

In Case B, organizational complexity was manifested in the internal balancing act between the needs of the project’s customer and the internal product platform the organization was building in parallel. Taking a platform development project into account introduced additional complexity for the project, particularly in terms of coordination and business priorities but also in relation to organizational politics. Interviewee B4 explained this dual prioritization as follows:

In Case A, the project was conducted within the organization, with no interorganizational complexity being involved. In contrast, Case B involved extensive interorganizational interactions, making this a key project complexity. As the product technical architecture required several actors to work on the code simultaneously, the complexity increased, which was evident in the communication patterns, the involvement of more people and managers, and the difficulty of discerning who was responsible for troubleshooting and fixing bugs. This complexity slowed down decision-making and, thus, the responsiveness to change, as reflected on by Interviewee B1:

As the automotive supplier ecosystem was entangled, in Case B, the multinational supplier, being significantly larger than the automotive OEM, could not view customer demands for new functions and features on the part of a component in isolation. Instead, such requests were considered as part of a broader set of demands from multiple customers relying on the same component platform. Moreover, the agile approach was far from universally adopted across the automotive industry, and the multinational supplier had to adapt specifically to the needs of the OEM in this case.

First, in line with Odusanya et al. (2021), the study indicates that the agile approach supports the management of certain dimensions of project complexity. It shows that the agile approach, particularly agile practices such as Kanban boards, sprint planning, and self-organizing teams, supports the management of organizational and development dimensions of project complexity. These practices enable transparency and iterative planning, which facilitate effort estimation, as practitioners find it easier to identify task interdependencies and estimate the effort required for the coming weeks as compared to that required for the entire duration of the project. The study therefore provides empirical evidence of proactive practices for managing project complexity, as previously advocated in the literature (cf. Baccarini, 1996; Mikkelsen, 2021; Kim and Wilemon, 2009; Kiridena and Sense, 2016). These findings lead to the following proposition:

Nevertheless, the agile approach reveals project complexity that was previously hidden by centralized project management roles and models. This may be frustrating for the individual focusing on technical problem-solving and raise questions regarding where in the organization the responsibility for coordination should be located. If the responsibility for coordination is centralized, responsiveness and in-depth information about the development efforts may be lost, but if it is decentralized, teams may be overwhelmed by coordinating work they do not have overview of. Moreover, project planning and overall complexity management are typically tasks that are new to team members. Completing them is not necessarily their main motivation, even though the agile approach dictates that teams be autonomous entities to ensure focus and stable throughput. It is possible, therefore, to suggest the following:

Moreover, the various dimensions of project complexity hinder the applicability of the agile approach. This is especially evident in the interorganizational complexity created via the increased coordination costs implied by large interorganizational projects but also in technological complexity, in which change propagation becomes a problem and architectural decisions must be made early at the expense of design flexibility in later phases. When several organizations are involved in a project, the need for coordination among them increases. In some cases, this coordination comes at the expense of the flexibility to make changes. This finding complements previous studies that suggest that outsourcing could support preserving maximum flexibility in terms of effectuating agile (cf. Teece et al., 2016). In contrast, this finding shows that when multiple organizations are involved, this may reduce flexibility, hindering the applicability of the agile approach. A number of industries in which companies operate are undergoing digital transformation, leading to new collaboration logics. It is no longer sufficient to establish a traditional supplier–customer relationship; development work needs to be done in a tighter collaboration mode in which risks and rewards are shared in a more transparent manner. This means that individuals working on a project must collaborate with people from various organizations, which increases the complexity of their day-to-day work. Additionally, issues such as contracts, intellectual property, collaboration tools, and other interfaces must be planned for up front and dealt with during the execution of the project. This finding confirms previous research that showing particular dimensions of project complexity, for example, developmental (cf. Odusanya et al., 2021) and organizational complexity (cf. Sońta-Drączkowska and Krogulec, 2024; De Oliveira Santos et al., 2024), influence the applicability of the agile approach and the realization of its associated benefits. One could therefore argue as follows:

These propositions illustrate the intricate and contradictory interrelationship between the agile approach and project complexity in product development. This extends prior research that has addressed the specific dimensions of project complexity in isolation (cf. Odusanya et al., 2021; Sońta-Drączkowska and Krogulec, 2024; De Oliveira Santos et al., 2024). By situating the agile approach within multiple dimensions of project complexity (i.e. technological, environmental, market, development, organizational, and interorganizational complexity), the study provides insights into the dimensions that hinder and/or support effective application, including those not examined in previous studies of product development projects. In doing so, it contributes to the ongoing discussion about the application of the agile approach in product development (cf. Dikert et al., 2016; Conforto and Amaral, 2010; Cooper and Fürst, 2023; De Oliveira Santos et al., 2024).

The presence of combinatory effects, in which multiple dimensions of project complexity interact and may even reinforce one another, thereby constraining or amplifying their interrelationship with the agile approach, was also observed in this study. For example, in Case A, the product development projects rely on internally developed technologies. While this internal development reduces dependence on external partners, thereby mitigating the interorganizational dimension of project complexity, it simultaneously intensifies the other dimensions of project complexity. These various technologies demand highly specialized knowledge, which must be integrated into each product development project. This demand for specialization and integration can constrain the application of the agile approach, particularly agile practices related to stable team composition, flexible resource allocation, and collaborative teamwork. Consequently, teams tend to grow in size, often being divided into sub-teams, which amplifies the organizational dimension of project complexity.

A second example derived from Case A pertains to the environmental dimension of project complexity. The industry and its customers demand high-quality requirements that companies must meet, often through compliance with established quality standards rooted in Stage-Gate models. As described, the agile approach is applied as an additional layer within this model. However, this layering may limit the applicability of agile principles, such as self-organizing teams. It can also increase cognitive load among team members, who must navigate and adhere to two slightly divergent sets of practices simultaneously.

A third example evident in Case B stems from the inherent complexity of the technologies and the involved organizations’ attempts to reduce such complexity by reusing as much as possible of their own existing code. This led to all actors pursuing a strategy of reuse and putting in place organizational assets and processes to ensure this. However, this created a tension between internal demands for efficient reuse and external customer demands for tailor-made adaptations.

In Case B, these combinatorial effects were also evident between technological and interorganizational project complexity. As described, the technological requirements and architecture of the component demanded simultaneous contributions on the part of multiple actors from various organizations. Technological complexity thus contributed to interorganizational complexity. This coordination was supported by the agile approach, including agile practices such as PI planning meetings, which were intended to align the efforts of the involved actors. However, the complexity of the resulting components, combined with the many organizations involved, made it difficult to clearly assign responsibility for troubleshooting and bug resolution, undermining crucial benefits associated with the agile approach.

Furthermore, the interorganizational complexity also intensified exposure to environmental complexity. For example, frequent updates to the externally developed automotive operating system triggered change propagation across several participating organizations. This propagation of changes also impacted the development of internal product platforms, which had been employed by the organizations in Case B as a strategy via which to mitigate internal technological complexity while simultaneously enabling the efficient delivery of tailored solutions to other customers.

The identified combinatory effects confirm the observations of De Oliveira Santos et al. (2024) and Pinciroli (2024), who point out overlaps among dimensions of project complexity as well as the constraining influence of contextual and project-specific factors on realizing the benefits of the agile approach. Furthermore, these combinatory effects align with the interaction among system elements and the emergence of outcomes as described in complexity theory (cf. Stacey, 2001; Cooke-Davies et al., 2007; Meso and Jain, 2006; Cilliers, 2000; Anderson, 1999).

This article demonstrates that the agile approach and project complexity are interrelated in intricate and, at times, contradictory ways. The study indicates that the agile approach can support the management of project complexity by enabling adaptation, fostering collaboration, coordinating dependencies, and improving effort estimation. It also indicates that the agile approach generates project complexity, as it reveals tensions due to the location of responsibility for coordination efforts. Moreover, the study reveals that project complexity may limit the applicability of the agile approach, thus offering insights into the conditions under which it can be applied. This is particularly evident in the case of interorganizational complexity, in which the involvement of multiple organizations increases the need for coordination, which, in turn, often reduces flexibility and, thus, the ability to address emerging challenges. The intricacy of this interrelationship raises questions regarding the allocation of coordination responsibilities within organizations and highlights tensions in collaboration logics. This study therefore contributes to the literature on the application of the agile approach in product development (cf. Atzberger et al., 2020; Dikert et al., 2016; Cooper and Fürst, 2023), as it indicates dimensions of project complexity that can limit the applicability of the agile approach in the product development context; however, is also contributes to the literature on managing project complexity (cf. Mikkelsen, 2021; Kiridena and Sense, 2016; Little, 2005), as it indicates that agile is a managerial approach that support the management of the various dimensions of project complexity.

Overall, the study highlights the importance of conducting an examination of project complexity when applying the agile approach, using structured frameworks such as the one proposed by Kim and Wilemon (2003), which considers the multi-dimensional nature of project complexity. Focusing solely on commonly examined dimensions, such as technological or organizational dimensions, risks overlooking other critical ones that may constrain or misguide the effective application of the agile approach. Therefore, an examination of project complexity may support a deeper and more detailed understanding of when, how, and why the agile approach can be effectively applied and why the associated benefits may be undermined. Moreover, although this study focused on product development projects, examining project complexity when applying the agile approach can be extended to other types of projects. For example, digital transformation, service development, and construction projects, are likewise exposed to project complexity and may benefit from such examination, albeit with potentially different dimensions. Indeed, studies on construction projects have already indicated that the agile approach may contribute to reducing or managing project complexity (cf. Sohi et al., 2016).

The study provides implications for project managers, project sponsors or owners, and steering committees. It raises their awareness of how the agile approach can support, generate, or be limited by project complexity. By considering multiple dimensions of project complexity, these roles can develop a more reflective understanding and an informed tailoring of the agile approach to meet specific contextual demands. Conversely, neglecting the various dimensions of project complexity could hinder the benefits associated with the agile approach. For example, neglecting project complexity arising from interorganizational product development efforts may lead project managers to underestimate coordination costs, delayed decision-making processes, or the need to align practices. The study shows that the interrelationship between the agile approach and project complexity may generate combinatory effects. Thus, a reflective application of the agile approach, in which practices are adjusted based on outcomes, is essential. Although the agile approach provides managerial options, it cannot ensure complete control over project complexity.

The limitations and contributions of this study open avenues for further research. Cases situated in different contextual conditions and with varying characteristics could help test the presented propositions. For example, cases operating under distinct market logics could yield additional insights into the interrelationship between the agile approach and marketing complexity. Moreover, longitudinal studies examining this interrelationship over extended periods could provide deeper insights into its evolution. Furthermore, the combinatory effects among project complexities fall outside the scope of the analytical framework used in this study, as it, despite considering multi-dimensionality, represents a static view of project complexity, thereby failing to capture the dynamic interrelations between complexities. Future research may therefore benefit from frameworks and research methods that incorporate the principles of nonlinearity, emergence, and unpredictability, as suggested by complexity theory (cf. Bakhshi et al., 2016).

The authors thank the interviewees for sharing their perspectives and valuable insights during the interviews. They also extend their gratitude to the editors and reviewers whose thorough and constructive feedback helped improve the quality of this article.