Keywords

1 Introduction

While the benefits of agile are well documented, large-scale agile product development settings are characterized by challenges with delivery speed, system complexity, and decision-making efficiency between interdependent development teams [3, 4, 11]. Such challenges are caused by inter-team dependencies that restrain development speed and progress [4, 19], which requires the use of coordination mechanisms. An inter-team coordination mechanism can be defined as an organizational process, entity, or arrangement used to manage dependencies to realize a collective performance [1].

Another way to reduce complexity and mitigate the coordination challenges caused by scale, is by establishing product areas where teams that work on similar products are grouped together [16]. We understand a product area as a defined organizational structure that focuses on a particular product, or set of products related to a customer segment or business need [16]. It consists of product teams led by one or more product managers who ensure that the product meets both customer and business needs. Several product areas can operate independently within the same organization [23], which may allow for easier collaboration between interdependent teams, and reduce inefficient interfacing between unrelated teams [13, 16].

Studies conducted in recent years have focused on coordination within [32, 33, 36] and between agile teams [4, 10, 15, 22, 23] in software product development. However, despite that product management are commonly integrated with agile processes and large-scale agile frameworks [8, 23, 28], and that lack of alignment between teams and unclear dependencies are among the challenges with software product management [28], to our knowledge there is little research that specifically examine coordination in product areas. In this study we therefore investigate the following research question: “How does coordination happen in product areas in large-scale agile?”.

2 Background

2.1 Organizing Large-Scale Agile Software Development into Product Areas

Agile development methods have been dominating software development, including large-scale settings, for the last decades [14, 24]. The benefits of agile methods, such as greater team autonomy, increased delivery speed and improved product quality have been well-documented in software engineering research [24]. Nevertheless, large-scale agile is characterized by coordination challenges and complex interdependencies that can reduce development speed and quality [4, 14].

‘Large-scale’ agile can be defined as two to nine teams, whereas ‘very large-scale’ agile involves more than ten development teams [12]. Such very large-scale cases require different coordination mechanisms, for example multiple inter-team stand-up meetings and retrospective meetings [10]. These mechanisms are needed to manage the many dependencies that arise from having many teams working together [1]. Establishing product areas where teams that work on similar products are grouped together [16], is one strategy to mitigate the coordination challenges in large-scale agile. The product area concept falls under the product management discipline, where ‘the product’ is placed at the center of the business goals and success [13].

Product management is an organizational discipline where the product is placed at the center of the business goals and success [17, 28]. In recent years, the term has been re-popularized by practitioners by writers such as Marty Cagan [7], Teresa Torres [35], and Christina Wodtke [37]. A recent systematic literature review on software product management [28] reports that, similar to large-scale agile [9, 14], the main challenges with software product management include problems with communication and synchronization across teams, problems with team autonomy and level of agility, and lack of clarity with regards to product management roles, especially the product manager [28]. Product managers perform activities related to product discovery and experimentation, strategic vision and product monitoring and adjustment, but also activities such as team support and stakeholder management [13, 34]. Today, many agile software development organizations use the product manager role in combination with the product owner role, which is typically understood as a narrower role [17, 34], but the terms are also used somewhat interchangeably [28]. Additionally, frameworks such as Large-scale Scrum (LeSS), has introduced specific roles such as the Area Product Owner [23].

Neither product management nor product areas are new terms within software engineering research [5, 13], but in recent years, the term has resurged also in the agile development research literature [21, 28, 34], perhaps due the focus of delivering customer value which is shared by both traditions [17]. However, as the inter-team coordination challenges that characterize large-scale development prevails, in this paper we explore coordination in product areas to understand how this type of organizational structure can support large-scale and very large-scale agile development needs.

2.2 Frameworks for Understanding Coordination in Large-Scale Agile

To understand coordination in product areas, it is necessary to understand coordination mechanisms used between teams. Recently, a taxonomy of inter-team coordination mechanisms in large-scale agile was developed, with the three main categories: meetings, roles, and tools and artefacts, and six sub-categories (see Table 1) [1]. These categories are commonly found in large-scale agile settings [e.g., 14, 22, 27, 31, 36].

Dependency management is core to coordination in large-scale agile. In line with the taxonomy of dependencies in agile software development, we define a dependency as something that occur when something, or someone, is dependent on the output of something or someone else [33], across three main categories: Knowledge dependencies are caused by the lack of information related to requirements, expertise, task allocation, or historical information. Process dependencies stems from the insufficient completion of development, or business process, activities, that blocks progress. Finally, resource dependencies occurs when an object, be it a physical entity or a technical object, such as a piece of code, is needed for work to progress.

Table 1. The taxonomy of inter-team coordination mechanisms [1] (Color figure online).
Full size table

Dependencies require constant attention through coordination to avoid unnecessary delays and blockages that slows down progress [4, 19]. The dependency taxonomy has been adapted to the inter-team level [1,2,3] and used in several large-scale agile contexts [31, 32, 36]. To our awareness, however, neither of these theoretical approaches have been used at to study coordination in product areas.

3 Research Method

We explored our research question in a large FinTech organization [20]. We chose the case study research design because case studies can provide detailed insights to real-life settings where knowledge is limited [29], such as with product area coordination.

3.1 Case Description

The case consisted of 25 agile teams organized into several product areas. When we collected the data during early 2023, his way of organizing teams was relatively new for the organization, and they were still experimenting with the format. The product area we studied, the first of six product areas established in the organization, focused on personal banking, and had existed for about a year at the time. The product area consisted of nine teams with approximately 60 employees, where each team worked with features related to a specific product. In the FinTech organization a ‘product’ was defined as “a repeatable solution that can be offered to a market that solves a want or need” [Strategic document]. Moreover, the teams in the product area had shared overall goals, such as goals related to customer satisfaction and product area revenue. The product are teams were cross-functionally organized and consisted of developers, designers, team leaders, testers, and product managers, depending on the focus of the team. Team A-E (vertical teams in Fig. 1) worked with products such as establishing accounts and keeping overview of personal finances. Team F-G (horizontal teams in Fig. 1) worked with features that were shared by some or all the vertical products, such as bank accounts, payment solutions including credit cards, and the mobile bank app. The product area management team consisted of product managers, team leaders and representatives from development and technology, and design.

Fig. 1.
figure 1

The organization of the product area.

Full size image

In terms of agile methods, the case organization did not subscribe to any specific scaling framework with pre-defined practices and coordination mechanisms. All teams could choose their own agile practices, which allowed for flexibility in practices like sprints, stand-ups, and retrospectives, which were used at varying frequencies by the different teams. In addition, the teams used the goal-setting framework Objectives and Key Results (OKR) in combination with practices from the Radical Focus framework such as the Monday Commitments and Friday Wins meetings [37]. Furthermore, all code needed to be checked by another developer to meet national standards for the financial sector. The formal software inspection process had been replaced by a mechanism called a pull request (PR), which was used within and across teams. In this approach, a contributor creates a PR after making code changes. Next, a reviewer inspects the suggested changes to see whether they can be merged into the base branch [18].

3.2 Data Collection

We collected our data from four of the product area teams (see Table 2 for an overview).

Interviews. Semi-structured interviews provided us with insights into how the product area was organized, which dependencies existed in the product area, and how they were managed. We conducted twelve interviews, where one of them was a digital interview with two participants. The other interviews took place in the organization’s facilities. All interviews were tape-recorded based on participant consent, and then transcribed by the second and third authors. The average duration of the interviews was 50 min. We used an interview guide with questions about ways of working and inter-team collaboration such as “Can you briefly explain the purpose of the product area?” and “On which parts of the product development do you collaborate across teams?”.

Table 2. Data sources.
Full size table

Observations. We conducted field observations to gain a deeper understanding of the practices and provide additional insight to support the interviews. The observations were conducted by the second and third authors, who took notes during the meetings. We observed weekly meetings in five different teams in the product area, which allowed us to gain insight into internal team routines. Additionally, we observed an all-hands meeting (see Sect. 4.2) which provided insight into coordination across teams.

Documents. Strategic documents such as company presentations, role descriptions, and organizational blueprints, and organizational blogposts were used as supplemental data. These gave us a thorough understanding of the purpose with reorganizing the teams, as well as how the area was organized. The blogposts also contributed to enhance our comprehension of how they performed their work in the product area.

3.3 Data Analysis

The analysis was conducted by the first author, supported by the second and third authors who knew the data collection in detail, and the fourth author, an experienced qualitative researcher in the large-scale agile research field and who had been following the case for years [20]. We triangulated on the analysis by engaging in discussions about the findings to improve the credibility and dependability of our study [29].

We used coding procedures from thematic analysis [6]. Thematic analysis can be both used inductively and deductively [1, 6], and in this case our analysis was guided by existing the theoretical frameworks presented in Sect. 2.2. First, we used the taxonomy for inter-team coordination mechanisms [1] to categorize the mechanisms into meetings, roles, and tools and artefacts. Next, we analyzed which dependencies each mechanism managed using the dependency categories developed by Strode [33]. We also analyzed at which organizational level the mechanisms were used (Table 3).

4 Findings

4.1 Organizing Teams in Product Areas

Traditionally, the case organization had consisted of 25 development teams that were part of business areas that resembled a classical departmental structure. This very large-scale setting was characterized by many and varied focus areas and prioritizations, which made it difficult to deliver customer value with the desired speed and proved suboptimal in terms of aligning to resolve shared development needs: “We realized that those who worked with payment cards, and those who worked with online payment had nothing in common. Although they both conceptually work with payment, they have no shared goals, their code is dissimilar … they work with completely different products.” [I04, Product Area (PA) Manager].

As shown in Fig. 1, the teams were organized in vertical and horizontal structures. This way of organizing enabled the nine teams to better support each other and aligning the teams towards shared customer goals “The way I see it, the product area is an attempt to gather teams that are related to each other. First and foremost, by having some level of shared goals, that are connected to our customers’ everyday finances […]But it’s also about how we want to be structured, with managers, product managers, team leaders, and how they collaborate” [I02, Developer].

Working towards shared goals was described as a way of enabling dependency management: “Customer value and business opportunities are often created where structures meet, and often there are dependencies between teams. Common goals across teams can be a way to remove blockages. It might be that one team need someone else to solve something in order to progress. Then it is the product area’s responsibility […] to make way”. [I04, PA Manager]. Defining goals at the product area level was.

Table 3. Coordination mechanisms used in the product area, based on [1].
Full size table

key: “We have been able to bring them together, to get their goals aligned. We had not been able to do that with 25 teams” [I04, PA Manager].

A key feature with the vertical and horizontal team set-up was the way roles were shared across teams. Although each team had a cross-functional basis set-up with developers, product manager and team leader, not all teams had all roles. This meant that sometimes teams needed to “borrow” expertise from each other within the product area: “Sometimes the competence for testing the solutions is in a different team. So, then we need to coordinate a bit between teams if I have something that needs testing and then those who know how to test it will come and do it” [I10, Developer]. Another explained that “the designers have started to work a bit outside the team, they try to see across where they can be of help” [I06, Developer]. Additionally, there were not a one-to-one correspondence between the team leaders, product managers and the development teams, which was explained as a benefit. “We have created a flexibility in the area […] We think more in terms of capacity than in the number of heads per team. It means that it is easier to say that ‘okay, we need an additional team, you go in there as a product manager’” [I04, PA Manager].

All in all, organizing the teams that worked with personal banking in a distinct product area enabled the teams to coordinate more efficiently than when they were part of the larger 25-team structure. In the following, we describe sixteen coordination mechanisms used in the product area. Table 3 contains the full list of coordination mechanisms, and Sects. 4.2–4.4, illustrate how they were used.

4.2 Product Area Coordination Meetings

We identified six coordination meetings. Two of these were conducted at the team level, and three at the product area level. One meeting occurred at both levels.

First, the monthly all-hands meeting contributed to shared overview across teams. “We needed a shared understanding of the overarching goals we are working towards. At the same time, we need to tell each other about what’s happening in the teams. So the all-hands meeting is actually a combo of a show-and-tell and our goals at a higher level” [I04, PA manager]. Knowing who was working on what contributed to managing knowledge (task allocation) dependencies, and the focus on aligning towards shared goals contributed to managing process (activity) dependencies.

Additionally, various professional forums were held among the specific professional groups. For example, Android developers met every Friday. “It’s like a professional exchange, and a bit like if anyone have any problems they are working with, this is an arena where we can discuss it” [I10, Developer]. As such, these forums contributed to managing knowledge dependencies related to the expertise of others, but also in identifying technical and resource dependencies that blocked team progress.

All teams held Monday commitments “which is a check-in where everyone get together and share our goals for what we will achieve this week” [I02, Developer] and Friday wins “which is more like ‘what did we actually accomplish’ with cake or snacks and good vibes” [I05, Developer]. Although these were team-level meetings, they worked as coordination mechanisms at the product area through the team leaders sharing information in the product management sync meetings. Moreover, “all the Monday commitment boards are displayed in a shared Miro-board, so that everyone can see what we are doing all the way” [I04, PA manager].

Finally, ad hoc meetings were widely used, and were held as needed. This enabled efficient dependency management: “If something needs to be solved, it’s basically just to invite people to a meeting to discuss it” [I09, Developer].

4.3 Product Area Coordination Roles

We identified five roles, three individual and two team roles, specifically related to coordination across teams.

First, the product managers were domain experts responsible for the deliveries. They performed typical product owner tasks such as being the links between the development teams and the internal customers, and communicating requirements to the teams, but they were also engaged in more high-level strategic work: “They are there to make sure we not only make something that is nice for the customer, but also creates value for the organization” [I11, Tech lead]. They engaged in cross-team discussions about prioritizations and technical dependencies and “often, it is the product managers that talk with each other, it is there the collaboration starts. And often it is them who puts together who needs to talk” [I11, Tech lead].

Second, the team leaders were “an administrative support function of sorts, who makes sure that we are onboard with what’s happening in the other teams, in a coordinating role. Also, they shield us from external noise so that we can focus on what we’re supposed to do.” [I01, Developer]. As such, both product managers and the team leaders contributed to managing knowledge dependencies by acting as an information carrier across teams, as well as resource dependencies by making sure the teams had what they needed to proceed. Third, the tech lead role was involved with product area coordination by managing technical dependencies across teams. These roles were held by senior developers who “have a bit more responsibility in the product area and attend discussions with tech leads from the other teams” [I09, Developer].

The product managers, team leaders and tech leads, together with representatives from technology and design, were part of a product area management team who were responsible for overall themes related to shared goals, principles and vision, strategic and economic focus, product compliance, as well as team typologies in the product area. This team was “responsible for providing the teams with strategic context and make sure they have what they need to reach their goals” [Company presentation document], thereby enabling management of process and resource dependencies in the overall product development, and knowledge dependencies by supporting an understanding of shared goals. “It is about facilitating […] to make sure that these teams have what they need to move quickly” [I04, PA Manager].

Finally, if larger or more complex problems with technical and processual dependencies across teams needed to be resolved, the product area made use of task force teams which are temporary teams composed by members of different teams. These were used if “there is a change that has a date, then we kind of have no choice. We have to put aside what else we were planning, and just do it. But that team will dissolve when the delivery has been made” [I12, Team Leader].

4.4 Coordination Tools and Artefacts in the Product Area.

We found six tools and artefacts that contributed to inter-team coordination.

Several communication tools were used, including Slack, Microsoft teams for remote and hybrid meetings, e-mail for more formal communication. For example, Slack was used to communicate and coordinate both within and across the development teams through group channels and one-to-one messages, thereby managing dependencies across the product teams by shared overview and effective communication. “A lot of it happens on Slack. We are often members of many team channels and product area channels, to see what is going on across the teams” [I01, Designer].

Furthermore, usage of documentation and visualization tools, such as Miro, Figma, JIRA, and Confluence, contributed to managing dependencies by supporting cross-team collaboration and knowledge sharing within the team. Related to this, the digital boards were examples of artefacts produced by these tools that contributed to managing knowledge and process dependencies by providing easily accessible information about the other teams’ goals or who was working on what: “It is one large [Miro] board only, with canvases next to each other. It is very easy to just scroll sideways or downwards and zoom in to see what the other teams are doing” [I01, Designer].

To express and measure progress towards the shared goals discussed in Sect. 4.1, the product area used OKR, a goal-setting framework that focuses on reachable business goals by formulating objectives for what to accomplish with corresponding key results that can measure what is actually achieved [37]. OKRs convey information about product and organizational goals, thus contributing to managing knowledge, resource, and process dependencies related to the overall product development. All teams formulated their specific OKRs which they revisited during weekly meetings and displayed in the digital boards. Additionally, “we have OKRs at the organizational level, about four or five focus areas. From those, we have selected some to focus on, while other product areas focus on others” [I09, Developer].

Another interesting coordination tool was PR used across teams. This contributed to managing technical resource, but also process and knowledge, dependencies in that team members could make changes themselves rather than waiting for others to become available. In addition to making a PR it was seen as important to engage in dialogue: “Pull requests are really about creating things together. It’s about talking together. And about saying ‘Hi, I have some thoughts about your product from our perspective. What do you think about this, is this something we could do?’” [I04, PA manager].

An alternative to PRs were to engage in pair programming, where developers work together. While pair programming was widely used within the teams, one explained “if I work with a larger task, I will often engage in pair programming. Mostly with someone from outside the team” [I09, Developer]. Another developer explained, “It is easier to ask someone that works in the same area, the level of engagement is a bit different than if you ask someone that works with their own [team’s] problem” [I05, Developer]. As such, pair programming contributed to managing knowledge and technical and entity resource dependencies related to the expertise of others, as well as process dependencies, in that it removed the need to wait on others to finish reviewing a PR.

5 Discussion

In this study we investigated the research question “How does coordination happen in product areas in large-scale agile?”. Our findings offered three main insights.

5.1 Product Areas as a Distinct Organizational Level

First, a product area can be understood as a distinct organizational level (Fig. 2). Research has shown that coordination can become problematic in very large development settings, as the number of teams increase, so does both systems complexity and the number of dependencies between teams [3, 4, 10]. Therefore, very large-scale development settings requires different dependency management than smaller settings [11, 12]. Our findings illustrated that the very large-scale setup (25-teams) was not manageable in terms of shared goals and successful product delivery, and that dividing into several product areas that could function relatively independent of each other, with their own mechanisms for inter-team coordination, was a successful approach. While inter-team coordination challenges are well-described in the current literature [e.g., 2, 4, 10], and studies has described mechanisms offered by large-scale frameworks, such as Area Product Owners in LeSS [23], little research attention has been directed at specifically examining coordination in product areas.

Fig. 2.
figure 2

The product area as a distinct organizational level.

Full size image

We found seventeen mechanisms that contributed to managing dependencies in the product area. This number is comparable to other studies. For example, Dingsøyr et al. [10] describe a large-scale case of ten teams that used fourteen inter-team coordination mechanisms, Stray et al. describe nineteen mechanisms [32] and Vedal et al. [36] list 22 mechanisms from the same case with seven teams.

5.2 The Team Typology of Product Areas

Second, a key characteristic with the product area was the set-up of vertical and horizontal teams (see Fig. 1). This type of set-up is similar to what is described in the Team Typologies framework [25] which propose core team types including the stream-aligned team the platform team, the enabling team, and the complicated subsystem team. These types can be compared to the types of teams we observed.

First, stream-aligned teams are described as cross-functional teams who are independently responsible for building and delivering specific products [25]. The vertical teams are comparable to this team type as they focused on specific products, such as creation of bank accounts or products of financial overview. This comparison is in line with the general concept of software product teams [17, 28, 34].

Second, platform teams are typically internal teams that support and enable the steam-aligned teams in delivering the customer-facing products [25]. This compares to the horizontal teams that developed internal products shared by the vertical teams. Platform teams are often used in large-scale agile because they manage dependencies between the vertical teams by providing resources such as shared infrastructure [1, 10]. We also found that the horizontal teams provided designers and testers, as needed.

Third, complicated subsystem teams can be compared to the temporary task force teams described in Sect. 4.3, which were assembled to resolve specific priorities with high levels of complexity that required a greater extent of inter-team coordination. According to Skelton and Pais [25], most organizations will not need this type of team on a permanent basis. However, in line with our findings, other studies support that temporary task force teams are useful in large-scale software development when specifically complex task needs to be solved [1, 3, 22].

Finally, we compare the product area management team to the enabling team type. This team type assist, coach and support teams as needed [25]. In the product area, the management team helped setting and managing the product teams’ goals and directions, removed barriers, and made sure they were provided with training in for example, product development practices and use of the OKR framework.

5.3 Pull Requests and Pair Programming as Coordination Mechanisms

Third, our findings shed light on how pull requests and pair programming were used as inter-team coordination mechanisms. While both these tools are well-known and well-described within software engineering, our study is among the first to show how they could be specifically used to manage dependencies between teams.

Use of the PR practice enable knowledge sharing and aim to balance the skills in the teams [18]. In our findings, the PR mechanism enabled solving dependencies within and between teams because instead of waiting for others to add, change or delete code, a developer could work in others’ code and then create a PR. Pull request have been used as a tool to manage technical dependencies across teams in other large-scale settings too. For example, Šmite et al. found that the number of cross-team and even cross-tribe pull requests at Spotify is huge [26]. And while the PR mechanism is now standard for code reviews, challenges have been reported, such as when team members are distributed, or when teams in large-scale settings use different agile approaches [30].

Interestingly, we found that the use of pair programming to some extent could replace PR as a coordination mechanism, as developers from different teams writing code together eliminated the need to create, review, and approve PR across teams. However, we cannot say from these observations alone what constitutes an optimal balance between the mechanisms, or to what extent this finding can mitigate the challenges reported [30]. Future research should therefore investigate how PR are used as a coordination mechanism, and if, and when, pair programming could be used as a replacement.

5.4 Practical Implications

In addition to the theoretical contributions, our study offers several practical take-aways. First, we recommend managers of very large-scale product development settings to consider organizing into smaller product areas, preferably with fewer than ten teams, as this is considered a cut-off level of increased complexity [12]. Our findings show assembling a product area with teams that focused on the same goals, enabled the use of several shared coordination mechanisms, such as the Monday commitment and Friday wins meetings, and OKR at the product area level.

A second recommendation is to consider sharing resources within the product area. This provides greater flexibility in responding to changes, which is important to consider as coordination needs change over time [3]. Moreover, sharing roles and expertise within a product area enables more efficient management of resource dependencies, within the capacity limits that are set for the roles. We further recommend setting up a product area management team that can follow up on the longer-term strategic goals and support the product managers in facilitating goal attainment at the team level [34]. Finally, if the development context is characterized by widespread use of PR, we recommend using pair programming across teams as a replacement mechanism to resolve technical dependencies, as PR is a more passive action that requires inter-team communication which in worst case can create process dependencies and hold-ups.

5.5 Evaluation of Limitations and Research Quality

The main limitations of this study are the single-case study design, and the use of interviews as the main data source, which makes it difficult to generalize the findings [29]. However, we relied on several forms of triangulation using multiple perspectives to ensure rigor and quality in the research process and to clarify the findings [29].

First, we ensured data source triangulation by supplementing the interviews with observations and strategic documents. By interviewing participants from different teams, we gained access to participants’ understandings of coordination in the product area. By observing meetings and supplementing with documents we obtained context and a deeper understanding of the participants statements during the interviews. Second, researcher triangulation was ensured by having different roles in the author team. The second and third authors collected the data, and the first author conducted the analyses. The fourth author contributed with additional data material and in-depth knowledge about the case organization. Third, methodological triangulation was used in the analytical phase, where we used the well-established thematic analytical framework [6], supplemented by the field-specific taxonomies [1, 33] which contributed to the relevance of the analysis in the large-scale agile empirical setting.

6 Future Research and Concluding Remarks

In this study we conducted a single-case study to understand coordination in large-scale product areas. This topic has received little research attention, at the same time as product management is re-surging as an important topic in agile software development practice. At the same time, the coordination challenges in large-scale agile prevails.

With this study, we have attempted to provide more knowledge on coordination in product management, by describing how coordination happened in a nine-team product area in a large-scale FinTech organization. We described seventeen coordination mechanisms used to manage dependencies, and illustrated how the product area can be represented as distinct organizational level. However, there is still a need for more knowledge on product area coordination, in particular in relation to what constitutes optimal product area size and team configuration [21]. Moreover, the product area organization form was relatively new for the case organization, and therefore, ongoing experimentation and changes were happening. With this study, we have only presented a snapshot, based on the data collection period. More research is needed to understand if and how changes in the product area also influence change in coordination mechanisms used in the product area. Additionally, we have described the team typology of product areas. Similar team types have been described in other studies, albeit not specifically within the product management context. This is an interesting avenue for future research. Finally, we identified pull requests and pair programming as related coordination mechanisms. However, we do not know enough about how these mechanisms can replace each other. Future research should aim to further advance our understanding of coordination in large-scale agile product management in general, and product areas in particular, with the aim of improving software product delivery and value.