Keywords

1 Introduction

Software product development and business development (BD) in large-scale agile requires closer collaboration between actors such as legal representatives, customer service agents, market and business representatives, designers, developers, testers, and maintainers. However, contemporary research shows that software development has been characterized by harmful disconnects between important activities such as planning, development, and implementation. Therefore, the link between business strategy and software development needs to be addressed and improved [10, 19].

Even if there seems to be a broad consensus in the literature that a holistic approach to software development is needed [8, 10, 11], at the same time, topics related to BD are often found outside the scope of software development as well as outside the cross-functional product development teams.

Table 1. Overview of the interviews
Full size table

In large-scale agile, it is crucial for business and software product development teams to coordinate well, which can be challenging due to the size [4, 6, 9, 14]. Effective coordination of work within large-scale agile software engineering is key to project success, and researchers have addressed topics related to leadership, organizational context, design of teams, autonomy, and team processes [7, 13]. Further, team autonomy must be balanced with the larger organizational structures because of a need for alignment between the system, the organization, and the product [5, 6, 15]. Challenges in large-scale agile include integrating non-development functions, change resistance, stakeholder management and keeping to the agile principles [6, 8, 9].

Berntzen et al. [3] found 27 coordination mechanisms across three categories in their study of 24 teams: Meetings, roles, tools, and artifacts. They found that the product managers, development managers, and customer managers were important for managing business process dependencies. Further, Bass emphasized the functions [1] and activities [2] performed by product owners to demonstrate the significance of the role for inter-team coordination.

We aimed to explore the overall research problem of balancing and aligning BD and product development in large-scale software development by investigating the following research question:

RQ: What are the barriers and enablers for coordinating business development (BD) and software product development in large-scale agile?

To answer our research question, we conducted a case study of a Nordic fintech company, hereafter called SoftCo.

2 Context and Methodology

SoftCo started as a service from a large Nordic enterprise and was later spun off as a separate company. SoftCo offers a payment infrastructure for the Nordic market, and operates in both the B2B (business-to-business) segment and the B2C (business-to-consumer) segment. The software development is done almost completely in-house. During the company’s lifetime of approximately five years, there have also been mergers and acquisitions, with the consequence that the existing code-base of SoftCo’s products may have different origins. The company culture is based on agile values, with a focus on flexibility and autonomy.

Fig. 1.
figure 1

Product areas and their associated teams

Full size image

The products are separated into three product areas; B2B - serving business customers, B2C serving end-users as consumers, and infrastructure products covering products related to payment infrastructure (see Fig. 1). Each product area is managed by an area product manager, with several underlying product managers and product teams. These cross-functional teams are often referred to as product- and tech teams, with team members such as an Engineering Manager (tech and personnel responsibility), a Product Manager (OKRs and P &L responsibility), UX and Interaction Designers (usability risk responsibility), back-end developers, and front-end developers. The product areas, the products, and the 25 cross-functional development teams are shown in Fig. 1. In addition, SoftCo has several other teams with more commercial-oriented focus, such as Marketing, Sales, Business Development, Strategy and Finance, and finally, Legal and Compliance. The employees within Business Development, Strategy, and also, to a certain degree, within the Sales unit label themselves as business developers. Much of their work is related to gaining new income by increasing market positions and developing partnership models. These teams are hereafter called commercial teams.

Slack was the main communication platform for both direct communication, daily group communications, and sharing documents. There are currently more than 1600 channels in use, and all of the company’s approximately 300 employees and consultants are able to create a channel. Open channels are highly recommended. A statistical report for a 30-day period shows that more than 243.000 messages were written in Slack, where 40% in public channels, 40% in direct messages, and 20 % in private channels.

Based on the research questions of this study, a qualitative approach with a descriptive and interpretive design has been chosen. The data collection has been done through in-depth interviews and document analysis. Such kind of a case study is explained by Yin (p. 5) [20] as an in-depth investigation of a real and contemporary phenomenon in a real-life context. The interviews were conducted in December 2021–March 2022 and lasted, on average, one hour; see Table 1. All recordings were transcribed, and we used NVivo to analyze the interviews and the Ladder of Analytical Abstraction [12] to structure the data analysis. This method helped us categorize, sort, and find patterns to reduce raw data. A predefined coding scheme was a starting point, with room for data-driven coding and grouping into new categories and themes.

3 Results

It is one thing to focus on continuous processes and trying to bridge the gap between commercial activities and product development; it is quite another to enable such collaboration and coordination to work in practice. Here, we focus on the main barriers and enablers in our empirical study on the team and organizational level when engaging in large-scale agile product development.

Table 2. Different Perspectives on Business Development
Full size table

3.1 Barriers

Unclear and Ambiguous Understanding of BD. Our analysis showed that people in the commercial and product teams had different understandings of the role of business developers and the tasks performed by a business developer. Because of missing role clarity (clarity employees have about the requirements and tasks for their work and others’ work), alignment between business and product teams became problematic.

When analyzing what the interviewees understood as business development, we found six different perspectives; see Table 2 for a summary. For example, one of the interviewees stated that business development and software product development “are the same thing, and there should not be anyone else than the product department that should work with such topics” . The interviewee meant that many resources may give their input, but it is finally the product managers who decide what to do. Other interviewees said there are many similarities between product and business development, and the line between the two is often unclear. Another perspective was that business development includes developing products, but goes wider and broader. A product manager explained that “Business development is the level above product development, because it also includes a holistic approach, such as finding customers, markets and distribution channels for the product being developed”.

These different perspectives indicate that having a unified definition of BD could reduce barriers. Based on our findings, we suggest that a definition of BD should include activities for creating new value, by creating new market positions, establishing new distribution lines, creating new products or new product features, or winding down the product portfolio to focus on other market positions.

Us Versus Them Culture. The commercial teams experienced that it was difficult to provide input on business development aspects (such as how to strengthen the market with new products and features) to the product- and tech teams. Some interviewees described that one reason was that the product teams wanted to have a bottom-up culture, be autonomous, and decide tasks themselves. For many, it felt like an us versus them mentality between the commercial teams and the product teams. The input from the commercial side was treated on many occasions with the same resistance that a top-down management approach would have received. One of the sales managers said:

“The development teams have no deadlines. They can deliver whatever they want at any time, and we struggle to give our input to this process.”

The mentality was a barrier that reduced collaboration between business developers and product teams. A business developer stated, “At worst, those teams think they are autonomous, so they will deliver something they believe is important, but in reality, there are other understandings from other parts of the organizations of what should be the most important thing to deliver.”

Agile only Embraced by Parts of the Organization. The product- and tech teams had used agile methods and techniques from the beginning. Trying to make a distance to the origin companies that SoftCo had spun out from, they had chosen not to entirely go for a well-established large-scale agile framework, but rather develop an in-house model, based on agile principles with a high degree for flexibility and autonomy for the product- and tech teams. This in-house model was well documented, and all interviewees explained that it was known to the whole company that “this is how the company executes their product development”. However, the commercial teams, including business developers and strategy resources, had their own processes. Those methods were not documented in the same extensive way as the in-house agile development model of the product- and tech teams, and some interviewees explained that they did not even know what the “so-called business developers” were doing. One product manager proclaimed:

We [the product-and tech teams] follow the company development model for product development, while “they” [BD] just follow their gut feeling

The lack of discussion of how to work together and what common processes to follow divided the company into two, which then strengthened the us versus them mentality. Since common processes, principles, and tools were missing, synchronization, alignment, and coordination of work became problematic. When interviewing people, many argued that it would be difficult to have a one-size-fits-all methodology, mainly because BD is both a broader and perhaps more future oriented area compared to product development focusing more on short term perspectives.

3.2 Enablers

Cross-Functional Business Fora. The cross-functional business fora, with bi-weekly meetings, helped bridge the gap between the commercial and product teams. Those fora were open to more people across the units, so they became an important arena for cross-functional discussions, with a wider professional coverage compared to what was found in the product- and tech teams. The foras was seen as a mean to prevent silo thinking, and the members of the commercial teams felt included. Further, the dialogue and dynamics that evolved in those fora reduced the us versus them mentality.

Having Agile Coaches. The in-house agile development model was developed and managed primarily from the product development side of the organization. The agile coach interviewed said they would like to spend more time educating and informing the whole organization about how to use agile methods. Several interviewees indicated that having agile coaches helped reduce the “us versus them” mentality and the use of statements such as “our model” versus “their model”. The commercial and product teams gave characteristic and polarized descriptions of each other and each other’s working practices. The agile coach understood both the business and software development perspectives and functioned as a valuable intermediary between the two groups.

A Unified Strategy and Collaborating on Goal-Setting. Our findings indicate that having a strong and clear strategy helped align the autonomous teams and prevented them from running in different directions. Also, in SoftCo, some used Objectives and Key Results (OKRs), which helped increase harmony between the commercial teams that were working with long-term strategic BD, and the product teams working on concrete tasks for the sprint. It also made it easier to collaborate on BD activities and helped the commercial and technical sides work together towards a common goal.

4 Discussion and Conclusion

In this study, we explored the challenges and enablers of aligning business development and product development in large-scale software development by asking, “What are the barriers and enablers for coordinating business development and software product development in large-scale agile?”

Our findings confirm previous research that coordinating business and software product development teams is challenging in large-scale agile [4]. Our case study revealed that an unclear understanding of BD and business developers’ roles and responsibilities hindered alignment between commercial teams on one side and the product teams on the other. An unclear terminology coupled with an “us versus them” mentality, created barriers for collaboration and reduced the effectiveness of business development input. As a common understanding of terms is important, based on our case study, we suggest the definition of business development in the context of large-scale agile software development as shown in Fig. 2.

Fig. 2.
figure 2

Suggested definition of BD

Full size image

Furthermore, the absence of common processes and principles between agile product teams and more commercial-oriented teams perpetuated this divide, making synchronization and coordination of work challenging. Addressing these issues may require tailored agile methodologies that promote shared understanding, collaboration, and integration of processes throughout the organization. Our findings suggest that agile coaches can help reduce the “us versus them” mentality by educating the entire organization. This finding supports that agile coaching should not be limited to the team level and that an important part of the work of a coach is to facilitate overcoming human-related obstacles and to guide both stakeholders and managers in the implementation of agile methods [17].

We found that the use of OKRs also helped improve the coordination between commercial teams and product- and tech teams, where people from business development and software product development worked together to agree on common future objectives. These fora can be understood as communities of practice or guilds [16]. For example, commercial teams worked together with the product teams when setting OKRs for the respective product area, and this seemed to have a positive effect in building a clear strategy. The use of collaboration tools like Slack and goal-setting frameworks such as OKRs has earlier been shown to play a vital role in coordination in large-scale agile where Slack enabled frequent, timely, and problem-solving communication, and OKRs facilitated knowledge sharing, goal alignment, and inter-team coordination [18].

Bridging the gap between commercial teams and agile product teams requires a reorientation not only by developers and business developers but also by management. Making such changes takes time and resources, but it is a prerequisite for the success of any kind of large-scale agile product development.