Holger Fischer
email: hfischer@s-lab.upb.de

Björn Senft
email: bsenft@s-lab.upb.de

Human-Centered Software Engineering as a Chance to Ensure Software Quality within the Digitization of Human Workflows

Keywords: Digital Transformation, Change, Acceptance, Workflows, Human-Centered Design, Agile, Software Engineering, Work 4.0

Nowadays, a technological development boost can be observed within information technology and its application possibilities. This development results in a digitization of economic processes and human workflows, e.g. within the manufacturing industry. Furthermore, the discussion between digital assistance of employees vs. automation of processes leads to an ongoing change of work tasks or employees' responsibilities. Decision-makers will have to focus on organizational, human as well as on technological aspects to ensure organizational and employee's acceptance of digital solutions likewise. Despite all efforts, today's software products still lack of quality with regards to missing or unused functionality and bad usability. Thus, current software engineering methods seem to be insufficient. Therefore, this paper describes an iterative approach combining software engineering paradigms like human-centered design and agility to enable decision-makers within manufacturing industry to build digital tools that are accepted by their employees and are of value for the company itself.

Introduction

Having a look on today's occupations, there are lots of reasons why people work. The primary objective as well as the most important one is earning a living for themselves and their families [START_REF] Maslow | A Theory of Human Motivation[END_REF]. Further objectives include to be part of the society, to create an own identity and to keep one's own dignity. Work is vital for everyone and for the society at all. It allows the people to participate, to use their talents, to find contact, recognition and validation within a community. Nowadays, we can perceive an evolution of the working environment due to the digitization of manual workflows, work places or tools. Digitization within the context of manufacturing industry describes the transformation process from traditional handmade activites towards computer-supported activities, e.g. operate a robot or maintain a machine getting assistance through digital glasses. This ongoing change and its impacts on the employees is also known as a part of "Work 4.0" [START_REF]BMAS): Re-Imagining Work -Green Paper Work 4[END_REF]. The overall term of Work 4.0 addresses multiple topics. Besides a cultural shift (e.g. work-life balance, demographic change), changes in the standard employment relationship or the globalized knowledge society, the main driver for all these topics is the digitization and automation of human workflows. Software solutions are increasing within the professional work context [START_REF]Monitoring Report Digital Economy[END_REF], e.g. enterprise resource planning (ERP) solutions in the administration, cooperative robots in the production or augmented reality glasses in the commissioning. The possibilities are versatile, but they also encourage further discussions about the impacts on the human working life. For example, thinking about the degree of automation within manufacturing industry, there are advantages and disadvantages for digital assistance systems as well as for the complete automation [START_REF] Bainbridge | Ironies of Automation[END_REF]. Shall the people or the system be in charge of control and decision within a process? Shall we store the organization's knowledge within the system or shall it be the knowledge of the employee to react on sudden anomalies? Bainbridge [START_REF] Bainbridge | Ironies of Automation[END_REF] describes some ironies of automation in her previous work, which are still up to date. For example, developers of systems designate the human to be the main source of error and build an automated substitute. At the same time, these developers are also humans. Thus, operational errors are often development failures based on insufficient assumptions. In addition, employees are replaced with a system because these systems should be more efficient. Simultaneously, the employees shall monitor and maintain the system and manually take over if necessary using all their knowledge that was replaced by the system before. Hence, an adequate human-system interaction has to focus on the supply with status information as well as to ensure situational awareness at any time. In summary, human working environments, workflows and areas of responsibilities are continuously changing. In addition, the concerns from outside the organization are rising, too. Planning a digitization within an organization challenge the persons in charge to take multiple perspectives into account (see Fig. 1) and deal with possible impacts of used technologies in advance, e.g. ensuring jobs, prevent the loss of knowledge, prevent a temporal condensation of work, increase the product quality. Therefore, modern software and system development will have to increase their focus on the employees using the systems. Project managers or IT departments cannot cope with the challenges on their own. Especially employees respectively end users have to participate in the change process due to the fact that they have to work with the systems at last. Thus, the individual and organizational acceptance as well as the usability and user experience of the system are crucial quality aspects. According to the World Quality Report [START_REF] Buenen | World Quality Report 2015-16[END_REF], CIOs and IT executives nominate "Ensure end-user satisfaction" along with "Protect the corporate image" and "Increase quality awareness among all disciplines" for the main three top quality objectives in the quality assurance of software products. "Customer [or user] experience" is also one of the five top influences on today's IT strategies. Despite all efforts, today's software products still lack of quality with regard to functionality and usability. According to the CHAOS manifesto [START_REF] Johnson | CHAOS 2014[END_REF], approximately 45% of the analyzed software projects have challenges within missing functionalities. In addition, business software in the European medium-sized enterprises lack on unused functionalities (36%) as well as on unusable software (21%) [START_REF]Independent Study on IT investments[END_REF]. Thus, current software engineering (SE) methods seems to be insufficient, because they don't consider end users in terms of active involvement during the development process. The challenge addressed in this design paper is to establish a participatory and iterative software engineering method combining paradigms like human-centered design (HCD) and agility. Thus, decision-makers within industrial manufacturing companies should be enabled to interdisciplinary build digital tools instead of monolithic systems that are accepted by their employees, by the work councils and are of value for the company itself. The paper is structured as following: First, the authors discuss existing approaches of SE methods with a focus on users and iterations regarding their potentials for the use in the digitization within manufacturing industry. Then, the authors present some contexts from industry project and elicit requirements for an agile SE method. Finally, the concept is outlined and future work is described.

Related Work

Several different software development approaches exist that focus on user participation and iterative development. Therefore, an introduction to human-centered design and agile development is given. Furthermore, a brief overview of combined approaches is presented.

Human-Centered Design

Human-Centered Design (HCD) is an established methodology within software development with a focus on the users of a prospective system [START_REF]Ergonomics of human-system interaction -Part 210: Human-centred design for interactive systems[END_REF]. HCD intends to create interactive solutions that match the users' needs and expectations as well as to support their tasks towards their specific goals. The advantages are far-reaching and include increased productivity, improved quality of work, and increased user satisfaction [START_REF] Jokela | An Assessment Approach for User-Centred Design Processes[END_REF]. One of the central quality attributes for interactive systems is their usability [START_REF] Bevan | Quality in Use -Meeting User Needs for Quality[END_REF]. Especially tasks that are either time-sensitive or security-critical benefit from user interfaces (UI), which are suitable, easily to understand as well as controllable. HCD includes lots of techniques to foster user participation (e.g. interviews, observation, prototyping, etc.), but it is still a discussion how to select appropriate techniques and how to integrate them on an operational level within existing software development processes. Thus, outcomes are mostly not directly convertible to software development, e.g. due to their narrative textual representation. Furthermore, HCD is living the prototyping and experimentation concept. Using paper-based or high-fidelity mockups, users' needs will be validated or even discovered during the ongoing development. Current software development methods mostly focus on evolutionary high-fidelity prototypes close to final user interface. However, low-fidelity paper-based prototype will encourage users to provide more feedback because they hold the status of incompleteness and enable people to think about their needs [START_REF] Walker | High-Fidelity or Low-Fidelity, Paper or Computer? Choosing Attributes when Testing Web Prototypes[END_REF]. Hence, it will be necessary to "encourage" the organizations in order to ensure software quality using throw-away prototypes.

Agile Software Development

Agile development (e.g. Scrum [START_REF] Schwaber | The Scrum Guide[END_REF]) enables an incremental development of software having a continuously runnable part of the software ready for reviews with the customer. Therefore, transparency and inspection are two key factors to create a common understanding within a project. However, agile development is not targeted on modeling user requirements and human behavior in a comprehensive way. Having inspections with the customer does not fulfill the expectations of having a broad analysis and evaluation with multiple users who are currently working with a system. Additionally, a systematic and documented way of decisions concerning the interaction or the UI as well as a systematic treatment of user feedback is missing. Talking about users within agile development often means customer feedback or user stories. Unfortunately, customers are not necessary real users of a system and may have a different idea about how a system should work. While the customers' focus is on the business values, the users are more related to their workflow and tasks. In addition, user stories that are only based on assumptions about users instead of empirical data might misdirect to unutilized functionalities. Agile model-driven development (AMDD) is an approach to specify models and implement solutions in an agile manner. Hence, it foster iterations of specifications as well as on solutions. Ambler [START_REF] Ambler | Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development[END_REF] propose a method to work on models, "which are just barely good enough that drive your overall development efforts". This is done in contrast to model-driven software development approaches, where extensive models are created before starting to write source code. Therefore, the AMDD lifecycle begins with an envisioning stage to specify initial requirements and to sketch an initial architecture. After that, the actual iterations start using model storming, modeling iteration and test-driven development stages completed by an optional review of the developed increment. The iterations are repeated until a software product result meets the requirements.

Agile HCD

Despite different positions towards requirements elicitation or upfront design, agile development and HCD have some similarities. Both focus on quality assurance while iterating with representative persons -business customers (agile development) or users (HCD) -to request continuous feedback. Thus, the main aspects are "quality", "iterations" and "active involvement". Over the last years, several approaches have arisen that addresses the combination of agile methodologies and HCD. For example, Silva et al. [START_REF] Da Silva | User-Centered Design and Agile Methods: A Systematic Review[END_REF] presented a systematic literature review identifying 58 relevant papers as well as defining eleven "agile usability patterns" [START_REF] Bertholdo | Agile Usability Patterns for UCD Early Stages[END_REF] for the early stages of HCD [START_REF]Ergonomics of human-system interaction -Part 210: Human-centred design for interactive systems[END_REF]: Plan the HCD activities, describe the context of use, specify user requirements. Belchev & Baker [START_REF] Belchev | Improving Obama Campaign Software: Learning from Users[END_REF] describe the pattern of having a "sprint zero", conducting one-toone interviews in the users' workplace to better understand the overall view of a system before starting to develop. Sy & Miller [START_REF] Sy | Optimizing Agile User-Centred Design[END_REF] formulate the "one sprint ahead" pattern to enable and synchronize the communication between the development and UX team at defined times. Gothelf & Seiden [START_REF] Gothelf | Lean UX: Applying Lean Principles to Improve User Experience[END_REF] describes his experience being a "UX specialist as product owner" to take real user needs as well as customers' interests into account for the prioritization of the product backlog.

In summary, several approaches on user participation and iterative development exist. Software engineering methods based on the Agile Manifesto [START_REF]Manifesto for Agile Software Development[END_REF] (e.g. Scrum, XP, Kanban) help us to get more agile but focus on the development itself. Taking the findings of Adolph [START_REF] Adolph | What Lessons Can the Agile Community Learn from A Maverick Fighter Pilot[END_REF], agile itself is a relative concept, a time based strategy for operational success. It is about reacting to changing environments, respectively the model we have of an environment. This in an utterly important finding as it shifts the focus from a building perspective to a holistic view. Not only speeding up the development process is important, but also improving the decision process. This means that the whole organization have to be open-minded for agility instead of just the development itself. Existing agile methods focus on single detached solutions or monolithic systems, which become deployed at the end of the project. Addressing industrial manufacturing, it will become necessary to digitize the process step-by-step with multiple digital assistance services supporting human workflows. Deploying one digital service might lead to impacts within the organization (e.g. temporal condensation of work or changing tasks) and it will need an overall agility to react on these changing work environments. Thus, digitization will be an ongoing process without any real end and the feedback during the everyday runtime of digital services have to be taken into account.

Human-Centered Software Engineering Method

In order to develop a human-centered software engineering method for the manufacturing industry, the different contexts within three industrial projects have been analyzed using semi-structured one-to-one interviews as well as observations and visits of production facilities. Key questions of this procedure were: How does the workflows look like? Is digital assistance a topic and for which tasks? Are employees involved in the digitization process and how? Insights and statements by the participants have been transcribed. Afterwards, requirements for a software engineering method have been derived within a team workshop based on these information. Then, an engineering method has been sketched to discuss and evaluate its validity and applicability within the three industrial projects.

Digitization within Manufacturing Industry

Having a look at the digitization of human workflows within manufacturing industry it is difficult to choose the suitable degree between digital assistance and complete automation (see Fig. 2). Taking the example of order picking, the first kind of digitization is the (1) "digital copy" of an actual workflow. Thus, a clipboard can be switch to a mobile device with a digital checklist. The overall workflow remains the same as before. A more automated digitization is the (2) "digital assistance". Using augmented reality (AR) and smart glasses the worker can be supported with a pick-by vision system. Thus, the workflow will change because the system undertakes human tasks and will make some automated decisions. Now, the first impacts of the system within the workplace environment might occur, because the person using the smart glasses might be distracted by the system and might not observe its surrounding carefully, e.g. a forklift truck that pass by. The third kind of digitization is the (3) "complete automation". A self-driving industrial truck might collect all parts from a warehouse by its own. The worker in charge will become unnecessary. Thus, all the knowledge about the process is implemented within the system. In a kind of system breakdown, the remaining worker might not be familiar with the previous picking process and the organization might struggle with the situation. Hence, the digitization of human workflows within manufacturing industry depends on the decision with multiple perspectives: business (e.g. reducing costs), human (e.g. changing tasks or responsibilities), society (e.g. work-life balance), politics (e.g. saving jobs) or legislation (e.g. work safety). Decision makers might not be able to predict every impacts before starting to work on a digital system. An agile and humancentered method will provide industrial organizations with an approach to deal with the challenge.

Industrial Contexts

Case 1: Facade Engineering: The organization of this case is active within the context of building construction and supports their customers (e.g. architects, engineers, constructors) with free of charge services in order to convince them to buy their building elements later on. Some stand-alone solutions exist that supports the involved people with some assistance. With the aim to improve the overall construction planning and coordination process and to connect existing solutions, a project has been set up to analyze the context of use within the company (sales, engineering, consulting) as well as with the users of their services.

Case 2: Door and window fittings production: The organization of this case is specialized in the production of individual door and window fittings. The employees in the assembly line perform different task and have to pick the parts of an order from the warehouse or have to adjust their machines or tools according to the order specification. Every information is written on a printed paper sheet that accompany the product through the assembly line. Maintenance information are based on the experience of the employees. For example, information about the quality of drill heads from the ones of Brazil vs. the ones of France is individual knowledge and unknown by the sales department. A project has been set up to analyze possibilities for assistance services and to ensure the individual acceptance by the workers.

Case 3: ATM assembly The organization of this case produce all different kinds of self-service systems, e.g. automated teller machines (ATM). The automated production of the parts needed is followed by a manual assembly line.

Multiply quality gates within this assembly line ensure the quality of the prod-ucts. As the number of produced machines is low within each order due to individualization by the customer, quality problems are reported at a time when they cannot be fixed anymore. A project has been set up to identify possibilities for digitalization of paper-based documentation and quality assistance for the worker.

Requirements

Based on the analysis of the industrial contexts, some requirements were elicited to develop a software engineering method for the digitization within industrial manufacturing.

Decision support: The decision-makers within an organization have to decide which workflows they would like to digitize and in which way they would like to do this. They have to balance different perspectives with different objectives for a digitization. To take all perspectives into account, to foresee possible impacts and to formulate a strategy, a matrix of key point indicators (KPI) have to be developed in order to ensure organizational acceptance. Employee participation: All stakeholders (employee directly interacting with the system; employee that are affected by the system; employee that perceive itself to be affected by a decision, activity, or outcome) have to be involved in the software development lifecycle. They have to participate in every development stage starting with requirements elicitation in order to ensure an appropriate workplace design and individual acceptance. Big picture: Dependencies of human workflows and organizational processes have to be identified in advance to achieve a broader view of the organization and to enable an appropriate interaction and user experience of digitized assistance services. Task suitability: Users' tasks have to be elicited properly as the system represents a tool to support the users in fulfillment of their tasks and goals.

Iterations: User requirements have to be elicited over iterations to evoke implicit knowledge and user needs. The amount of iterations has to depend on the quality of a functionality. Agility: The organizational culture have to allow agile management of workflows and assistance services during runtime in order to immediately react on impacts within the work environment.

Interdisciplinary nature: Interdisciplinary decision-maker teams have to be introduced comprising manager as well as workers, technology scientists, psychologists, sociologists and designer to deploy an appropriate digitization and to enable innovations through the employee. It will support the organizational change within the software-using organization and will create a feeling of participation and decision on the employee level. Architecture: The systems' architecture has to be as flexible as possible to react on changed as well as on new added requirements for the digitization.

HCSE Method

An agile SE method has been developed in accordance with the defined requirements and the given context of manufacturing industry (see Fig. 3). It is divided into four major iterations: Envisioning, modelling, development, operation.

Envisioning: The approach starts with an envisioning stage to build an abstract "big picture" of participating roles, their responsibilities and interactions within the work environment. Thus, dependencies of human workflows and organizational processes as well as later impacts can be identified. Performing contextual inquiries with interviews and observations all stakeholders are analyzed and their context of use is described on an upper level using the concept of flow models (addressed earlier in [START_REF] Fischer | Towards a Task Driven Approach Enabling Continuous User Requirements Engineering[END_REF]). Based on this abstract model of the organization a KPI matrix of acceptance criteria for organizational as well as individual acceptance of digital transformation is built. Thereby, a first architectural envisioning of a possible systems' architecture is conducted and quality metrics are defined. Digitization of complex human workflows is step-by-step project. Therefore, the system's architecture should be designed as flexible as possible using e.g. modularization concepts as well as service-oriented architectures (SOA). Hence, a kind of "service toolbox" with multiple assistance services for the workers may arise.

Modelling: To develop each assistance service the concrete human workflow that shall be digitized is analyzed using a deeper contextual inquiry. One focus is also on the workplace to identify restrictions, e.g. no space for installing a touch display or touch isn't an option due to safety gloves the worker wears. All analyzed information about the current workflow are described using task models, e.g. HAMSTER notation [START_REF] Martinie | A Multi-Formalism Approach for Model-Based Dynamic Distribution of User Interfaces of Critical Interactive Systems[END_REF]. Then, the modeled tasks are allocated between the human or the system based on the acceptance criteria the team decided on before. Using these information, prescriptive task models are developed and the needed functionality is derivated. A first validation of the new concept can be achieved using evaluation techniques, e.g. focus groups. Preparing the development of the modeled assistance service a model-to-model (M2M) transformation is used. Thus, the task model is transformed into a dialog model respectively an abstract user interface (AUI) model using interaction description languages, e.g. IFML [START_REF]Interaction Flow Modeling Language (IFML)[END_REF].

Development: The development of the user interface (UI) and the software functionality may be done according to model-driven user interface development paradigms, e.g. the CAMELEON reference framework [START_REF] Calvary | A Unifying Reference Framework for Multi-target User Interfaces[END_REF]. Using modelto-model transformations, the AUI model is than transformed in a concrete user interface (CUI) model specified for the target platform. Based on the CUI model the initial code for the final user interface (FUI) can be generated with a modelto-code (M2C) transformation taking appropriate guidelines and style guides into account. Performing usability test with usability experts as well as with employees will ensure the quality of the interaction with the UI. Operation: As the digital transformation is a continuous step-by-step project, lots of changes and impacts on the work environment (e.g. temporal conden-sation of work, changing job knowledge conditions) will occur during runtime after the deployment of a assistance service. For example, also an earlier deployed service might conflict with the new one. Thus, the organization should be set up according to an agile manner. Hence, a long term evaluation based on the organizational and individual acceptance criteria can monitor these changes and reflect the feedback back into modeling or development stage to improve or replace an assistance service within the service toolbox.

Conclusion

In this paper, the lack of quality within today's interactive systems due to insufficient software engineering methods, which don't consider end users in terms of active involvement during the development process, and the rigidity of requirements in the context of digital transformation have been discussed. The focus has been on the digital transformation of human workflows within the manufacturing industry. Next to the business perspective on reducing production costs, further perspectives have to be taken into account. Employees as well as society, politics or legislation addresses new challenges towards work structures, working time or work environments. Therefore, an approach has been presented that uses human-centered design to focus on the employees' workflow as well as iterations to set up an agile software engineering method that develop assistance services instead of inflexible monolithic systems. It has been shown, but not yet fully validated that the approach of four major stages addresses the specified requirements of the digital transformation within the manufacturing industry.

In our future work we will further expand the concepts in more detail. In a next step the matrix for individual and organizational acceptance criteria as a concept for decision support will be elaborated within multiple workshops with representatives of local industrial enterprises. Furthermore, the approach will be enriched defining roles and responsibilities for the most critical parts. All steps of the approach will be evaluated within further software projects as well as within teaching activities.

Fig. 1 .

 1 Fig. 1. Concerns from outside the organization

Fig. 2 .

 2 Fig. 2. Example: Decision about the degree of automation within order picking


Filip Kis
email: fkis@kth.se

Cristian Bogdan

Endev: Declarative Prototyping with Data

Keywords: UI modeling, GUI generation, interactive prototypes, discourse model, query annotations

The trend of Open Data and Internet-of-Things initiatives contribute to the ever growing amount of data available through web APIs. While building web applications has become easier with recent advancement in web development technologies and proliferation of JavaScript frameworks, the access to data from various APIs and data stores still poses certain challenges. It often requires complex setup and advanced programming skills that hinder the rapid prototyping efforts. Therefore, we propose Endev, a declarative framework for prototyping applications that is built on modern web technologies and supports building modern web applications, that utilize the vast amount of available data, without the need for setup or write complex JavaScript code.

Introduction

The Open Data and the Internet-of-Things trends are producing more and more data that users are expected to have access to via GUIs of interactive applications. At the same time building such data-centric applications requires less effort than ever, for skilled developers, thanks to cloud services, popularization of scripting development technologies (e.g. JavaScript, Python) and the omnipresence of web1 . However, the setup and advanced programming skills required to build interactive prototypes hinders the rapid prototyping efforts.

Prototyping is the key activity in human-centered software engineering process as it allows designers to explore design alternatives and include end-users early on in the process. Various prototyping methods, from sketching to using dedicated prototyping tools, are used in practice, however, the research shows that designers desire better tools that would allow them to prototype the flow of data and advanced interaction [START_REF] Grigoreanu | What designers want: Needs of interactive application designers[END_REF][START_REF] Myers | How designers design and program interactive behaviors[END_REF]. Furthermore, a survey of 4000 designers [START_REF]The Tools Designers Are Using Today[END_REF] shows that HTML is preferred prototyping tool over tools specifically designed for prototyping (e.g. InVisio) or even general design tools (e.g. Photoshop, In-Design).

Building on these research results, and with the aim to support rapid prototyping of data-centric applications, we demonstrate Endev [START_REF] Kis | Declarative Setup-free Web Application Prototyping Combining Local and Cloud Datastores[END_REF] -a declarative prototyping solutions. The declarative HTML annotations allow users to prototype interactions with, and connection to, data. Endev is developed as JavaScript library and utilizes cloud services to support data storage and API access without the need for server setup or dedicate development environments.

Related Work

Declarative languages have played an important role in UI development and especially in web design where HTML and CSS are dominating as markup technologies for defining UI layout. Modern client-side web development frameworks (e.g. Angular [START_REF]AngularJS -Superheroic JavaScript MVW Framework[END_REF], Ember [START_REF] Ember | js -A framework for creating ambitious web[END_REF]) use declarative data-binding constraints that provide more dynamic features, such as keeping HTML elements automatically in synchronization with the application data values, though they still require significant amount of non-declarative code to access the backend or the API data.

Quilt [START_REF] Benson | Spreadsheet driven web applications[END_REF] is a recent solution that provides HTML annotations to connect the interface to a spreadsheet that serves as the datastore. Quilt allows both data read and write and keeps the interface in synchronization with the spreadsheet data. Another solution based on spreadsheets as the datastore is Gneiss [START_REF] Chang | Creating Interactive Web Data Applications with Spreadsheets[END_REF]. Unlike Quilt, Gneiss is a live programming mashup environment where, instead of using HTML annotations, the users can drag and drop widgets to the page and connect them with spreadsheet values. A key feature of Gneiss is the support for any REST2 web service returning JSON3 data which can be interactively combined in the spreadsheet before their data is used in the interface. The main drawback for Gneiss compared to Endev is that the users are limited to working with UI widgets existing in the system, which significantly reduces the design possibilities.

XFormsDB [START_REF] Vuorimaa | Leveraging declarative languages in web application development[END_REF] is a declarative data binding solution that binds to server-side data. It is based on the XForms4 , a W3C Recommendation, that was designed to be the next generation of HTML forms. XFormsDB depends on having a complex server setup and supports only XML based databases, thus it is not ideal for quick prototyping. Furthermore, even though XForms are relatively old-standard (first version published in 2007), none of the major browsers currently natively supports it.

Setup-free prototyping with Endev

During prototyping, it is often important to be able to share the prototype with other stakeholders to solicit feedback. When the prototype is interactive, includes data, or requires a complex setup, it becomes hard to share it beyond screenshots or video recordings that capture only fixed path interaction. However, Endev addresses these challenge by utilizing modern web technologies and cloud services.

With Endev the users can prototype web applications that provide data storage and other features that contemporary users expect (e.g. drag-and-drop interaction, real-time data synchronization) by writing HTML and annotating it with declarative expressions. Such prototypes can be executed in any browser, which makes them easily sharable. In other words, the prototype can be sent by email, shared over Dropbox or put on-line in one of the code playgrounds (e.g. CodePen5 , JsFiddle6 ) for easy access and modification. We will use an example Wish List app (shown in Figure 1) to demonstrate how a prototype can be built with Endev. The goal of the Wish List app is to give the users possibility to setup their wish list (e.g. for a birthday or Christmas). Each item on the list can optionally include a picture that the users can retrieve by searching through public pictures on Flickr. The following sections will describe how the two main challenges (storing the wish list data and getting the pictures from Flickr) are achieved through prototyping with Endev. The more comprehensive and interactive tutorial covering the main features of Endev is available on-line7 .

On-the-fly creation of own data

Storing the data is typically not a concern that is addressed during UI prototyping. The designers normally use dummy data that is either not possible to edit or, at a more advanced stage of the prototyping, the edits are temporary (e.g. refresh of the page or reload of the app reset the data). However, there is a value in working with the data that is stored. For instance, when testing with users they get to experience the flow of the application by experiencing the interaction with the data. Furthermore, if there is a need to quickly modify the design, the user-entered data is still there and thus makes the comparison of alternatives easier to compare.

Listing 1.1 shows the HTML code with Endev annotations needed to list the items from the wish list and add a new item to the list. The code is the same code used for the application shown in Figure 1 without the additional layout-only HTML code.

Current list < div data-from = " f i r e b a s e : W i s h L i s t item " d a t a-a u t o -u p d a t e = " true " > < input data-value = " item . name " / > < img src = " {{ item . image }} " / > < / div > Add item to list < input data-value = " newItem . name " / > < img src = " {{ newItem . image }} " / > < button d a t a -i n s e r t -i n t o = " f i r e b a s e : W i s h L i s t " data-click = " insert ({ name:newItem . name , image:newItem . image }) " > Add < / button > Listing 1.1. Endev code of Wish List app (see Figure 1) for listing the items in the wish list and adding a new item to the list.

In this example data-from and data-insert-into annotations are used to connect to the data storage for which we use Firebase8 cloud storage. Firebase is a document-based storage, therefore, there is no need to define the data structure before hand. Instead, data is stored as-is and on-the-fly.

We have seen, in the related work, some solutions use spreadsheets to allow building applications quickly without the need for complex database setup. However, document-based data storage provides more complex data objects compared to spreadsheets thus allowing for more complex use-cases. Furthermore, Firebase is just one of several data providers offered by Endev and others (e.g. spreadsheet storage) can be added easily.

Other annotations like data-value and data-click serve to bind the values to some UI elements or user actions respectively. Finally, the data-auto-update annotation enables automatic updates of the values in the Current list, in other words, as soon as the users modify any of the items in the list the changes are saved automatically.

The second challenge of the Wish List app is to integrate with Flickr search API so that an image can be associated with the wish list item. Traditionally such feature would be prototyped with dummy data instead of having a real API integration. However, with more and more web services generating data and applications that work with them it is important that prototyping includes working with real API data. Web service data, compared to proprietary domaindata, comes with certain challenges (e.g. quality, reliability, latency) that are often out of control of application developers. For instance, the end-users or designers might expect the results from API to be the same as when they use the actual service where the data comes from. While, in reality, the service provider might have different algorithms for these two cases. Experiencing the differences early on in the prototyping allows for better management of expectations and thus better design.

Accessing APIs requires certain amount of complex and error-prone code [8] that needlessly increases the prototyping effort. Endev addresses this by providing seamless mechanism for reading web service data that is seen by the users as just another data provider. In other words, the difference between reading their own data (as seen in Listing 1.1) and the data coming from an API is in the string that defines the data source (e.g. data-from annotation).

Listing that follows shows how the users can read data from Flickr API based on the inputed search term.

Search for an image < input data-value = " searchTerm " / > < div data-from = " yql:flickr . photos . search result " data-where = " result . text = searchTerm AND result . api_key = ' _API_KEY_OMITTED_ ' " > < div data-from = " result . photo photo " > < img src = " http: // farm {{ photo . farm }}. staticflickr . com /{{ photo . server }}/{{ photo . id }} _ {{ photo . secret }}. jpg " d a t a -i n s e r t -i n t o = " f i r e b a s e : P h o t o C o l l e c t i o n " data-click = " newItem . image = ' _LONG_URL_OMITTED_ ' " > < small data-from = " yql:flickr . people . info2 people " data-where = " people . user_id = photo . owner AND people . api_key = ' _API_KEY_OMITTED_ ' " > by {{ people . person . username }} < / small > < / div > < / div > Listing 1.2. Endev code of Wish List app (see Figure 1) for searching public images on Flickr and, when one image is clicked, adding it to the new item.

The first data-from has similar meaning as in Listing 1.1. However, instead of getting data from Firebase, Endev now uses Yahoo Query Language platform 9 to directly access the Flickr search API. Since the data returned by the API is hierarchical (i.e. contains an item called photo that contains an array of actual photo results) the second data-from is used to access each item in the array. The final data-from is used to access another Flickr API which returns the information about the owners of the photos based on their ids. Finally, the data-click sets the value of the image of the newItem which was used in Listing 1.1 when creating the new item for the list.

Behind the scenes

Endev is implemented as JavaScript framework with architecture shown in Figure 2. Endev Core is responsible for caching (on the client-side) and querying the data from one of the Endev Providers which, in turn, access the data and keep it in sync with the data storage. Endev Annotations are built on top of Anuglar, therefore, Endev supports evolutionary prototyping as the prototype can evolve beyond the capabilities provided by Endev. Thus, Endev can be used to either quickly prototype a completely new application or just a new feature in already existing applications. In both cases the prototype can evolve into a more stable system without the need of re-implementing the whole interface from scratch. In this paper we demonstrated Endev, the tool for prototyping interactive applications with data. Endev enables prototyping with real data, created by the users or coming from a web service, through declarative annotations without the need for complex setup or server orchestration. The prototypes are simple HTML files that can easily be shared among all the stakeholders and require only a browser to be executed.

While the declarative annotations employed by Endev provide a uniform way of accessing data, there is a challenge in finding and understanding the growing amount of web service data. Endev currently supports a basic way of exploring the data returned from an API, however, in the future we would like to explore how to better support the discovery and understanding of APIs during prototyping.

Fig. 1 .

 1 Fig. 1. The Wish List prototype showing the items on the list (with name and optionally an image) on the left (Current list) with possibility to add a new item on the right (Add item to the list). At the top right the users can type the name of the new item, while in the bottom right they can search and select a picture that should be associated to the item.

Fig. 2 .

 2 Fig. 2. Endev architecture

Web is becoming the platform of choice for many applications as it is easier to maintain (no installs or updates) compared to desktop or mobile applications.

Representational State Transfer protocol -most widely used protocol for web service APIs

JavaScript Object Notation -data format often used by exchanging data through web services

https://www.w3.org/MarkUp/Forms/

http://codepen.io/

https://jsfiddle.net/

http://www.endevjs.org/tutorial

https://firebase.google.com/

https://developer.yahoo.com/yql/


Sigurhanna Kristinsdottir
email: sigurhanna@gmail.com

Marta Larusdottir

Åsa Cajander
email: asa.cajander@it.uu.se

Responsibilities and Challenges of Product Owners at Spotify -An Exploratory Case Study

Keywords: Project Management, Product Management, Agile, Agile Methods, Scrum, Product Owner (PO), Software Development

In Scrum, the Product Owner (PO) role is crucial for the team to be successful in developing useful and usable software. The PO has many responsibilities and challenges, including being the link between customers, other stakeholders and their development teams. This exploratory case study conducted at the software development company Spotify focuses on POs three responsibilities: a) Identification of customers, b) Estimation of value of their teams' work and c) Forming a vision for the product. Additionally, challenges perceived by the POs are studied. Data was gathered through five interviews and on site observations. Results show that the POs activities are divided between daily work, such as making sure that their teams are functional and long-term activities such as making a vision for the product. The main challenge of the POs is to inspire and encourage team members to collaborate and communicate within the team and with stakeholders.

Introduction

Traditional project management approaches for software development, like the waterfall approach, have been challenged by Agile approaches in recent years [START_REF] Cervone | Understanding Agile Project Management Methods using Scrum. Managing Digital Libraries: the view from 30,000 feet[END_REF]. Agile is an umbrella term for project management approaches such as Scrum, XP, and Kanban [START_REF] Strode | Coordination in clocated Agile software development projects[END_REF], where Scrum is the most widely adopted Agile approach [START_REF]The 10 th State of Agile Survey[END_REF].

Scrum is an approach with a few ceremonies, roles and artefacts. The roles are called: Product Owner (PO), Scrum Master (SM) and Team Member (TM) [START_REF] Schwaber | Software Development with Scrum[END_REF]. Management responsibilities are divided among these three roles [START_REF] Schwaber | Agile Project Management with Scrum[END_REF]. Pichler describes the PO role as a new, multi-faced role that unites authority and responsibility that traditionally, in the traditional processes was scattered across separate roles such as customer, product manager and project manager [START_REF] Pichler | Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series)[END_REF]. Hence, when using Agile ap-proaches the PO role in some aspects replaces the role of various stakeholders. The PO has the authority to set goals and shape the vision of a product and therefore the PO has other responsibilities than the project manager that mainly writes requirements and does prioritization for the team [START_REF] Pichler | Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series)[END_REF]. For example, the POs in Scrum projects in Iceland had various responsibilities [START_REF] Sverrisdottir | The role of the product owner in Scrum -comparison between theory and practices[END_REF]. The proportion of the POs time collaborating with the team varied from 5% to 70% of their total working time. Furthermore, the POs used from 10% to 50% of their working time collaborating with customers, users and other stakeholders [START_REF] Sverrisdottir | The role of the product owner in Scrum -comparison between theory and practices[END_REF].

The Product Owner role has not had much focus in academic research; the main focus has been on productivity, teamwork and collaborative decision-making in Agile teams rather than studying specific Agile roles. Additionally, more attention has been on examining factors that drive organizations to initially adopt Agile approaches than on those that affect their continued usage [START_REF] Senapathi | Understanding post-adoptive Agile usage: An exploratory cross-case analysis[END_REF]. Still, the use of Agile approaches is constantly increasing in software development [3; 25], thus the Product Owner role is interesting and important since this role is often the link between business and development departments of an organization. One of the fundamental principles of Agile approaches is to aim at satisfying the customers by producing valuable pieces of the final product early in the development lifecycle [START_REF] Misra | Agile Software Development Practices: Evaluation, Principles, and Criticism[END_REF].

This paper is an exploratory case study conducted at the software development company Spotify at the end of February 2014. It is a description of the PO role at this point in time and the main focus of the research is to study how POs identify customers for their teams, how they measure value of their teams' work, how they form vision and communicate that to their teams, what their challenges are and how they deal with those.

The research questions in this study are:

1. What are the main responsibilities of the Product Owners? Particularly: a) How do Product Owners identify customers for their teams? b) How do they measure the value of their teams' work? c) How do they form the product vision for their teams?

2. What are the challenges of a Product Owner, and how does he or she cope with them?

The structure of the paper is that first we describe some of the background literature on Agile approaches and Scrum. We particularly describe the definitions of the POs role. Then we describe the data gathering methods used in the study, followed by a section describing the results. Finally we discuss the findings and give concluding remarks.

Background

This section describes Agile approaches and Scrum, the teamwork of Agile teams and the PO role.

Agile Approaches and Scrum

The origin of Agile project management (Agile) was first described in a paper by Takeuchi and Nonaka in 1986 [START_REF] Takeuchi | The new new product development game[END_REF], but Agile as a methodology gained attraction when Sutherland and Schwaber [START_REF] Sutherland | The SCRUM Methodology. InBusiness object design and implementation[END_REF] discussed the first Agile process (also called Agile approach) for software development in the 1995 OOPSLA conference. They had analysed common software development processes and found that traditional development approaches were not suitable for empirical, unpredictable and non-repeatable processes such as development of software. The fundamental values and principles behind Agile are described in the Agile manifesto [START_REF] Beck | The Agile Manifesto[END_REF]. Six obstacles in decision making in Agile have been analysed, which are: a) unwillingness to commit to decisions; b) conflicting priorities; c) unstable resource availability; and lack of: d) implementation; e) ownership; f) empowerment [START_REF] Drury | Obstacles to decision making in Agile Software development teams[END_REF]. The effect of these obstacles is a lack of longer term, strategic focus for decisions, an ever-growing list of delayed work from previous iterations, and a lack of team engagement.

In Scrum, the most common Agile process [START_REF]The 10 th State of Agile Survey[END_REF], the projects should be split up into two to four week long iterations called sprints, each aiming to end up with a potentially shippable product. In Scrum, self-organizing and strongly united teams are heavily emphasized, typically with six to eight interdisciplinary team members. One of the benefits of using Agile was claimed to be that customers' needs are taken more into account than when developing software using sequential processes [START_REF] Schwaber | Scrum development process[END_REF]. The Scrum team is self-organising and works independently during the sprints. Daily Scrum meetings are prescribed where the Scrum team meets and plans the work during the day, and where the tasks are distrib-uted in the group. The work in the Scrum team should be guided by collaboration and communication. Demos of the outcome are made at the end of every sprint. Agile teams should have a common focus, mutual trust and the ability to reorganize repeatedly to meet new challenges. IT professionals appreciate the inherent values in Scrum, which are speed and communication internal to the Scrum team. Also, working in teams and focusing on a small number of tasks at a time is valued. The main challenges are that including specialists in the teams is hard and Scrum does not always match with external requirements for the organizations [START_REF] Larusdottir | Challenges from Integrating Usability Activities in Scrum -Why is Scrum so Fashionable?[END_REF].

Being self-organised does not mean leaderless, uncontrolled teams but that the leadership is meant to be light-touch and adaptive, providing feedback and subtle direction. Leaders of Agile teams are responsible for setting direction, aligning people, obtaining resources and motivating the team [START_REF] Hoda | The impact of inadequate customer collaboration on self-organizing Agile teams[END_REF]. The leader can be anyone with influence or authority over the team and can include managers, POs and the SM [START_REF] Cohn | Agile estimating and planning[END_REF]. In the next subsection, definitions of the responsibilities of POs are described.

Definitions of the POs Role

Schwaber [19; p. 6-7] defines the PO role as follows: "The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. The Product Owner achieves initial and ongoing funding for the project by creating the project's initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration."

Both the developing team and the people driving the business need to collaborate to develop the final required product [START_REF] Misra | Agile Software Development Practices: Evaluation, Principles, and Criticism[END_REF]. The PO is the link between the customer and the user side of an organization and the development team. The team and the PO should constantly collaborate and plan together how to produce the most value for the business [START_REF] Schwaber | Agile Project Management with Scrum[END_REF]. The primary duties of the POs are making sure that all team members are pursuing a common vision for the project, establishing priorities so that the highest-valued functionality is always being worked on and making decisions that lead to a good return on the investment in the project or for the product [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF][START_REF] Kniberg | Scrum and XP from the Trenches: How we do scrum[END_REF]. The responsibility of the PO is to prioritize the work to be done by the team, but he or she should not be involved with how the team does their work [START_REF] Ivarsson | Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds[END_REF]. In commercial software development, the PO is often someone from the marketing or production management side of an organization [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF].

Picher describes that the PO should lead the development team to create a product that generates the desired benefits for the customer and the user [START_REF] Pichler | Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series)[END_REF]. This includes creating the product vision, prioritizing the product backlog, planning the releases, involving stakeholders, managing the budget, preparing the product launch, attending meetings, collaborating with the team and many other tasks.

Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] states that the PO role is challenging because the PO needs to address both inward and outward facing needs simultaneously. The inward facing responsibilities being participating in daily stand-up meetings, reviews, retrospectives as well as management meetings, managing the product backlog, answering questions from the team and being available to the team as much as possible. Outward facing responsibilities are to attend to user's needs, manage stakeholder expectations, prioritize the product backlog and develop a product strategy and vision. Furthermore Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] states that the PO should provide just enough boundaries for the project so that the team is motivated to solve the difficult problems but not providing so many boundaries that solving the problems becomes impossible. In that way the role is more of an art than science.

Galen [START_REF] Galen | SCRUM Product Ownership: Balancing Value from the Inside Out[END_REF] states that the PO role is the most difficult one within the Agile or Scrum team. A PO needs to be a highly skilled individual who understands the nuances of the role and is enabled by the organization to take the time necessary to fully engage the teams in value-based delivery. A skilled PO is a member of his team and should consider the team as his or her primary customer. PO is a distinct member of the team in which overall success or failure is a joint endeavour. The PO needs to give the team the right things to do and make sure they do everything possible to qualify the work [START_REF] Galen | SCRUM Product Ownership: Balancing Value from the Inside Out[END_REF]. The PO role can be difficult to staff with a single individual because the competences are so broad and intimidating that it is hard to find an individual having all these skills [START_REF] Galen | SCRUM Product Ownership: Balancing Value from the Inside Out[END_REF].

In summary, Cohn, Galen and Pichler describe four aspects of the PO role, which are: involving customers, focusing on value, creating a vision and that it is a challenging role. Schwaber has a bit more focused definition, emphasising customer involvement and value of the product as the main aspects. We therefore analyse the results according to four themes in the paper: 1) customer involvement, 2) focusing on value, 3) making a vision and 4) challenges of the PO role.

Method

Little research exists on the Product Owner role, and this study is exploratory in nature and examines the role of Product Owners. The research is a qualitative case study conducted at Spotify at the end of February 2014. This study was first presented as a master thesis study and has been rewritten for the purpose of this publication.

Context of the Study and Participants

Spotify was founded in 2006 in Sweden and in 2008 they released their core product, a music player named Spotify that can be used online or downloaded as an app on desktop or mobile. Its users have access to one of the fastest growing catalogues of licensed music in the world [START_REF]Labels and artists[END_REF]. It has grown tremendously since it was founded, has a good track record of product delivery and its products are loved by users and artists [START_REF] Kniberg | How Spotify Builds Products[END_REF] Active users are growing fast, they were over 20 million at the beginning of 2013 and paying subscribers around 5 million [START_REF] Kniberg | How Spotify Builds Products[END_REF]. At the time of this case study Spotify's employees were around 1.000 with software development taking place in three locations: Stockholm, Gothenburg and New York.

Spotify has used Agile approaches in one form or another since it was founded in 2006. Their teams, which are called squads, used Scrum in the past but when they started delivering all tasks ahead of the end of each three-week sprint they decided that each team could be completely autonomous in the way they work. Some teams use Scrum today but that is a minority of all the development teams. Most of the teams use Kanban or some form of that. But each team still has a Product Owner and a Scrum Master. At the time of the study, the product that was being developed was quite mature. The Agile teams had been working on the product for years, and their way of working had matured a lot, since the company was established.

As this is a case study the participants were selected in consultation with a professional from Spotify. The participants were spread across the organization to insure that they did not have the same background and were working in different projects and with different parts of the product.

Five interviews were conducted. Three Product Owners were interviewed, one director of Product Development, that was previously a Product Owner and one Scrum Master, called Agile Coach at Spotify, to receive a better view on the Product Owner role and his challenges. One of the Product Owners also had the role of an Agile Coach at the time of the interview. The participants had various backgrounds; most of them started as developers but had changed roles, two participants said it was because they like to speak their opinion on the way things are done so they were asked to take the Product Owner role on a team. The participants all had a good understanding of agile processes and the business of Spotify.

The others happened to take on this role when the teams were set up according to Scrum. The Product Owners work in different parts of the organization, which might explain differences in their opinions.

Research Method

Case studies are the preferred method when how or why questions are being posed, when the investigator has little control over events and the focus is on a contemporary phenomenon within a real-life context [START_REF] Yin | Case study research: design and methods[END_REF].

The case study method allows the investigator to retain the holistic and meaningful characteristics of real-live events, such as organizational and managerial processes.

As one of the researchers had the chance of conducting a research of the Product Owner role at Spotify's headquarters in Stockholm this research method was chosen. Knowledge gained from this study is transferable to other settings through the interpretations of the reader.

In this exploratory case study we have used a mixed methods approach. The primary data collection method was in-depth, face-to-face semi-structured interviews with five employees at Spotify. The first step in data gathering was to prepare the interview protocol and pilot test it prior to the study. After the pilot test there were minor changes to the protocol. The protocol had: 7 questions on the background and experience of the participants, 2 questions on the stakeholder focus, 2 questions focusing on value, 3 questions on the vision, 5 questions on teamwork, 4 questions on the challenges for POs and 9 questions on the PO role in general.

The interviews were audio-recorded with the permission of the participants and then transcribed verbatim. Their length was between 50-65 minutes. The quotations in the results chapter are not always verbatim but slightly rephrased to be more readable.

Observation on site were also made through shadowing a Product Owner for a day to observe his daily role. The shadowing included being present in all meetings the Product Owner had that day: stand-up meetings with his teams, one-on-one meetings with his team members and managerial meetings. Additionally informal conversation was performed people in various roles around the organization.

Source data hence included field notes from the observations, transcripts from the interviews, documents and photographs taken at site. The researcher spent three days at Spotify finishing each day by documenting the observations as field notes and then used the next day to seek clarification and gather more data.

Analysis of the Data

In the analysis we identified and coded the results into the four themes: 1) customer involvement, 2) focusing on value, 3) making a vision and 4) challenges of the PO role. When analysing customer involvement, both statements about the customers (the person paying) and end users (the person using the software) are analysed, since the users for the Spotify service are also customers. The source documents were grouped by each participant and then analysed by the use of the themes according the theme analysis [START_REF] Ezzy | Qualitative analysis: Practice and innovation[END_REF]. Conclusions were finally drawn from the data collected. Emphasis was put on understanding the participants' lived experiences in the Product Owner role and their different views. In order to answer the research questions, the transcripts and field notes were read several times to obtain insight into each case.

Results

In this section the research results are divided into two sections, the first subsection presents results from the interviews when it comes to the POs experience of the three responsibilities. The second subsection presents the challenges the POs described that they have had in practice.

Responsibilities of the Product Owners

In this subsection the Product Owners experiences regarding the three responsibilities that are connected to their role in literature are described: 1) customer involvement, 2) focusing on value and 3) making a vision.

Customer Involvement

The Product Owners that participated in the research worked with different kinds of teams, those that develop new features and those that work on infrastructure or measurements that other teams then use to build their features on. The Product Owners did agree that the teams should know who their customer is but they did not all find it their responsibility to identify those customers and their needs and communicate those needs to their team so that the teams are working on the most valuable tasks for the customer at any given time. Some felt strongly about it being their responsibility while others found it to be a team effort and not even something they should think about in their role. Some said that the PO should make sure that discussing the customer needs should take place within their team. Some of the Product Owners also tried to bring end user focus to their teams by pointing out that even though their team was working on a platform for an internal customer the team members still have to think of the end users as their customers.

As one participant said: "We [Product Owners] should represent the customers' interest, we are here to deliver something that users want to use and will love. Our success should ultimately be customers who love the product." But another one said: "I would say that both the Product Owner and the team have an input on what the users want, it might not be only the Product Owners responsibility to communicate that to the team but he should be the one seeing to that we know what are the customers' needs." One participant said that in a very broad sense this was his responsibility and in his daily work he talked to many people in the organization to find out where there are needs for his team to come in and work for other teams. Some of the Product Owners mentioned customer services as being their main connection to the end user. They felt that if the users are not happy with the software or the changes the teams are doing to it they should see that in the number of complaints from users and ultimately the number of users and take action if they were going down. Spotify's success should therefore be judged by numbers of users, if the numbers are going up the users are satisfied and vice versa: "Internally I play the devil's advocate; I try to empathize with the users and make clear to the team that everyone depends on us by asking questions like: If we brake something who will that affect?"

One Product Owner mentioned that his team tried to write user stories to understand their user's situation and figure out what their needs are. He believed that it is his responsibility to make the team focus on why the program or system is working on this specific task rather than another one but he said it can be a challenges as there are developers who are happy to continue writing software and not ship anything to the end user. He would like his developers to think of the end user and launch the software out to them as soon as possible: "For me the heart of agility is getting software to users and learning from them, listening to them and getting feedback fast and that's all there is to it."

Focusing on Value

Most of the Product Owners found it difficult to measure the value of the work their team was doing because often there was no transaction of money taking place. They tried to use measurements but the teams themselves did not always control those as they are mostly working for internal customers so it was hard to figure out what of the actual end value is generated from each team. As one Product Owner put it: "We see very little money here as Product Owners, it is strange but I don't concern myself with money at all actually."

Spotify tracks global user satisfaction usage for changes of the software but as the iterative changes to the software are so incremental it is difficult for the user to see them or know about them. So the Product Owners use the number of users as their main parameter of success. Then they try to build a dependency chain on metrics and work with hypothesis, for example if Spotify has more music they have more users, if users collect more music they will play more music, if users are able to find music easily they will collect more music and so on.

One participant said that it should be up to the team to deliver return on investment, not the Product Owner. He or she should just be the contact point for other parts of the organization to make it a bit easier for the team to work uninterrupted but in the best of teams the Product Owner is just another team member and the team as a whole sets the goals that then bring value to the organization. If the Product Owner tries to do it by himself chances are that the team will not buy into the goals: "You can usually see when the team has set the goals as a whole rather than the goals being delivered from someone else."

One participant said that his team did not measure return on investment in any way but verbal feedback from his internal customer was what he focuses on. His gut feeling was therefore his main form of measurement.

Making a Vision

When the participants were asked if they lead the vision of the product development for their teams most of them agreed that it was a difficult responsibility that they struggled with. One participant said: "I think it's important that the Product Owners sees to that the team has a vision, that they know what it is, but I don't think it is solely the Product Owner who creates that vision, I think that the team does that together but the Product Owner is responsible for that they have it".

The Product Owners do not always know what that vision is as the organization has been growing fast and the vision of a team tends to change relatively quickly: "Speaking completely openly it is something we are struggling with, this question of the vision and sharing it with the other teams because we are big and distributed. So how do you share that vision? I think we overcomplicate it at the moment and I think we just need an objective and should focus less on measurements."

Each team is encouraged to come up with five measureable goals each quarter, but one of the participants said that he does not like that because he thinks that often metrics are gamed, especially if they come from the top down. He would rather have a vision set at the top and then trust the teams and let them prove to the organization that what they are doing is moving the whole organization in the right direction. Another participant agreed on this, the Product Owner should provide a vision but said that somebody had to provide them with the organizational vision so that he is able to do that, the Product Owner cannot come up with the vision on his own. One participant said that he would like to think that he facilitates the visionary activities for his team. But he said that his team has a much better insight into the needs of the customers as the team is working much closer with them than he is. He does trust his team to have much input on the vision of the development: "I get a very fluffy high level overview but the team has very concrete details so I facilitate the vision but they provide most of it."

Another participant said he had a clear vision of how his product should be developed but the organization as a whole did not have a shared vision for the end product. He said his team starts to converge of this unspoken vision every two or three months so they sit down and take a conversation about it but they never write it down, their world is changing so fast that they do not want to put it in a document that is obsolete in a few weeks. Another participant involves others in the visioning activities but then he communicates the vision: "High-level vision for the company takes place in broad hall meetings. That's for the entire company and then I translate that into the reasons why we are doing the things we are doing now."

One participant said that his team works a bit with story mapping to try to figure out what the big items for the future could be but as their goals changes so quickly it is extremely hard to work on a long-term basis: "The longest project I've seen so far has been about a year. And the business landscaped has typically changed so much over time that at the end the product might not be quite right, good examples are the download store and the iPod integration which were a good idea at the time but when they were finally released it wasn't anymore. Over all we change the goals, what we prioritize, so often that it's hard to have a longer term vision."

Challenges of the PO role

Part of this study was to gather information on the challenges a Product Owner faces at Spotify.

One participant described the role as a combination of a diplomat adviser and juggler because there are a lot of voices with different needs and the Product Owner needs to communicate with all of them. The best way to do this was to be transparent so people see for themselves why things are done this way and not the other: "Be transparent because you are not going to please everyone all the time. As long as you are transparent about how you are doing things, how you make decisions and why certain things need to be prioritized over other things you will succeed."

It is the most challenging role on the team, said one participant, because there is ultimately more responsibility in the Product Owner role than in other roles in the team: "You have all those people wanting things from your team and for everyone what they want is very important and that is the diplomat part of the role. The team should be exposed to this pressure to an extent but the Product Owner should also protect the team from that. The developers need to know that they are not working in a vacuum, there are people who really care about what they are delivering but the Product Owner is also protecting them which makes it a more challenging role."

One participant said that the Product Owner role is challenging because even though the team is responsible for their delivery the Product Owner is in the forefront of that, the one seeing to that the delivery happens and it is compatible to what was initially planned: "I think that is a tough thing to have on your shoulders."

Being a Product Owner also means to align other people so that everyone has the information they need to do the right job at every given moment: "It's all about alignment and knowing what others are doing, you should not be working in isolation, it's very hard to do the right thing if you don't know what others are doing so the Product Owners are the ones who just make sure that we don't deviate on our own into what we think it is we should be doing."

Every Product Owner found it extremely important to spend time with the team every day, as much as they physically could to but some struggled with that as they worked with more than one team and had to attend to various meetings. Teamwork and collaborative decision making seem to play a crucial role in the work the Product Owner does with their team. The Product Owner is often guided by the team in what is technically right, so he has to listen to the team and take their advice on how things should best be done: "I'm there to represent the teams interest, fight their corner and to make their case. Just this week we said we're not going to make a release because the quality is not there yet. That message comes from me to the stakeholders but it is informed and guided by the voices of the team."

The challenge is also that the Product Owner has to be an indirect leader of the team, he has some authority to make decisions for the team but he very rarely wants to act on that authority and be the only one making decisions that affect the whole team and their work: "Product Owners are indirect leaders and many of them are totally inexperienced when it comes to leading someone. Especially if it's a junior team, so that is a big challenge for a lot of the Product Owners." The Product Owner has to get people excited and aligned so that they know what is expected of them without actually telling them: "The Product Owner is supposed to lead the team, engage and inspire it, make sure that things are moving forward but it is very artificial to have just one person that does that, the team itself needs to be interested in these kind of topics and discussions." And the challenge is also to see what is missing and add that to the mix: "I think the Product Owner role involves picking up the slack, so if something isn't working then it's clearly your Product Owners fault. Anything that is missing you'll have to pitch in."

Most of the Product Owners talked about the stakeholder side as being one of the most challenging parts of their role. It is difficult to motivate a team that does not know for whom it is working and lacks a purpose: "I think the special challenge is that we are not very often doing particularly exciting or glamorous parts of the development, we're providing a platform and keeping developers motivated around that is a particular challenge here. And focusing on the user value and remembering that we've not just got internal customers, we've got users as well." One participant said that his biggest challenge was to sell his vision of the development to the developers on his team: "The challenge is not only to sell the product to the end users but to sell the work that the team needs to do to the team. Both are important but if I have to order them it's selling the work to the engineers that is more important." Part of the role is to trust the team to do their job and leave them to do just that: "Part of our role is actually to back off, let people try things and trust them to do something interesting."

Communication was also mentioned as being one of the Product Owners' main challenge: "When the Product Owner is good at communication I see the teams do a really good job and when the Product Owner isn't good at communication the teams seem to struggle with what they should be working on." And it's not enough that the Product Owner is a communicative person but he also has to make other people speak to each other and see the big picture instead of focusing on their own task: "The more people talk to each other the more they realize that teamwork is important and they get more humble as they know what others are doing instead of getting stuck in their own corner of the universe."

All participants mentioned that they have come a long way and now find the role a bit easier than when taking the role. The challenges were often the same but in different situations and they feel they can use previous experience to handle them.

Discussion

The results show that all the participants are well aware of the responsibilities that are described in literature [5; 8; 15; 19] and all of them attend those in some way or another, although they have different approaches in their daily work to fulfil them. As described by both Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] and Pichler [START_REF] Pichler | Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series)[END_REF] the role is multi-faced, inward and outward facing and challenging. The results in this study show this quite clearly. Some respondents commented that they needed to have one foot in the daily work and one foot in the future and lead people to work on the right things at any given moment. Since Spotify has been growing during the past years it might be that the POs have to focus more on their inward facing responsibilities as Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] describes them, dealing with their own team on daily basis to make sure they are functional. The results indicate that when these challenges have been met the POs can look ahead to the future and start to focus on customer involvement, the vision of the product and the value their team is delivering as these are among the outward facing needs [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF].

At Spotify the role of the PO varies from one person to another. One aspect is that the POs have a very communicative role and the individuals in the PO role have different communication competences. An additional aspect is that the responsibilities of the POs are not necessarily the same in one part of the organization compared to another part of it.

The participants agreed that the PO role is often complicated and diverse and in some ways it can be hard to describe what the actual daily work is and should be. There are many tasks to juggle each day and the POs often felt that they were not delivering any visible work to the team or the organization.

The biggest risk for Spotify is building the wrong product, meaning that the product does not delight users or does not improve success metrics such as user acquisition or user retention [START_REF] Kniberg | How Spotify Builds Products[END_REF]. This is what is called "product risk" at Spotify. To compensate for this, the POs make sure that the customers (end users) are represented when the teams plan their work. Within the teams that build infrastructure or internal tools, there seems to be a lack of understanding of whether the concept customer includes the end user or not, that is if the teams should be focusing on the system from the users point of view or focusing on the customer, which ofter are internal managers at Spotify or other teams they are developing for. The end user is not always in the developers' mind when they are developing for infrastructure or measurement, we could say that the end user is somewhat invisible. There were examples of teams not knowing who their primary customer is. Helping the POs to identify their teams' customers would give the teams a better vision for the reason for why they are doing what they are doing and hopefully empower team members and make them more involved in defining the vision for the product. As the organization has different teams working for each other and a few are developing directly for the end user, the visionary activities are blurred. There are indications that strategic work is strong for the organization as a whole but that does not seem to help the POs with their vision for their specific product development and the communication of that to their teams.

As Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] states the PO should establish priorities so that the highest-valued functionality is always being worked on to maximise return on investment. The POs did not think about the value of the tasks their teams are working on and did not prioritize them according to return on investment, mainly because they don't have the right tools to measure the value of every task. It is also difficult to put a price on something you don't know how much effort is needed to finish.

Leading visioning activities for the product and communicate that to the team like both Cohn [START_REF] Cohn | Succeeding with Agile: Software development using Scrum (Addison-Wesley Signature Series)[END_REF] and Pichler [START_REF] Pichler | Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series)[END_REF] describe as one of the main responsibilities of the POs is what the POs all struggle with. It is difficult for the teams to focus on the big picture when they work on a limited amount of tasks each time.

This case study has contributed to the software development and project management literature by examining the PO role at Spotify. This is a complex role with both inward and outward facing responsibilities. Studying POs for three days might not give a generalizable picture of their duties, but the study gives an understanding of the POs responsibilities and challenges. The findings are interesting in regards to how the POs describe the complexity of the role, how it is much more of a leadership role than a manager role and how communication and people skills are crucial to the competences of a PO. The PO has to work closely with the team and as soon as the team feels that they don't have a clear vision of where they are going they start to drift of and become dysfunctional.

Conclusion

It seems that the PO role is as diverse in practice as the literature describes it and the challenges a PO faces each day are many as the results indicate. The POs need to have one foot in the daily work and one foot in the future and lead people to work on the right things at any given moment. The POs do not want to use their authority to make decisions for the team but they want everyone to be involved in the work and in that way the team should be able more productive and develop valuable products.

The PO is not a person who knows it all, as one participant put it: "I don't think the Product Owner is a magical person who has all the answers. You can give a steer on priority, you can help make sure we are focusing on customer value but you don't have all the answers."

In practice, the PO role seems to be much more of a leadership role than literature has indicated so far and it would be interesting to research the role in relation to the academic literature on leadership. The main challenge of the PO might therefore be to inspire and encourage team members communicate openly. If the team members are empowered and interested in their work the challenges seem to become much easier.

Acknowledgement

The authors would like to thank the participants and people at Spotify for the opportunity to do this research at their offices in Stockholm. Special thanks to Anders Ivarson who helped with arrangements and gave valuable comments on a draft of a thesis that this paper is based on.