Exploring the Product Owner Role Within SAFe Implementation in a Multinational Enterprise

[Context] Agile development methods are highly popular across software organizations. To leverage benefits in larger enterprises, Agile development methods have to be scaled. Scaled Agile Framework (SAFe) is the most commonly used scaling framework. Performing of the Product Owner role has been identified as crucial in project success in large-scale environments. Staffing the right Product Owner is one of the challenges of adopting SAFe. [Motivation] Research papers focused on Product Owner in SAFe are scarce. Our study outcomes help enterprises to understand the Product Owner role in SAFe and therefore contribute to the removal of challenges with finding the right Product Owners. Additionally, we aim to improve the research community’s understanding of the Product Owner role within the context of SAFe. [Method] Qualitative data were collected through three semi-structured interviews and analyzed using deductive content analysis. [Results] This paper presents the initial results of a single case study. We found out that many activities identified for Product Owners in previous research are not carried out by Product Owners in this particular SAFe implementation.


Introduction
Agile, as a set of iterative and incremental software engineering methods [1], becomes commonplace in many large organizations [2], where agile practices have to be scaled [3]. Scaling Agile was identified as an important research topic [4], and more and more large organizations are transitioning towards Agile [1,2]. During this process, new roles are introduced to the enterprise environment, such as the Product Owner (PO) role. The PO role originates from the Scrum method [5] and has been identified to play a crucial role in project success [1]. The PO role is also present in the frameworks for large-scale Agile, such as Scaled Agile Framework (SAFe) [6], which is the most commonly used framework for scaling Agile [7]. However, staffing the right PO was identified as one of the challenges of adopting SAFe [8]. Surprisingly, research papers with a focus on the PO role in SAFe are scarce. A better understanding of the role in SAFe will help enterprises to acknowledge requirements to people assigned to the PO role and therefore help with the success of their SAFe adoption. In our research, we address the following research question (RQ): Which of the activities described for Product Owners in previous research are performed by the Product Owners in the examined enterprise that follows SAFe?
The paper is organized as follows. Following Introduction, Sect. 2 provides a literature review and a taxonomy of PO functions mapped to SAFe roles. In Sect. 3, the adopted research method and the context of the study are described. Section 4 provides findings from the semi-structured interviews. Section 5 concludes the paper with a discussion and a summary of key take-aways.

Background
In this section, we provide a literature review and present a taxonomy of PO functions. We use the term "function" to refer to a designated group of coupled activities.
Large-Scale Agile. Scaling Agile was identified as an important topic [4]. Dikert et al. [1] identified challenges and success factors for large-scale Agile transformations, focusing on large-scale organizations with 50 or more people. The agile practices have to be scaled [3], and POs must cope with a range of new activities [9].
Product Owner. Originally, Scrum defined the PO role relatively simply as the sole person responsible for managing the Product Backlog [5]. Yet, the adequate performing of Product Owners was identified as one of the critical success factors for projects [1], and a wide range of other activities performed by PO was described [3,[10][11][12][13][14]. The PO role has been examined in previous research. Bertzen and Moe [15] identified the importance of frequent communication and interaction between POs in large-scale Agile. Paasivaara et al. [3] described the differences in approaches to scaling the PO role. Bass carried out an empirical research [9,10] on the PO activities in a large-scale Agile environment. Yet, only a limited amount of papers focus on the PO role in SAFe.
SAFe. SAFe provides prescriptive guidelines for implementing enterprise-scale Lean-Agile development, and a number of companies that have applied SAFe have reported significant benefits from it [6]. Interestingly, the popularity of SAFe seems unaffected by concerns about Agile principles and values in the top-down approach, and SAFe's strong emphasis on process rather than on people [16,17].
SAFe and PO. Despite some existing research on SAFe [8], papers focused on the PO role in SAFe are still scarce. The study of Paasivaara et al. [2] states that implementing SAFe results in closer collaboration and communication between POs and Product Managers (PM). However, the study focus was on SAFe adoption in general. Overall, little is known about the PO in SAFe.
PO in SAFe. SAFe adopted the PO role but, in contrast to Scrum, assumes that a single person cannot handle product and market strategy while also being dedicated to agile teams. It was confirmed in [9,10] that in large-scale Agile environments, the scope of activities goes beyond the capacity of one person acting as PO. PO and PM share responsibilities for working with customers [6]. We have identified some of the PO activities from [3,[10][11][12][13][14] in the descriptions of activities performed by other SAFe roles. The System Architect (SA) creates an architectural vision and aligns teams around a shared technical direction [6]. Aside from development, during planning, the Agile Team (AT) identifies risks and impediments [6]. The risks are actively managed by the Release Train Engineer (RTE) [6]. Specialty roles, people, and services to cover customer training, support, and compliance audits are represented in Shared Services [6]. Scrum Master (SM) ensures that the agile processes and guidelines are followed [6].
Taxonomy of PO Functions. To understand the fragmentation of PO activities, we extracted the taxonomy of the PO functions from the previous research on POs outside the context of SAFe [3,[10][11][12][13][14]. Next, we mapped the activities from the taxonomy to the descriptions of roles provided in SAFe [6]. The results are presented in Table 1. The functions described by Bass [10,11] were used in accordance with his descriptions. When adding functions from [3,[12][13][14], we followed the example of the descriptions of functions in [10,11]. Added functions from [3,[12][13][14] are written in italics. Prioritizer [10] Prioritizes requirements in the product or sprint backlog and ensures requirements bring value to the business.

PO/PM
Groom [10] Makes sure product backlog is continuously evolving and registers requirements from clients. Clarifies the details of product backlog items and their respective acceptance criteria.

PO/PM
Release Master [10] Manages and approves release schedules. PM Technical Architect [10] Designs, implements, and disseminates a reference architecture, provides architecture coordination on large projects.

SA
Governor [10] Provides a technical governance framework to project teams working on a program and ensures project compliance with corporate guidelines and policies.

RTE/SM/SA
Communicator [10] Ensures that global teams are in sync and bridges onshore and offshore geographical distribution.

SM/PO
Traveler [10] Travels to clients to get first-hand knowledge of the client's needs and gathers an understanding of it by spending time onshore at customer sites.

PM/PO
Intermediary [10] Has extensive experience in the system business domain and acts as an interface to senior executives.

PM
Risk Assessor [10] Performs risk management and mitigation when needed, especially with focus on technical complexity.

AT/RTE
Gatekeeper [11] Determines feature or story completeness for inclusion in the release.
PO Customer Relationship Manager [11] Provides technical support to customers, assists with site preparation and product installation, and conducts product training.

Shared
Services Entrepreneur [12] Develops business/product plan and service planning. PM Motivator [13] Motivates the team and finds ways to get the team more involved. SM Leader [14] Leads the development teams. SM Negotiator [3] Negotiates with different stakeholders to avoid conflicts.

PM/PO
The mapping in Table 1 indicates the fundamental difference between the PO role in SAFe and the PO role examined in previous research by showing a visible fragmentation of previously identified PO activities to other SAFe roles.

Research Method
Context. The single-case study has been conducted in a division of multinational enterprise that delivers mainframe software. The examined value stream specifically focuses on workload automation software, written mostly in low-level programming languages. For newer components (e.g. modern user interfaces), higher languages like C, Java, or JavaScript are used. The division follows the Portfolio SAFe configuration [6] and claims to follow SAFe on the team and program level "by the book". The development teams work in 2-to 4-week sprints. Overall, the environment can be characterized as a very large-scale Agile with 30 teams and 250+ team members.
Data Collection. Three POs have participated in the initial phase of the study. Table 2 shows the length of their experience in the role, the number of teams they concurrently work with, the number of development team members they work with, their previous position, and overall experience in the field of mainframe enterprise software. Additional interviews with 6-7 respondents are planned to complete the study.
The interviews were done in person, audio-recorded, and transcribed. The interview guide is available at https://rebrand.ly/4ylvsbo. The interviews consisted of 54 questions, 3 to 4 per each function, and took from 65 to 85 min to complete. Our aim was to identify if the activity of the function had been performed, to what extent, how often, typically followed by a request to provide an example to validate the previous answers. All recordings and transcripts were given codes and stored separately from any names or other direct identification of participants.
Data Analysis. A deductive content analysis [18] was used. We used the functions from the taxonomy introduced in Table 1 as categories for the analysis. Next, we manually open coded, analyzed, and matched data into these categories. As the last step, we have interpreted the results.

Results
In this section, we provide the preliminary results from the examined SAFe implementation. The comparison of each PO function from the taxonomy introduced in Table 1 with the findings from the semi-structured interviews showed that POs in the selected enterprise SAFe implementation perform the activities of Prioritizer, Groom, Communicator, Traveler, Gatekeeper, and Motivator. In the rest of the functions, POs are only partially involved. In Table 3, we present evidence for each function in the form of quotations or merged findings. The functions confirmed as being performed by POs are written in bold. All POs stated that architectural activities and decisions are not in the scope of PO activities. As evident from PO C 's answer, they try to avoid any architectural involvement as much as possible. "I try very hard to exclude myself from any involvement with architectural decisions. And I also try very hard to avoid anything in the description of the user stories that will imply any suggestion for architectural decision." [PO C ] Governor Different roles perform governance activities. POs mentioned: SA, Legal, Functional Managers, and SMs. For POs, the delivery of the item is the primary concern. POs only make sure that the frameworks are followed and, in case not, inform other roles to take action. "I raise a point or question when I believe it is appropriate to raise the point, but  All POs clearly stated that there are dedicated support and education teams, so POs are not directly involved in providing support nor training to the customers. PO activities in this area are limited to providing internal training sessions and materials to support and education teams. "I got the skillset, but it is not what I do. I will not sit with the client and show him how to install the product." [PO B ] Entrepreneur All POs are involved and are contributing by providing information to, and having discussions with, PM. The decisions and plans are made by PM, who also owns the product roadmap. "As PO I just discuss what customer want, reflect this to the management, and then the decisions will come from the management, not the product owner. POs seem to be positioned as mediators, but not the negotiators per se. "I would consider myself a mediator between different stakeholders and trying to find the source of the conflict and initiator of it." [PO C ]

Discussion and Summary
Examining the Scaled Agile Framework [6] and its concrete implementation in a multinational enterprise, we addressed the RQ: "Which of the activities described for Product Owners in previous research are performed by the Product Owners in the examined enterprise using SAFe?". We found out that many activities identified for PO in previous research are not carried out by POs in this SAFe implementation. Specifically, our preliminary research findings demonstrated that PO in this particular SAFe implementation is *not*: leading the teams; mitigating identified risks; designing, implementing and disseminating technical architecture; providing governance frameworks; ensuring compliance with corporate guidelines; communicating with senior executives; nor providing support and customer training. This is surprising because previous research conducted outside the context of SAFe assumed that PO responsibilities are very broad. Below, we offer a hypothesis about the reason for the inconsistency. The mapping provided in Table 1 indicated that there is a complex relationship between the previously identified PO functions and roles in SAFe, where the performing of the activities is fragmented among multiple roles. Supported by the outcomes from the conducted semi-structured interviews, which indicate that in SAFe, the original PO role functions have undergone significant modifications, it is evident that PO functions in SAFe are different from the functions of the PO role identified in previous research. In our research, the close collaboration between PO and PM described in [2] was confirmed. In fact, PO's decisions about priorities and requirements for development are strongly influenced by PM, who, in reality, drives and develops business and product plans. This PM activity contradicts the prime Scrum definition of PO as the sole person responsible for managing the Product Backlog [5]. Therefore, the PO's accountability for product leadership fades away.
We offer a possible explanation. SAFe provides rigorous descriptions for the implementation of Agile processes on a large-scale and put the emphasis on the process [15]. This de-facto leads to a new form of the management-driven top-down approach [16] with the fragmentation of the roles. We support this statement by evidence from the interview: "As PO I just discuss what customer want, reflect this to the management, and then the decisions will come from the management, not the product owner."

[PO A ]
Conclusion. The PO role in the examined SAFe implementation deviates from the previous understanding of the role outside the context of SAFe, as the range of PO activities is narrowed. We attribute it to the top-down approach criticized by practitioners and confirmed during our single-case study. We identified PM as the person accountable for, and steering, the product.
Limitations and Threats to Validity. The presented results were obtained in one division of a large multinational enterprise and, therefore, might be influenced by the local context. Achieving a validity in a single case study is a known challenge, thus plausible, rival explanations or triangulation methods should be used in further research to strengthen validity of our findings [19]. The study provides only preliminary outcomes from the three interviews. Hence, it is too soon generalize the PO role in SAFe. Two papers [12,13] used in our taxonomy did not explore a large-scale environment context. Still, we identified similar activities appearing in the examined environment.
Future Works. As this research is ongoing, another 6-7 interviews will follow to validate the preliminary findings. Our next steps will be to gather, analyze, and incorporate more data from POs with different experience and from different parts of the organization, which will help to understand the real-life PO functions in SAFe implementations. More case studies exploring further enterprise SAFe adoptions are needed to confirm the findings presented in this study.