1 Introduction

Coordination is key to large-scale agile software development projects [4, 6]. In large-scale agile projects, the number of interdependencies requires the collective input of multiple teams and individuals, often with nonoverlapping knowledge sets. Because of frequent changes, size, and complexity, large-scale agile projects have a high level of uncertainty. In such high uncertainty contexts, it is more important to control output (e.g., by setting goals and targets) than to control behavior (e.g., through rules and programs). This can be achieved by relying on continuous feedback and mutual adjustment [20]. Furthermore, the high levels of uncertainty and dependencies in large agile projects require subcentral unscheduled coordination and the need for coordination mechanisms to continually emerge [22]. Additionally, delivering value frequently requires work and knowledge coordination on different levels (e.g., the program, project, and team levels). Teams need to manage dependencies with other teams, experts, managers and stakeholders [26]. To achieve effective coordination, participants must be connected through relationships of shared goals, knowledge and mutual respect [12, 13].

Inter-team coordination is one mechanism for managing dependencies in large-scale agile. Dingsøyr et al. [6] described 14 inter-team coordination mechanisms in a large-scale software project, while Stray et al. [28] identified 20 mechanisms (11 synchronization activities and nine synchronization artifacts). Paasivaara et al. [24] found that the product owner (PO) and the PO team were critical in assisting with inter-team coordination. To understand coordination in large-scale agile, the PO role and the coordination mechanisms related to this role are crucial to understand. To the best of our knowledge, the existing literature does not address how POs coordinate work within and across teams in large-scale agile.

Motivated by the importance of coordination in large-scale agile and the need to understand the coordination in PO teams, our research question is as follows: How do product owners coordinate work in large-scale agile?

The study was conducted in a large-scale software development program, here referred to as the PubTrans program, where 13 development teams work toward the same overall goals. Here, the teams rely on agile methods of choice. Some use a Scrum-based approach, while others use Kanban or some combination of agile practices. As such, there is no one unified agile approach across the teams. Furthermore, while POs coordinate with a range of stakeholders, our focus in this paper is on how POs coordinate with each other and with their teams. The remainder of the paper is organized as follows. Section 2 outlines related work. In Sect. 3, we describe our research methodology. In Sect. 4, we present our findings, further discussed in Sect. 5 which also concludes the paper with a summary of major findings.

2 Background and Related Work

2.1 The Product Owner Role in Large-Scale Agile

Agile approaches focus on self-management, emergent processes, and informal coordinating mechanisms. The software team achieves coordination through the simple process of informal communication [8]. Large-scale projects, defined as projects with two to nine teams, or very large-scale projects, with more than 10 teams, introduce the need for new or adjusted agile practices [6]. When scaling up, several challenges arise, such as managing a larger number of stakeholders, keeping to the agile principles and coordinating the different teams while maintaining an informal approach to communication [4,5,6, 8]. In large software projects, informal communication can take place within teams, between groups of managers, or between groups of representatives acting on behalf of their teams.

Most agile methods are concerned with good customer relationships, where the customer should be involved, preferably on-site and co-located with the development teams and project management [1, 19]. In Scrum, the PO is defined as a person who gathers and prioritizes requirements and interacts with the customer [25]. In other agile approaches, such as Kanban and XP, the role is not defined [19], but similar activities are performed. In the PubTrans program, in which we conducted the study, the PO role is used, although the program does not use Scrum as the only agile approach. A PO needs to understand what should be developed and translate and communicate these business needs to the development team [1, 19]. The PO defines and prioritizes the features of the product, decides on release dates and content, and is responsible for the profitability of the product [29]. The development team is responsible for designing, testing, and deploying systems, while the PO knows what system should be built.

In large-scale agile, one strategy for scaling the PO function is for the POs to form teams to gather and prioritize inter-team requirements in the face of conflicting and competing business needs [1]. The POs on these teams can either share responsibility or be responsible for a subset of product features [24]. Bass [1] identified nine different functions that POs have in large-scale projects, which included architectural coordination, assessing risk, and ensuring project compliance with corporate guidelines and policies. As such, the PO role is a complex role with a broad set of responsibilities, which in large-scale settings may need to coordinate complex, interdependent tasks and team goals contributing to the overall goals of the software project.

2.2 Relational Coordination Theory

Relational Coordination Theory (RCT) is an established and empirically validated theory that originated from research conducted in the airline industry in the 1990s [12]. RCT holds that relationships are central to coordination toward common outcomes. An assumption is that relational coordination is stronger in more horizontally designed organizational structures [14], which is important to large-scale agile [7, 23].

Relational coordination is defined as “a mutually reinforcing process of interaction between communication and relationships carried out for the purpose of task integration” [13]. Gittell [12] proposed that relationships provide the necessary bandwidth for coordinating highly interdependent work in uncertain and time-constrained settings and that effective coordination in these settings is carried out through relationships of shared knowledge, shared goals, mutual respect, and high-quality communication, described in the below sections. These three concepts are mutually facilitated by frequent, timely, accurate and problem-solving communication [11, 12]. Because large-scale agile projects are characterized by high levels of interdependence, uncertainty, and time pressure, and because autonomy is a central tenet in agile [4], we believe RCT is an interesting theoretical lens for studying coordination in large-scale agile.

Shared knowledge informs participants of how their tasks, as well as the tasks of others, contribute to the overall work process [12]. However, individuals and groups working on different functional tasks often reside in different “thought worlds”, which can hamper effective coordination because of the lack of insight about others’ work [9]. Drawing on sensemaking theory [32] and transactive memory theory [18], RCT suggests that a shared understanding of the work process and a common understanding of each other’s areas of expertise across roles facilitate the coordination of knowledge [12]. When participants know how their tasks fit with other tasks in the work process, they will better understand who will be impacted by changes; in other words, they will understand who needs to know what, why, and when [11].

In large-scale system development, no one can know everything. Therefore, teams’ and peoples’ knowledge networks are essential. Šmite et al. [26] found the size of teams’ knowledge networks in a large-scale agile company to be dependent on the number of years the individual team members had been at the company, in addition to which forums the individual participated in.

Shared Goals.

A goal may be seen as shared to the extent that employees across functional areas are aware of the same goals and have a similar understanding of why they are important [12]. Thus, they play an essential role in effective coordination by enabling people to accomplish a set of complex interdependent tasks [30, 31], a common characteristic in large-scale development projects, where autonomous teams work on different parts of an overall product.

In large-scale agile, the collective goal of the project or program can be broken down into a goal hierarchy. The goal hierarchy is important for teams in large-scale agile to share a distal goal while the individual teams pursue their more proximal goals. Nyrud and Stray [23] found that the demo meeting and backlog grooming were essential in this context because they provided an arena for creating common expectations and understanding the finished product – shared goals within and outside of the team. Moe et al. [21] found that when managers set goals in a large-scale project without involving the team, it resulted in team members being uncertain about the goal of the project.

Mutual Respect.

Finally, for effective coordination to occur, employees should be connected by relationships of mutual respect between the coordinating parties. According to RCT, mutual respect reinforces the inclination to act in accordance with the overall work process by establishing a middle ground [12].

A study of large-scale Scrum found that responding respectfully to each other fostered psychology safety, which is important for agile teams [27]. In a study of a large-scale project Moe et al. [21] found that external stakeholders approached team members directly, despite members expressing that it disrupts the work. Bypassing the established process reduced team progress.

High-Quality Communication.

According to RCT, shared knowledge, shared goals and mutual respect should mutually reinforce high-quality (that is, frequent, accurate, timely and problem-solving) communication [10,11,12]. This should, according to RCT, contribute to the overall quality of the coordination of the work process.

A survey on coordination in large-scale software teams found the importance of good personal relationships for coordination [2]. Dingsøyr et al. [6] found the importance of communication in large-scale agile to be both informal and formal, happening both in groups and by two people meeting. Furthermore, they found that an open work area supported fast communication in informal meetings. In relation to RCT, an open work environment enables high-quality communication, building shared goals, shared knowledge, and mutual respect in large projects.

3 Method

We chose a case study approach [33], because case studies provide depth and detailed knowledge, and there is little research-based knowledge about how POs coordinate work in large-scale agile. We selected a case in which almost the whole development program was co-located in order to reduce the effects due to the distribution of teams. In the following, we refer to the case as the PubTrans program. The program started in 2016 and aims to develop a new platform supporting public transportation. The first author conducted fieldwork at the program and was given access to rich sources of data, including meetings, SlackFootnote 1 channels and documentation tools. In addition, the two other authors participated in site visits, workshops, and in two of the interviews.

3.1 Case Description

The PubTrans program has thirteen development teams ranging between five and fourteen team members working toward developing the same products. Each team is responsible for their part of the overall products. The PubTrans program can thus be classified as very large-scale agile [6]. In order to coordinate work within and across teams the program makes use of various electronic tools, such as Slack, Jira, and Confluence; material artefacts such as task boards; and various scheduled and unscheduled meetings. The development teams are autonomous to the extent that they may choose freely how they go about solving their tasks and rely on agile methods of choice. As such, there is no one unified agile approach across the teams. All teams include a team leader and a PO, but there is no defined Scrum Master role or any other roles specific to any one agile method. The POs are situated within each team and are considered part of the development teams in the PubTrans program. Seven of the POs have one team, whereas two have three teams each. The POs have varied backgrounds; some have a technical (e.g., engineering) background and have been working in the product domain for several years, while others came from industries such as marketing and business development.

3.2 Data Collection

We conducted twelve interviews in October 2018. The interviews were semi-structured, and we allowed the conversations to develop naturally as the participants unfolded their stories. The duration of the interviews was between 30 and 60 min (average of 40 min). All interviews were tape-recorded based on participants’ consent and were later transcribed by the first author. We spent a total of eighteen days with on-site observation and participated in several PubTrans activities, described in Table 2.

3.3 Data Analysis

When analyzing the data material, we relied on data triangulation, including observation, interviews, and documentation as data sources (see Table 2). Our rationale for the choice of these data sources for the study of PO coordination was that by interviewing the participants, we gained access to their own understanding of their work routines. Analyzing the observations and documentation such as Slack logs shed light on the accounts given by the interviewees and provided context to their statements. As such, data triangulation was likely to contribute to strengthening our findings and conclusions through increased accuracy and compellability [33].

Through our engagement with the data, RCT emerged as an appropriate lens for examining PO coordination in a large-scale agile setting. This is because RCT is a suitable theory for organizational contexts characterized by high levels of interdependence, outcome uncertainty, and time criticality [11, 12] typical in large-scale development. We coded the data using Nvivo according to the coordination mechanisms used by the POs (Table 3) and how these mechanisms related to the RCT concepts defined in Table 1. The coding process proceeded as follows: First, all three authors coded parts of the material. Second, the authors discussed the material, resolving any disagreements. Third, the first author coded the material in more detail, followed by a second discussion of the analysis and results.

Table 1. Elements of relational coordination based on the synthesis by Gittell [12].
Full size table
Table 2. Data sources
Full size table

4 Results

Table 3 shows the main coordination mechanisms involving the POs. These were identified based on documentation of work routines from the PubTrans program, the interviews, and the authors’ on-site observations. In the following, we describe a selection of these coordination mechanisms in relation to the relational coordination concepts of shared goals, shared knowledge, mutual respect, and high-quality communication.

Table 3. Product owner coordination mechanisms
Full size table

4.1 Coordination Between POs

The weekly PO coordination meeting, facilitated by the product manager, enabled discussions on shared experiences and matters that came up during the previous week. For instance, POs discussed challenges with team processes or updated each other on external client issues. Having a weekly meeting contributed to communication that was problem-solving, accurate, and frequent. However, its content seemed to vary. One PO told us, “There is no fixed, no defined agenda. We are supposed to talk about what is on our mind, and that is a very open question! [laughs]. It can be anything. So I think there have been some meetings that we have not gained so much from.” The POs expressed different opinions regarding this weekly meeting. Some POs thought it was very useful, in particular for building shared knowledge and goals. Some thought that once a week was too frequent, because they wanted to spend more time with their team, whereas others felt there should have been more PO meetings like this because “we don’t have any places to meet to exchange experiences across teams, other than these Product Owner meetings.” As such the meeting appeared to be an important coordination mechanism in relation to shared knowledge and goals.

The bi-weekly task board meeting gathered the POs and relevant stakeholders. The meeting was typically facilitated by the product manager, CTO, or program management. All met in front of a large visual task board (Fig. 1) to update each other on their progress – current in-progress tasks and long-term delivery milestones. As such, this artefact provided all POs with shared knowledge of current goals and the status of the teams’ various tasks.

Fig. 1.
figure 1

The PO task board meeting.

Full size image

The task board meeting was initially termed the “prioritization meeting,” but according to the participants, this meeting did not meet its purpose. Rather than focusing on task prioritization, it was more of a reporting and updating meeting in which all POs simply reported on their teams’ progress, and many talked for several minutes about their teams’ internal tasks. Until recently, the meeting lasted one hour, and we observed how the POs struggled to pay attention to what others were saying as time went by. One PO said, “If we compare hours spent [at this meeting] versus insights gained, it doesn’t add up.” Across several meetings, we observed that several sat down on the floor after a while, and some started looking at their phones, responding to messages and e-mails, rather than listening. During the interviews, some said that they felt bad for being disrespectful when they did not pay attention. Most of them, however, perceived the intention behind the meeting – updating each other on progress across teams – as useful and therefore wanted to keep the having meeting, but in a different format.

Unscheduled coordination between POs was common and was done just by walking over to each other in the open office environment. One PO explained, “I seek out people at their desks… It is something about it, one thing is to communicate in writing [e.g., sending an email], but in my experience, you accomplish more by just talking to people.” Sometimes a PO would also call a spontaneous meeting, inviting only those that needed to be part of the particular coordination activity.

Moreover, the POs have a dedicated Slack channel, created in March 2018, for knowledge sharing and quick updates regarding the goal attainment of the different POs’ teams. During the interviews and from examining the Slack logs, it became clear that this channel was used to varying degrees by the different POs. Primarily, it was used for frequent and timely information updates, such as notifying each other of absence, or uploading documents such as plans and presentations, rather than for knowledge sharing and ensuring the attainment of shared goal across teams. For instance, one particular day in September 2018, two POs discussed whether to hold the weekly PO meeting:

  • PO 1: “Does this mean you will not be here today either @PO 3? [PO 4] said he too would be absent today, and so is [the Product Manager], and when there is so few of us, is there a point in going through the things we agreed all of us should be part of? Should we skip the meeting?”

  • PO 2: “I’d like to meet those of you who are present, but we can postpone the planned common PO discussion theme”

  • PO 1: “We’ll meet as planned then.”

The POs also use the Slack channel more informally. During a PO workshop, one posted, “This is the smallest hotel room I ever saw! You’ll find me in the bar.” This social and informal communication may indicate mutual respect and a sense of community among the POs, a mutual respect that is perhaps reinforced by the coordination activities they perform throughout the year.

The PO quarterly workshop gathers the POs normally overnight at an off-site location. Prior to these quarterly workshops, all POs attend a set of preparation meetings with the product manager. This is done to gain a sense of shared goals and knowledge before the workshop in order to work more efficiently together. As such, the quarterly workshop contributes to both shared knowledge and shared goals between POs at an overall program level, but it may also reinforce mutual respect between the POs as they get to know each other better. As stated by one of the POs, “It is… both professionally useful, but it’s also about getting together. It is rather social, actually.” The topics of the workshops depend on upcoming issues in the PubTrans program, for instance, discussing the potential implications of overall program strategies in relation to specific team and cross-team deliveries in the upcoming quarter. Another theme could be improving their own work processes, such as inter-team coordination.

In late fall 2018, two of the authors joined the POs for one such workshop with the product manager and eight of the nine POs. At this workshop, we facilitated a retrospective with the POs focusing on coordination efficiency. One outcome of this retrospective was four action points they believed would improve the coordination. First, in relation to the quarterly PO workshop, some POs expressed that they would prefer if the workshops were one full workday, with no overnight stay, as some felt it took up too much time. This led to some discussion, but eventually, although other POs appreciated the change of scenery, they agreed to try the next workshop as a one-day workshop. This demonstrates that although the POs do not always agree or have the same preferences, they are willing to adjust to each other, which may indicate mutual respect.

A second action point was to move all written communication to Slack rather than use it as a supplement to e-mail. After the workshop, we observed a change in the communication in the dedicated PO Slack channel. Communication in the channel became more frequent and contributed more toward shared goals and knowledge among the POs. For instance, the POs started to share “best practice” tips and work routines on Slack, as well as agenda points for the weekly PO meeting. A third action point was to increase the focus on a clearer agenda for the weekly PO meeting. As such, the communication at this meeting might have become more accurate, which in turn contributed to reinforcing shared knowledge and goals. Finally, the fourth action point was to reduce the length of the task board meeting from one hour to 20 min and to focus only on updates relevant for at least two thirds of the attendants. In the following three meetings, we observed that the new format led to communication that was more accurate and timely.

4.2 Coordination Between POs and Their Teams

We found differences in how the POs coordinate with their teams. Some POs have well-established practices and close, regular interaction with the team, while others have a more loosely defined approach with a high level of delegation. Regardless of their level of interaction with their team(s), the POs aim to communicate the vision and priorities for the teams’ work such that all team members share knowledge about the team’s own goal, as well as an understanding about other teams’ work.

Coordination with the team leader was a key process for most POs. Several POs spoke respectfully about their team leaders, seeing them as having both good people skills and good technical skills. The POs described the team leader as an essential link for coordination with the team, who often joined the POs in the decision-making. One PO explained, “We go through all priorities together. […] we are rarely in disagreement. And if there is… it could, for instance, be that I have knowledge from the business side that calls for different priorities, then I make the decision, but normally we agree.”

During a team retrospective, several team members expressed the importance of the PO and the team leader in shielding the team from external pressure and in making sure they knew which tasks to work on. This may indicate both the importance of these roles in relation to shared knowledge and what many POs found important: respect for the developers’ time and their role in the overall goal attainment.

Stand-up meetings with the team varied in frequency. Some teams had stand-up meetings every day, others once or twice a week, and some on a more ad hoc basis, for instance through sharing task-related information on team Slack channels. The stand-up meeting was an important meeting for sharing knowledge and solving issues. A PO explained the challenge of just listening and then being an active participant in the meeting: “I want to be part of the stand-ups, as I want to pay attention to what they are doing […] but then they expect me to say something, and I feel that I have to, otherwise it is all ‘top-down.’” He further explained that he wanted to listen and learn from the team, but at the same time, he was not sure what he could bring to the meeting because he saw his work tasks as very different from the team’s and did not find it relevant to talk about those tasks.

Retrospectives with the team varied in frequency and process. When the team members got together to discuss their work during the previous period, the meeting contributed to strengthening shared knowledge about the teamwork processes and shared team goals in that the teams analyzed, discussed, and adjusted their own practices. Mutual respect among the participants might also have been strengthened as they shared their thoughts and perspectives. Many POs left it up to the team leader to facilitate team retrospectives, while some took a more active role.

Furthermore, the retrospectives provided important information as to how the POs could adjust their coordination practices toward the team. One PO explained, “I thought me and the team leader were good at bringing information back to the developers. As it turned out during our last retrospective…we were not! And we are going to do something about that.” This illustrates the importance of conducting retrospectives so that the team can mutually adjust to better accommodate each other. The willingness to adjust based on feedback may also indicate respect toward the team members through acknowledging the impact a lack of information could have on their work.

Unscheduled coordination with the team appeared important for fast decision-making. Much of the coordination with the team occurred during spontaneous conversations and meetings, and many decisions at the team level were made during such unscheduled conversations. According to one PO, “If there are decisions to be made in relation to choice of technology or similar, normally it would be me, the team leader and some developer… we just decide then and there […].” This illustrates how shared knowledge about decisions are reached through accurate, timely, problem-solving communication.

Slack was also extensively used among the teams in the PubTrans program; almost all teams appeared to have closed private channels where the whole team, including the PO, discussed internal matters. In addition, there was a range of public channels for different topics. While Slack was seen as an invaluable source of knowledge and information, for some it became overwhelming. One PO of three teams explained, “I spent some time adjusting from e-mail to Slack. […] There are so many channels! It is so much to pay attention to and read, it can actually be a bit too much.” The same PO further explained that Slack was not used for making larger decisions, but that overall, Slack was a great place to keep the discussion going on technical issues and everyday work-related matters.

5 Discussion and Conclusion

The PO has an important role in agile development, often performing a complex set of activities [1, 19]. Our findings underscore the importance of relationships for efficient coordination among POs and between the PO and the team. We have attempted to shed light on PO coordination through the concepts of RCT. We now turn to discussing our research question, “How do product owners coordinate work in agile?” Our analysis of PO coordination in a large-scale agile development company shows that (1) coordination varies depending on the context of each PO (type of team, experience, preferences), (2) a focus on high-quality communication changes coordination over time, and (3) unscheduled coordination enables high-quality communication.

5.1 Coordination Practices Varies Between the POs

During our observations and in the interviews, we noticed several differences in PO coordination both among each other and toward their teams. This may be due to differences in coordination preferences among the POs, as well as the number of teams a PO is responsible for. It may also be due to the autonomy the teams have in choosing their approach to agile methods leading to a variety in coordination mechanisms between the POs and their teams. The differences in routines on each team may have made it more challenging to coordinate across teams and between POs, and to ensure a shared understanding of goals among the POs and across and the different teams.

High-quality communication reinforces shared goals and knowledge [12,13,14]. The POs communicating frequently with their teams and with other POs, experienced such coordination to be beneficial, which then lead to even more frequent communication. Furthermore, how long the POs had known the teams and each other varied, which also might influence how frequent a PO communicate with other POs and their teams. In relation to this, Šmite et al. [26] found that the frequency of communication and the number of actors a person coordinated with depended on how long the person had been at the company. The longer the experience, the more frequent the communication, which indicates that coordination becomes more accurate because of knowledge about who knows what [26].

5.2 Changes in Coordination Over Time

Several of the coordination mechanisms involving the POs, such as the task board meeting and Slack communication, changed during the period of the study. Our findings are consistent with those of Jarzabkowski et al. [15], who argued that coordinating mechanisms do not appear as ready-to-use techniques but are formed as actors go about the process of coordinating. Furthermore, coordinating mechanisms are not stable entities but emerge through their use in ongoing interactions [15].

Throughout our data collection period, the main driver for change in a coordination mechanism was the focus on continuous improvement. During the retrospective, several action points were set, and we observed how coordination mechanisms were improved; for example, the task board meeting, was improved by more timely and accurate communication in that the meeting became shorter and more focused. We also observed a change in the PO Slack channel toward more frequent and problem-solving communication, for instance by using the channel to share agenda points for meetings and best practices from teams.

5.3 Unscheduled and Frequent Coordination Enables High-Quality Communication

As a supplement to the scheduled meetings, we found that unscheduled meetings appeared to be an important driver of high-quality communication in the PubTrans program for coordination on a daily basis. Our results indicate that unscheduled meetings and seeking out people at their desks are important for efficient day-to-day coordination. We also found that the use of Slack enabled timely, frequent, and unscheduled coordination between subsets of people, such as between the POs or within teams. As such, our results indicate that standardizing the communication channels on one digital platform contributes to shared knowledge across POs and teams.

Unscheduled conversations and meetings contribute to strengthening the shared knowledge and goals and can be seen as timely and problem-solving communication, in particular when only a subset of the POs needs to coordinate. In line with our findings, previous research supports the importance of both formal and informal communication, both in groups and by two people meeting, and that an open work area in large-scale agile supports fast communication in informal meetings [6].

5.4 Implications for Theory and Future Research

As can be derived from our results and this discussion, the elements of RCT are evident in the coordination mechanisms used by the POs in the PubTrans program. The theory, therefore, appears suitable for studying coordination in a large-scale agile setting. According to RCT, organizational change is seen as intertwined with the relationships between roles. Research that explores organizational change to further develop the theory has been encouraged [11]. Furthermore, according to RCT, relationships between roles are central for coordination [11,12,13]. In her work on the airline and health industries, which also represent large-scale settings, Gittell [12, 13] observed that the companies that performed best had higher levels of relational coordination between roles, which was explained by the differences between the studied companies in terms of shared knowledge, goals and mutual respect. In line with this, our results indicate that frequent communication and interaction between POs is important for coordination, also in the PubTrans program. Furthermore, our results indicate that coordination between the PO role and the team leader role is key for high-quality communication, knowledge sharing, and updates about goal attainment with the teams. While this study contributes to the understanding of PO coordination, this study is the first to utilize RCT in large-scale agile for understanding PO coordination. Therefore, more studies from other programs are needed to make comparisons between large-scale agile programs.

Future research could also investigate whether the number of teams for which the POs are responsible influences their coordination practices. It might be that the more teams, the more coordination is needed on each PO’s part. Finally, while POs coordinate with a range of stakeholders, including customer representatives, management, and architects, our focus in this paper was on how POs coordinate with each other and with their teams. An interesting topic for future research would thus be to expand the focus to investigate how POs coordinate their work with other stakeholders.

5.5 Implications for Practice

We believe that our study has the following main implications for PO coordination. First, we recommend focusing more on unscheduled meetings rather than scheduled, time-consuming meetings, as also suggested by other research on large-scale agile [22, 28]. Established frameworks such as the Scaled Agile Framework and Large-Scale Scrum recommend a rather fixed meeting structure [16, 17]. In contrast, our results indicate that unscheduled meetings are important enablers of spontaneous coordination that contribute to shared goals, shared knowledge and mutual respect in large-scale agile. Such meetings are facilitated by open work spaces and co-located teams [6]. Second, we recommend agreeing on a common communication infrastructure, such as Slack, for swift communication and information sharing, but also for the POs to have their own space where they can discuss outside of the scheduled meeting arenas. Third, frequent meetings and workshops in which POs can discuss goals and share knowledge are necessary. However, such meetings should have a clear, predefined agenda to ensure efficient use of time and resources. Fourth, scheduled workshops throughout the year contribute to forming social bonds between the POs supporting relational coordination. Finally, we advise regular retrospectives focusing on improving coordination, strengthening shared knowledge and goals, and reinforcing mutual respect and trust within the PO group.

5.6 Limitations and Concluding Remarks

One limitation of our research is the reliance on a single case. As such, the general criticisms of single-case studies [3, 33] apply to our study. However, our rationale for choosing the PubTrans program as our case was that it represents a setting in which large-scale agile has been applied since the outset of the program in 2016. Furthermore, because the program is largely co-located and the POs are considered part of the teams, the case provided a unique setting for exploring how POs coordinate in large-scale agile settings. A further limitation relates to the reliance on semi-structured interviews as a major source of data collection and analysis [3]. However, data triangulation made it possible to study the phenomena of interest from different viewpoints, as well as during the changes we observed, which should serve to strengthen our results [33]. We facilitated a PO retrospective in which concrete action points were formed, indicating that we did affect how work processes are conducted in the PubTrans program, at least for the time being. However, the PubTrans program already had a high awareness of challenges with inter-team coordination before we started our research. Therefore, we do not believe our presence has biased the results.

On a concluding note, in this paper, we applied a relational coordination lens to the question of how POs coordinate work in large-scale agile system development. Our findings suggest that the PO contributes to shared knowledge and goals both within and across teams, and that efficient coordination also includes relationships of mutual respect and high-quality communication. This is in line with previous findings from research using RCT; however, this study is the first to investigate relational coordination in a large-scale system development setting. As such, this study makes way for future research that can contribute both to the further development of RCT as well as improving our understanding of coordination in large-scale agile development.