Keywords

1 Introduction

Agile practices in software development have been around for quite some time and originally emerged due to the need to adapt faster to changing customer requirements [1]. Developing in iterations provides the required flexibility and enables agile projects to “identify and respond to changes more quickly than a project using a traditional approach” [1]. With the focus being on “individuals and interactions over processes and tools” [2], preferably through face-to-face communication, agile practices initially aimed at small, local teams. However, as agile development became more popular, larger organizations adapted certain practices as well [3]. As a result, large-scale agile frameworks, such as SAFe [4] and LeSS [5], were developed to provide guidance to large organizations. The application of scaled agile methods has already been investigated to a great extent, e.g. in [3, 6,7,8,9,10], and [11]. The focus, however, lies mostly on large-scale projects or multiteams within one organization. This lead us to the question: How to scale agile even further, beyond organizational boundaries?

Software ecosystems can be defined as “the interaction of a set of actors on top of a common technological platform that results in a number of software solutions or services. [...]” [12]. Opening up a platform to external developers enables platform operators to expand their offerings and provide further functionalities that they would not have been able to develop themselves, thereby providing more value to the customer but at the same time requiring additional coordination efforts [13, 14].

In large-scale distributed, agile teams, inter-team coordination has previously been identified as a major challenge [8]. As large-scale software ecosystems differ from traditional organizations in various ways, these challenges cannot directly be adopted. For one, each actor within the ecosystem has its own way of working that can hardly be standardized [13]. This results in many different practices applied across the ecosystem and, therefore, many different degrees of agility which can be difficult to align. Moreover, the actors do not belong to a single but instead to many different organizations which share different, possibly competing, relationships. For this reason, the actors do often neither share the same goals nor communicate in a fully open way. This makes the inter-team coordination even more difficult.

To our knowledge, the challenges of inter-team coordination beyond organizational boundaries are not yet sufficiently investigated in existing literature. For that reason, we raise the following research questions:

  1. (a)

    How do agile teams within software ecosystems coordinate their efforts?

  2. (b)

    Which inter-team coordination challenges do agile teams within software ecosystems face?

In order to achieve this, we conducted a case study within two large, industrial software ecosystems to investigate their processes and inter-team coordination. We elaborate the results along three dimensions that constitute the framing for our findings: (a) maturity of the ecosystem (b) phases within the agile lifecycle (c) openness/closedness of the ecosystem. We use this framing to map the conflicting interests between actors as well as the resulting challenges and implications to the dimensions. Therefore, the contribution of this paper is to unfold why certain conflicts arise in a particular situation or setting in order to increase awareness of other actors’ mindsets, and to help practitioners understand certain challenges and possible trade-offs they, thereby, might be facing. Moreover, we were able to tie most of the challenges back to long communication paths and a lack of established processes, raising the need to extend existing agile practices.

The remainder of this paper is organized as follows: First, we explain the characteristics of software ecosystems in Sect. 2, followed by our case study design in Sect. 3. In Sect. 4 we present the results of our study, before providing an overview of related work in Sect. 5, and summing up and concluding our work in Sect. 6.

2 Characteristics of Software Ecosystems

One of the major differences between distributed teams in traditional organizations and software ecosystems is the fact that the teams or actors are not within the same company or organization but instead spread across several organizations, whereby each actor contributes different elements to the system or product. This entails various types of relationships between actors within an ecosystem. For instance, the actors can be competitors or share mutual benefits [12]. The complexity of relationships and dependencies increases with the number of parties involved in the ecosystem [13]. Moreover, the number of actors and their possibly competing relationships results in a lack of sharing data which has previously been observed in large organizations [15].

Even though iterative requirements engineering processes provide an increased flexibility and are already widely applied in software ecosystems, further challenges arise due to the ecosystem’s various actors, the physical distance between them, and the complexity of dependencies within the ecosystem, which impede a common understanding among and alignment between actors [16,17,18]. For one, the interpretation and prioritization of requirements can differ highly between ecosystem actors because different stakeholders value different attributes when dealing with a requirement. Every partner contributes requirements to the ecosystem which might result in a requirement overload, causing complications in the prioritization process [19]. Additionally, the negotiation process of requirements is highly influenced by the amount of power and dependencies between actors [18]. An adequate understanding of the other actors’ goals and business models is required in the requirements engineering process in order to satisfy existing stakeholders and attract new partners.

In this paper we analyze how the described characteristics and challenges manifest in the inter-team coordination of agile teams within software ecosystems.

3 Case Study Design

Case studies are a well-known research methodology to investigate and understand contemporary phenomena in their real-world context with no or little control by the researcher [20, 21]. As our research questions aim at answering exploratory questions, we believe that this is the right methodology for our study, following the guidelines by Runeson and Höst [20].

Case Study Design. The research objective of our study was to investigate the inter-team coordination and its accompanying challenges across organization boundaries. Specifically, our study focuses on how teams in distributed organizations communicate with each other, what kind of information, feedback or data they share, how it is shared, and how they are making and communicating decisions that affect any of the other teams. To achieve this, we performed this case study in two large software ecosystems, Ecosystem A and Ecosystem B, which are established in the industrial and the healthcare domain, respectively. Each ecosystem originated in a large, industrial company and offers several services, mostly in terms of applications, to the companies’ customers. In order to expand their offerings, they opened up their platform to internal as well as external partners developing applications on the platforms. Figure 1 gives an overview of the ecosystems’ structures and actors. We chose the respective ecosystems for our study since the keystone as well as the partners work in agile teams and experience difficulties in their coordination.

Fig. 1.
figure 1

Actors in ecosystems

Full size image
Table 1. Description of ecosystems
Full size table

Data Collection and Analysis. We conducted semi-structured interviews with key stakeholders within the two ecosystems. Four product owners (PO), one product manager (PM), one demand manager (DM), and one software architect (SA) participated in the study. The demand manager is responsible for collecting and structuring requests from partners and customers before forwarding them to appropriate platform teams. Each of our interviewees belongs to a different, individual agile team within the respective ecosystem and was chosen as a key stakeholder to represents the views of their entire team. Moreover, all interviewees belonged to either the keystone who develops the platform (PM, DM, and one PO) or to a complementing player (three POs, SA) of an ecosystem, therefore providing views from both angles. One product owner, the demand manager, and the software architect belonged to Ecosystem A and the product manager and three of the product owners belonged to Ecosystem B (see Table 1 for a structured overview of the ecosystems and our participants).

All interviews included the following topics: communication structures, exchange of data and feedback with partners and customers, and decision making processes; though the interview guides were slightly adjusted to the specific roles. At the beginning of each interview the participants were given a brief introduction into the study and the structure of the respective ecosystem was shortly discussed in order to create a common understanding. Following this, the interviewees were asked for their permission to audio tape the interview, before the interviews were conducted. Each interview lasted between 45 min and one hour, and was transcribed and summarized afterwards.

Additionally to the interviews we derived further knowledge from two experts in this field. Both of them have been working in and with multiple ecosystems, including Ecosystem A and Ecosystem B, for several years, and shared their experiences in a couple of unstructured interview sessions. They provided additional insights on how the respective ecosystems are structured from a bird’s-eye perspective in contrast to the team perspectives. Moreover, we discussed the findings of our interviews with them in order to support the validity of our study.

As a result, we achieve triangulation by (a) investigating multiple software ecosystems (b) interviewing multiple roles within the ecosystems (c) adding expert knowledge.

4 Results

One major difference between distributed teams in large organizations and teams within software ecosystems is that the actors within an ecosystem do not belong to the same company or organization and, therefore, do not necessarily share a common (business) goal. Since we wanted to understand why certain challenges occurred, we decided to first investigate the respective (differing) interests on the keystone’s as well as the partners’ side in order to locate potential sources of conflicts, before we focused on the analysis of the challenges. Hence, this section is structured as follows: First, we describe the dimensions used in our framework, followed by the conflicting interests, and concluding with the identified challenges.

4.1 Influencing Factors

During the analysis of our data we observed that our findings were highly dependent on three different factors: the phases of an agile lifecycle comprise different tasks that require different communication and coordination processes, and the maturity as well as the openness of an ecosystem influence the relationships between actors and, therefore, also the communication. These factors constitute the main dimensions of the models that include the results of our study, and are explained in detail in the following sections.

Agile Lifecycle. The common agile lifecycle includes an initial requirements definition and planning phase, followed by a development phase including integration and tests, a review and feedback phase, frequent releases, and a reprioritization phase before the next iteration begins [22]. Since all our interviewees work in agile teams, they all go through a similar agile lifecycle, experiencing different challenges in different phases. As the focus of our study is on coordination challenges, we neglected the technical phases (development and release) but rather focused on the planning, prioritization and feedback phase. We asked each interviewee about the phases they go through and, based on the literature as well as their answers, we propose the agile lifecycle in Fig. 2 that constitutes one dimension in our study.

Fig. 2.
figure 2

Agile lifecycle

Full size image

Maturity. Based on our interviews, we noticed that the maturity of the respective ecosystems plays a rather important role. Especially the communication between keystone and partners changes drastically over different phases of maturity. For instance, in the early phases of opening up a platform it is important to attract new and please existing partners, therefore the focus on communication is much higher than in later phases when the ecosystem is mature enough to attract partners automatically because of its success and the benefits for the partners.

One way to describe the evolution of a technology or an innovation is the s-curve. It describes the performance of a technology during different maturity stages from “pregnancy, birth, childhood, adolescence, maturity, and decline” [23]. Both ecosystems already have products on the market but regarding their maturity we would classify Ecosystem A as still being in the “birth” phase and Ecosystem B as being in the “childhood” phase. Specifically, Ecosystem A is still in the process of opening up their development to external partners while Ecosystem B is already established but still accelerating. For this reason, we define the second dimension as the maturity from “opening up” to “acceleration”.

Openness vs. Closedness. Hartman et al. identified two different types of ecosystems, open and closed [24]. While closed ecosystems are still tightly coupled to and somewhat controlled by the keystone, open ecosystems are easily accessible for partners and can be characterized by their interchangeability of components and parties. However, ecosystems are not necessarily one or the other, they can also be in a hybrid stage [24]. This is relevant for our study since the communication and trust across ecosystem partners appears to be different for the two types. For instance, the actors in closed ecosystems are more interconnected than the actors of open ecosystems and, therefore, communicate more openly and share a higher level of trust. By tendency, Ecosystem A belongs to the category “open ecosystem” while Ecosystem B incorporates closed as well as open aspects. This is directly reflected in the characteristics of relationships that the keystone shares with different types of partners (both external & internal).

Fig. 3.
figure 3

Conflicting interests between different ecosystem actors

Full size image
Table 2. Description of conflicting interests between keystone and partners and the influencing factors in different phases
Full size table

4.2 Conflicting Interests

Each ecosystem actor usually follows its own business strategy which can easily result in different interests that are hard to align and, therefore, cause conflicts between the actors. In order to analyze which opposing interests might lead to conflicts, and based on that even challenges, we extracted the interests of the partners as well as the keystone out of the interviews. Next, we mapped contrary interests that share a common link from both sides to each other which, therefore, constitute main drivers and crucial influencing factors for certain conflicts. Since not all interests and conflicts apply to all ecosystems or to all phases of agile development, we mapped the conflicting interests to different maturity levels, phases within an agile lifecycle, and the degree of openness (see Fig. 3). A more detailed description of the conflicts, interests of the platform and partners, and other influencing factors can be found in Table 2. All of the described results were derived out of the interview sessions of our case study. Overall, we identified nine conflicts that were caused by opposing interests on the partners’ and the keystone’s side. Three of the conflicts originated in the planning phase, four in the value prioritization phase, and two in the feedback phase.

Fig. 4.
figure 4

Mapping of challenges to different settings

Full size image

Planning Phase. Conflict #1 concerns the platform functionalities provided by the keystone and required by the partners. On the one side, the partners require the keystone to provide specific functionalities for their minimum viable product (MVP) while the keystone receives so many requests that it is difficult to take all partners into consideration so “[they] need to come to a point where [they] say what platform value creates the most value to the ecosystem and that’s not easy because the ecosystem is so broad”. For this reason, the keystone concentrates its planning efforts on the partners that bring the most value to the ecosystem.

The next issue (#2) is related to the communication of requests and the inconsistency of processes. Partners want to communicate their requests in an easy and fast way, and expect the keystone to respond to their requests, while the keystone “receive[s] quite small or tiny, tiny described requests” but “would like to receive more well described requests” from their partners. As there are no consistent processes available this often leads to misunderstandings of what the requirement actually is and, therefore, causes displeasure on both sides.

Moreover, the keystone’s control and the partners’ independence (#3) lead to conflicts, especially in closed ecosystems. While the partners want to be independent of the keystone in order to being able to optimize individual business interests, the keystone wants to keep control over the end-customers and the partners’ interactions with these customers in order to ensure a coherent, overall business offering.

Table 3. Description of coordination challenges caused by divergent interests of actors within the ecosystem
Full size table

Value Prioritization Phase. Conflict #4 concerns prioritizations and different business strategies. As each partner follows its own business strategy, the keystone wants to ensure the ecosystem’s future which leads to conflicts in the prioritization process since the different strategies can be difficult to align. One interviewee explains that they need to decide “from a platform point of view, what makes most sense, what is scalable, what is beneficial for a lot of customers [...] that’s a challenge”.

It is quite natural that some ecosystem partners are more important business partners to the keystone than others. However, this leads to different power relations (#5) as the important partners can create more pressure on the keystone than the others. Ultimately, the partners expect the keystone to be aware of them and their needs and to be treated (at least) equally to other partners, while the keystone wants to bind its important partners (e.g. defined by the number of customers, revenue etc.) to the platform.

Moreover, especially during that opening up phase, the ecosystem partners expect transparency of the keystone, e.g. concerning the prioritization of next steps, delivery timelines, or commitments. One of the interviewees states that he “would like to have more transparency how and on what basis decisions are made [...] because at the moment it’s very non-transparent how [the keystone] decides what constitutes the biggest value for the overall project”. However, the keystone avoids giving too detailed commitments and detailed timelines in order to stay flexible and being able to reprioritize. This leads to conflicting interests concerning the amount of transparency by the keystone (#6).

Analogously to and building upon conflict #3, the keystone’s control and the partners independence (#7) create a conflict in the prioritization phase of closed software ecosystems. The partners would like to base their prioritization on a broad picture of all their customers while the keystone wants to keep control over the interaction with customers.

Feedback Phase. The partners would like to receive as much information on their customers as possible even if the data is collected by another partner. However, they are disinclined to share their data with competitors within the ecosystem but would be willing to do so with collaborative partners. On the other hand, the keystone perceives it as low priority to provide an infrastructure for sharing data across the ecosystem. This leads to conflicts concerning the exchange of data and the required infrastructure (#8) to do so.

Lastly, and related to the previous conflict, the handling and forwarding of customer feedback (#9) concerning other partners or the keystone also constitutes certain challenges since the partners only benefit from forwarding feedback if it is directly connected to the partners’ apps or services. However, the keystone relies on the partners to forward platform-related requirements of their customers to them. Additionally, one interviewee explains that “feedback from customer visits are a tricky thing because the POs are going to the visits and we have a process described on how to feed back the feedback to the organization and also to me but that is still a little bit... some use it, some don’t and some you have to chase to get their feedback for their customer” which is why they “need to turn that into a more automated, also tool-automated, process flow”.

4.3 Challenges

Based on the previously extracted conflicting interests, all ecosystem related challenges faced by either the keystone or the partners were extracted out of the interviews. For each challenge we identified the following properties: The ecosystem’s maturity, the phase within the agile lifecycle, other influencing factors, and causes for the respective challenge. Table 3 shows an overview of the detected challenges. In a next step, we mapped the challenges into a multi-dimensional model (see Fig. 4). The two main dimensions are the phases within the agile lifecycle (planning, value prioritization, and feedback) and the degree of maturity of the ecosystems. We added an extra dimension, the openness of the ecosystem, to each of the phases of the agile lifecycle because we identified challenges within these phases that were also strongly influenced by this factor. We identified two types of partners: partners that are closely coupled to or guided by the keystone and partners that are only loosely coupled to the keystone. Challenges between actors may be effective only in one or in both directions (arrows with one vs. two heads in Fig. 4). The power balance can be even or be dominated by one actor (indicated by a square or by triangles respectively).

Planning Phase. The first challenge results out of conflict #1 concerning the development of basis or new platform functionalities. The partners sometimes feel like the keystone is not sufficiently responsive and takes too long to deliver needed functionalities while the keystone receives too many requests over a lot of different channels which makes it difficult to respond to or handle the requests in a decent amount of time, as one interviewee explains “we keep on getting requests from everywhere [...] not everything can be taken up at the same time”. The challenge is to achieve the right request responsivity (#1). Among others, this is caused by missing or not well established processes to handle such requests which, again, leads to many different communication channels.

Furthermore, both cases in our study perceived an appropriate communication of topics and deliverables (#2) between platform and partners as quite difficult as a result to conflict #2. The partners reveal that they would appreciate more transparency on the keystone’s side in order to get a clear picture of what is possible to achieve. If this is not well communicated, this lack of transparency easily leads to a lack of trust. On the other hand, the keystone explains that they mostly receive high level user stories from their partners which have a high potential for being misinterpreted by the product manager who has to refine the user stories. Possible causes for this challenge are long communication paths across multiple stakeholders often implying information loss, and the fact that it is impossible for product managers to have expertise in all of the partners’ areas which easily leads to misunderstandings, especially since the partner offering are “operating in a very specific domain which makes it difficult for most people to understand the topics”.

Another challenge, closely coupled to closed ecosystems and related to conflict #3, is to obtain a broad picture of the end-customers (#3) due to keystone guidelines. In case partners and the keystone are very tightly coupled, partners who talk to customers are perceived as representatives of the entire ecosystem. For this reason, the platform wants to ensure an congruent representation of the ecosystem in front of the customers. In the particular case, the keystone has collaboration agreements with certain customers and the partners get instructions which partners they should talk to. However, this keeps the partners from getting a broad overview over all customers.

Value Prioritization Phase. As a result to conflict #4, it is challenging to achieve alignment of roadmaps and prioritizations (#4) as the actors within an ecosystem simply do not share a common business interest. This makes it difficult for the keystone to consider all partners and decide what brings the most value to the ecosystem. One of the partners states that “it is challenging because the keystone has its own roadmap, its own prioritizations and this can cause conflicts if the priorities or values do not match”.

Quite the contrary to the previous challenge and related to conflict #5, this challenge addresses the difficulty of handling different power relations (#5) within the ecosystem. The partners feel like the keystone gives preferences to certain “important” customers and neglects the “less important” customers. One interviewee explains that he feels like “it depends on which partner has the greatest business potential”. However, the keystone is simply not able to treat all partners with the same amount of attention because “[the partners] are always creating pressure” in order to get their requests preferred which naturally leads to the questions how to decide which partners are more important.

Conflict #6 concerning the amount of transparency by the keystone leads to an insufficient communication of prioritizations (#6), e.g. concerning the keystone’s next steps, which causes displeasure on the partners’ side. At the same time, the keystone faces the challenge how to handle the trade-off between pleasing partners and maintaining its flexibility.

As a result of challenge #3 and related to conflict #7, we observed that – due to the divergent viewpoints concerning the partners independence and the keystone’s control – the partners face the challenge of obtaining a broad picture over all their customers (#7). The reason is that they are unable to include all their customers in their prioritization process due to the keystone’s limitations concerning the customer communication. One of the interviewees even states that “It would be much better to run more statistics because I don’t feel like this is a comprehensive picture”.

Feedback Phase. Some of the interviewees reported on their interest in collecting and sharing customer data with certain collaborative stakeholders (conflict #8), however, so far there exist no established processes for software ecosystems to do so. The interviewees explain that they “would rather have direct feedback channels” or “centralized ways to store and access feedback” because off-the-shelf infrastructure can usually not be used for such kind of data sharing since fine-grained access to the data is not easy to control and legal or privacy issues need to be addressed. As a result, this leads to information loss and one-sided feedback. Therefore, the challenge is to establish processes to collect and exchange data (#8).

Lastly, both of our cases perceive the communication across stakeholders as insufficient and are under the impression that a lot of information gets altered or lost due to the (mis-)communication across multiple partners. This results in the challenge of an appropriate communication and avoidance of information loss and altering (#9). One of the interviewees revealed that the keystone does not immediately communicate malfunctioning platform features that the partners’ features rely on to them because high priority communication channels for incident reporting in software ecosystems would need to be established first. On the other hand, the keystone suffers from limited amount of customer feedback and information loss since the chances for alterations are very high due to the long communication paths. One interviewee reports that “the more people you involve in between the more information gets lost”. Moreover, the feedback from end-customers concerning platform features are often communicated via the partners. Especially in open ecosystems the keystone often does not have direct customer contact. This makes it challenging for the keystone to receive information on and to understand the real customer’s needs.

5 Related Work

Previous research suggests that the application of agile practices is more difficult in large projects or organizations than in small teams [25]. As an organization grows it becomes challenging to keep an overview of all projects and groups within one organization [26]. Additionally, if the activities between them are not well communicated, it is hard to keep track of the existing dependencies. These factors often result in coordination challenges and additional coordination efforts [9, 27]. For instance, an overarching figure or role, as well as appropriate methods, are required to coordinate the teams and address team-crossing challenges [11]. However, inter-team coordination in software ecosystems rises additional complications as the teams are distributed over several organizations who rarely share common goals or strategies nor a centralized control figure who coordinates them.

Moreover, it has been observed that an increased autonomy enabled by agile practices causes individual teams within a mutual organization to prioritize their own goals over the larger context [27]. Knowledge regarding the system is spread across the distributed teams and processes to share that knowledge need to be established [28, 29]. Additionally, a global distribution of teams leads, among other challenges, to “reduced feelings of proximity when telecommunication is necessary, and difficulty in arranging frequent meetings due to time zone differences” [27].

Previous studies by Dingsøyr et al. [6] and Stettina et al. [30] indicate that most issues identified in agile large-scale software projects are related to processes as well as the people and their relationships. We observed quite similar results in our case study. Nevertheless, our results differ from the challenges of distributed agile teams in the way that the interactions between teams of a single organization are quite different to the interactions across organizations. In the latter case, single parties do not necessarily share a mutual larger context or even a common business interest which also impedes the sharing of knowledge. Moreover, the individual teams do neither apply or utilize unified processes nor can they be forced to do so since a central control figure does not exist in this context.

In order to improve the lack of visibility in large-scale projects, methods and solutions such as agile portfolio management, reporting or inter-team retrospectives have been introduced to connect the business strategy and the respective teams, to get an overview of all initiatives within a portfolio, and to address inter-team coordination challenges [6, 10]. However, it has not been investigated yet how such practices could be applied across organizational boundaries. For instance, some actors can be reluctant to share their reports with certain other actors. Therefore, practices or guidelines would need to be established to coordinate the distribution of reports or to enable inter-organization retrospectives.

The complexity of (inter-)team coordination tends to increase with the size of the project and the number of teams involved (e.g. in multiteam systems). A shared mental model (e.g. concerning the work process, tasks, or awareness of who knows what), closed-loop communication, and trust are considered mechanisms that facilitate the coordination of multiple teams. Bjørnson et al. [7] investigated the practices that can be applied in order to implement these mechanisms. They identified, among others, formal as well as informal communication channels, specialized roles that rotate between teams, stand-up meetings, mini demos, and discussions in an open workspace as helpful tools to implement the mechanisms. In their case study, all teams are located in the same office and many of the proposed practices rely on the co-location of the teams, or at least on a shared common business interest and willingness to exchange information. These characteristics can usually not be observed in software ecosystems which makes it challenging to adapt these practices and mechanisms in this context.

Scheerer et al. [31] investigated different types of coordination strategies for multiteam systems. Each of their strategy types comprises three coordination types – mechanic (e.g. plans, rules), organic (e.g. mutual adjustment, feedback), and cognitive (e.g. cognitive similarity configurations) – that are applied to different kinds of extents, e.g. low, medium, or high. This work specifically focuses on multiteams that work on the same software product and while each team works toward an individual goal, they still share, at least to some extent, a mutual collective goal [31]. Rolling out a unified coordination strategy ecosystem-wide is very difficult to enforce since it would affect teams across several organizations, each of them pursuing their own goals and applying their own practices, without sharing a central control figure.

6 Conclusion

The research objective of our study was to elaborate the arising coordination challenges of agile teams within software ecosystems. Our findings indicate that many of the identified coordination challenges are either directly or indirectly related to long communication paths and a lack of well established communication processes, especially if information needs to be shared with other actors across organization boundaries. In contrast to distributed teams within one company, this is additionally challenging because of the varying, sometimes even competitive, relationships that influence the communication and the way data is forwarded or shared. For one, our participants perceived the responsivity as very slow and insufficient. Moreover, the deficient communication structures cause a lack of awareness and understanding of topics, deliverables and timelines between the keystone and its partners. The keystone is rather cautious when it comes to revealing its prioritizations and plans for the future which causes frustration on the partners’ side. In addition to that, our results imply that on many occasions information gets lost or altered due to the multiple hops it has to pass. Our research provides evidence that there is a need to adapt or develop agile processes to facilitate and enable across-organization communication, coordination, and exchange of data.

Therefore, future work could be dedicated to solving the identified challenges and to investigate how agile practices would need to be adapted in order to fit across-organizational needs.