Peter Forbrig

Alexandru Bundea

Ann Peder- Sen

Thomas Platz
email: thomas.platz@uni-greifswald.de

Digitalization of Training Tasks and Specification of the Behaviour of a Social Humanoid Robot as Coach

Keywords: Social Humanoid Robot, Human Factors, Interaction Design, Robot Assistance, Arrm Rehabilitation for Stroke Patients, Task Models

The number of physiotherapists and occupational therapists is not sufficient to cope with the demands of the increasing number of stroke survivors worldwide. These patients need specific training to promote recovery and prevent stroke-related disability. The paper discusses aspects how a social humanoid robots might serve as therapeutic assistant. It is not intended to replace human therapists, but to provide them with therapeutic assistance once therapeutic decisions are taken and the therapy has been introduced to the patient by the human therapists and the day to day practice needs to be supervised. The paper provides a case study of an HCD approach and exemplifies the strategy of digitalizing training tasks, the identification of exceptions, and ways of modelling the dynamic behaviour of the humanoid robot. This is demonstrated by task models. Some extensions of task models are suggested.

Introduction

Within the project E-BRAiN (Evidence-based Robot-Assistance in Neurorehabilitation; www.ebrain-science.de) we want to develop software that allows a humanoid robot to observe carefully selected training exercises. The project has the goal to support therapists by a new companion in the training of patients after a stroke. It was decided to follow a Human-Centered Design (HCD) approach that was adapted from Harte et.al. [START_REF] Harte | A human-centered design methodology to enhance the usability, human factors, and user experience of connected health systems: a three-phase methodology[END_REF]. To study the tasks and contexts is one of the first things one has to do. A stroke is a leading cause of disability [START_REF] Gbd | Disease and Injury Incidence and Prevalence Collaborators. Global, regional, and national incidence, prevalence, and years lived with disability for 310 diseases and injuries, 1990-2015: a systematic analysis for the Global Burden Disease Study[END_REF]. Brain lesions caused by stroke affect various body functions and lead to activity limitations and participations restrictions. Frequently, intensive specific training schedules are necessary to promote the recovery of body functions and reduce disability thereby. Platz and Lotze report in [START_REF] Platz | Arm Ability Training (AAT) Promotes Dexterity Recovery After a Stroke-a Review of Its Design, Clinical Effectiveness, and the Neurobiology of the Actions[END_REF] about the clinical effectiveness of specific exercises in cases when stroke survivors suffer from mild to moderate arm paresis causing focal disability, i.e. limitations of dexterity. A specific group of such exercises is called Arm-Ability Training (AAT) First, we will provide an overview of some of these exercises for post-stroke patients. Afterwards, the social humanoid robot Pepper is shortly introduced. This is followed by a discussion of digitalizing three of the training tasks with paper and paper. Models for specifying the collaboration between patients and therapists are discussed in the fourth section. In the fifth section we focus on modelling the collaboration of patients and therapists resp. humanoid robots. Some lessons learned from methodological and technological aspect are discussed in the six section before a summary with outlook follows.

Arm-Ability Training (AAT)

Arm-Ability Training has been especially designed to promote manual dexterity recovery for stroke patients who have mild to moderate arm paresis. Platz and Lotze report in [START_REF] Platz | Arm Ability Training (AAT) Promotes Dexterity Recovery After a Stroke-a Review of Its Design, Clinical Effectiveness, and the Neurobiology of the Actions[END_REF] about its design, clinical effectiveness, and the neurobiology of the actions. The idea of AAT goes back to the identification of sensor motoric deficits of stroke survivors in [START_REF] Platz | Prolonged motor skill learning -a combined behavioural training and theta burst TMS study[END_REF]. Fig. 1 provides an overview of the suggested training activities that are a result of previous research in [START_REF] Platz | Reliability and validity of arm function assessment with standardized guidelines for the Fugl-Meyer Test, Action Research Arm Test and Box and Block Test: a multicentre study[END_REF] and [START_REF] Platz | Best conventional therapy versus modular Impairment-oriented training (IOT) for arm paresis after stroke: a single blind, multi-centre randomized controlled trial[END_REF].

Fig. 1.

Training tasks of AAT (from [START_REF] Platz | Arm Ability Training (AAT) Promotes Dexterity Recovery After a Stroke-a Review of Its Design, Clinical Effectiveness, and the Neurobiology of the Actions[END_REF]).

The clinical effectiveness of the arm ability training was discussed in [START_REF] Platz | Arm Ability Training (AAT) Promotes Dexterity Recovery After a Stroke-a Review of Its Design, Clinical Effectiveness, and the Neurobiology of the Actions[END_REF] on the basis of two single-blind randomized controlled studies that included 74 patients. [START_REF] Platz | Best conventional therapy versus modular Impairment-oriented training (IOT) for arm paresis after stroke: a single blind, multi-centre randomized controlled trial[END_REF] were able to show is superior clinical effect on focal disability compared to therapeutic time-equivalent "best conventional" therapy.

However, the training is resource intensive because one therapist is necessary to observe and support the exercises of a patient. The idea arose to use a robot for assisting the patients. The robot is intended to provide instructions, provides feedback, be a motivator and suggest alternatives if something does not work well. It was analysed which existing kind of robot fits to the requirements of the arm ability training. As a result, the humanoid robot Pepper was selected for first experiments. A more detailed discussion related to humanoid robots can be found in Forbrig et. al. [START_REF] Forbrig | Using the Social Humanoid Robot Pepper for Training Tasks, 1st Workshop on Adapted intEraction with SociAl Robots (cAESAR), IUI 2020[END_REF] and [START_REF] Forbrig | Supporting the Arm-Ability Training of Stroke Patients by a Social-Humanoid Robot, accepted for IHIET-AI 2020 conference[END_REF].

3

The Humanoid Robot Pepper Pepper looks a little bit like child and has a very nice appearance. Most people like Pepper and smile while they are looking at the robot. Pepper can talk, listen, move the head and focus on people that he interacts with. His eye blinking simulates the blink of an eye of humans in a nice way. The robot can also blink with shoulders and ears. Additionally, Pepper can move its arms and fingers and is gesturing while talking. Even that he does not have real legs the robot can move around.

It is our assumption that patients can establish a good relationship with the robot. We assume that this is very helpful for the training tasks that are intended to support the functional recovery of patients. We want to use Pepper mainly to supervise highly standardized training sessions as instructor and motivator and like in [START_REF] Manca | The Impact of Serious Games with Humanoid Robots on Mild Cognitive Impairment Older Adults[END_REF] or [START_REF] Petersen | The Utilization of Robotic Pets in Dementia Care[END_REF] and try to find the appropriate feedback. Therefore, within our E-BRAiN project we are cooperating with psychologists and Professionals from health care management. They will analyse whether a humanoid robot as therapy assistant can acceptable for patients. It is, however, well possible that the approach is only helpful for specific subgroups of stroke survivors and specific types of functional training. It is one goal of our project to identify such groups and forms of training.

Robot-Supported Training Tasks

The goal of the project E-BRAiN is a combined therapy of human experts und humanoid robots. Background for any robot-supported training tasks are the assessment, goal-determination, selection of appropriate therapy, information and consent about any findings and plans with the patient and equally the introduction of the training tasks to the patients by a human therapist.

Accordingly, (human) therapists need to assess patients, explore the individual treatment goals, select, suggest and agree on the appropriate training, and introduce the training exercises to patients. They also need to supervise the first cycles of training performance. Once, this level of therapeutic care is achieved, there might be a role for a social robot to support additional largely standardized training sessions.

However, before this can be done, the therapist has to specify personal data and medical training specifications in detail. Additionally, personal goals of the patients have to be identified. Such a goal could be: "I want to play chess with my grandchildren again". Later in the therapy, these goals are used to motivate patients. Pepper can say: "Today your performance was very good. Soon you will be able to move pieces on the chessboard".

We learned from psychologist that individualized therapeutic goals are best expressed in a positive way, e.g. "I want to open a door by myself" instead of: "I do not want to ask for help if I to open a door." It is also known that training achieves the best results, when people are motivated. Psychological experiments showed for musicians who all trained the same exercise that training-related differences in changes of brain activation could be observed depending on whether the musicians were motivated or only forced to perform the exercises. Therefore, motivation seems to be one important aspect for training-related learning and hence presumably also for functional recovery post stroke. This is especially important, because success of the training tasks is only very slowly apparent after a large number of repetitions over a series of training sessions. Hence, there might be role for robot-supported training tasks once the level of routine day-to-day practice is achieved during therapy and the humanoid robot can help to assist training while supporting a patient's motivation at the same time.

Pepper has a lot of sensors. Nevertheless, it is sometimes very difficult to analyse manual tasks when performed with paper and pencil. Therefore, a digitalization of training tasks might help a lot. It was our idea to replace paper by tablets. Applications had to be implemented to allow the exercises to be done on those tablets. We will shortly present this approach for the three training tasks AIMING, CANCELLATION and MAZE TRACKING

Digitalization of training task AIMING

A patient has to hit circles of different size from left to right and afterwards from right to left (see left part of Fig. 3) that are placed perpendicularly. Next, circles located horizontally on the table have to be hit (see right part of Fig. 3. Circle at the button). This can also be seen from the digitalized version with two tablets represented in Fig. 4.

After ten perpendicularly presented circles are hit, connection lines between the circle at the button of the left part of Fig. 3 to all other horizontally presented circles have to be drawn. Once this is done a patient has to start hitting the perpendicular circles again.

A patient has one minute for this exercise. When a circle is missed the patient has to try to hit it again. The task AIMING has to be repeated four times (e.g. for times repeated practice over approximately one minute).

The goal of becoming faster while always meeting the precision demand of hitting both the smaller (more difficult to hit) and larger (easier to hit) targets affords continuously the adjustment of the motor behaviour, will only gradually be reached, and implies an underlying improvement of performance, i.e. motor learning. To implement the conventional AAT therapy manual procedure straight away would have triggered a verbal comment from Pepper that a circle was not hit in a correct way, if such an error occurred. However, we felt that it would be better since more direct, if the application on the tablet itself provides an appropriate feedback. In this way the robot is not considered as a kind of "opponent" because it has to provide corrective feedback. Negative aspects are related to the tablet.

We considered the following types of feedback for the task "hit the circle" on the tablet:

 The circle that has to be hit is blinking  Properly targeted circle becomes green  A specific acoustic sound will be provided for correct and incorrect hits Some of the suggested feedback are redundant. It will be evaluated in the future which kind of patients would like to have which feedback.

We are also yet not able to answer the question: "When should the robot take corrective actions?" Experiments with different versions of our application will show, which solution is appreciated by patients and which solution does not assist, but puts more pressure on the patients. Psychologists will help us to find the right solutions.

Digitalization of the Training Task CANCELLATION

Patients have to cross out symbols of O's. They are not allowed to put the arm on the table. The arm has to be moved freely in the air. Fig. 5 presents the tablet implementation for CROSSING. One has to start from left to right followed by the following line from right to left. Afterwards, crossing out has to be done from left to right again. At the top of the tablet one can see the remaining time (10 seconds) and the reached points (80). If the crossing out was done correctly the symbol gets a green background. If something was wrong, the background becomes read. In this case the attempt has to be repeated. Again, the robot itself does not comment on errors as a first instance. It only comments on exceptions like unexpected stop of the activities. Additionally, Pepper informs about the result and relates it to previous exercises. This is combined with some motivational sentences.

Digitalization of the Training Task MACE TRACKING

For the MACE TRACKING exercise patients have to follow the mace as far as possible in one minute without hitting its boundaries. The result is captured as the percentage of the correctly followed mace. 100 percent are the complete mace.

In case there is time left, a patient can start to follow a second labyrinth, but this time s/he starts with the opposite direction. In this case more than 100 percent can be reached.

Each mistake, touching or crossing the border, results in one second penalty. We discussed the preconditions for the observation of three specific training tasks. The support for further training tasks is under development. Some videos can be found on the website of [3].

Modelling Collaboration

In this paragraph we want to model the task model for Pepper, the patient in DSL-CoTaL [START_REF] Forbrig | A Textual Domain Specific Language for Task Models: Generating Code for CoTaL, CTTE, and HAMSTERS[END_REF], that is based on features of Buchholz et. Al. [START_REF] Buchholz | Extended Features of Task Models for Specifying Cooper-Activities[END_REF]. The DSL supports the specification of a team model that reflects the collaborative activities of the participants. The specification of Fig. 7 expresses that a training consists of a greeting part that is followed by the training (>>-enabling). Afterwards some ending activities have to be performed. In the greeting part pepper and the patient have to perform the task greet in any order (|=|-order independence). The role model of pepper and patient must have a task greet each. For the training pepper provides an introduction that is followed by the performance of the patient, which is an iteration that is finished by finishing the exercises. At the end pepper finishes exercises and in parallel (|||) the patient says bye. Currently, from our language DSL-CoTaL code can be generated to CoTaSE [START_REF] Buchholz | Extended Features of Task Models for Specifying Cooper-Activities[END_REF], to CTTE [START_REF] Paternò | ConcurTaskTrees: An Engineered Approach to Model-based Design of Interactive Systems[END_REF] and to HAMSTERS [START_REF] Palanque | Designing and Assessing Interactive Systems Using Task Models[END_REF].

Fig. 10 shows the generated CTTE model of the specification of Fig. 7. It would also be good to generate code directly for Pepper. To be able to do that some more specific language constructs like say(text) would be necessary. In [START_REF] Forbrig | Modelling the Collaboration of a Patient and an Assisting Humanoid Robot during Training Tasks[END_REF] we provide a little bit mor extended discussion about this aspect.

Additionally, we recognised a further problem: in the specification of the role model of Pepper. Sometimes Pepper has to ask: "Can we proceed?". This has to be repeated until a positive answer is given. Even for the case of maximal three repetitions, the task model becomes quite complex.

It would be nice to have iterations that can end with a certain condition like a repeat until statement in programming languages. Our language DSL-CoTaL will be extended in this way.

Fig. 11 gives an impression how the language could look like. The task asking is repeated until the task yes is performed. The result is presented by Fig. 12 . 6 Lessons Learned

Methodology

Following the HCD approach worked quite well. Therapists were interviewed, the artefacts they work with were analysed and videos of their work with patients were taped. Textual transcriptions were produced and evaluated. Specific events were extracted and highlighted. In this way, exceptions for our applications were identified. As example we can mention the exception that patients did stop the crossing out at the end of a line even when the instructions said that they should continue in the following line and all these lines were visible. We did not expect such a behaviour.

The therapist said in the case: "There is still time left. You should continue in the following line." We do the same now with our application. The tablet app throws an exception when no activities can be identified at the end of a line within three seconds and informs the robot. The robot says the sentences of the therapist.

Modelling the behaviour of the therapist, patient and the robot was useful to understand the domain. It also supported the communication with experts. Especially, the animation of specifications helped a lot to establish a common ground between all participants.

As we know already from requirements engineering, we recognized that communication between psychologists, sociologists, expert from medicine and people form computer science in natural language is very problematic. Requirements are sometimes very vague like: "The robot has always to say some motivational words". Neither is clear what the robot should say nor when. Modelling helped us a lot to be more precise and to understand the ideas of other people. Some ideas for further extending task model features were identified. Interaction will be the challenge for success [START_REF] Ahn | Social Human-Robot Interaction of Human-care Service Robots[END_REF].

Technology

We started to implement applets in java on the robot and on the tablets. Connection was realized directly via wireless local area network. Connection was often lost and applications had to start again.

Therefore, we used the Message Queuing Telemetry Transport (MQTT) technology [START_REF] Pulver | Hands-On Internet of Things with MQTT: Build connected IoT devices with Arduino and MQ Telemetry Transport[END_REF]. It was designed as an extremely lightweight publish/subscribe messaging transport opportunity for the "Internet of Things". MQTT was designed for lowbandwidth, high-latency and unreliable networks. Messages are sent via a server and it can be checked whether a message was received by recipient. If something went wrong, a message is sent again.

Using MQTT made our applications much more stable. We really recommend it for similar applications.

Having a stable message exchange established in our applications, we discussed the idea of implementing the behaviour of the robot externally. In this way, the robot has only an interpreter of messages that delivers the execution of commands. As a consequence, available technologies like knowledge management, machine learning or behaviour specification can be used without limitations.

The robot becomes something like a thin client. We have the impression that this software architecture facilitates digital implementation. However, we will investigate these aspects in more detail in the future. Alternative designs will be evaluated.

Summary and Outlook

The paper provides a case study of digitalizing Arm-Ability Training (AAT) for patients with mild to moderate arm paresis after a stroke causing focal disability. It was discussed how a social humanoid robot like Pepper can assist patients during AAT. Such a robot will play the role of a supervisor providing instructions and feedback, a motivator and supporter. Its application is restricted to highly standardized training schedules and excludes clinical decision making.

AAT training tasks need a digitalization to allow a smooth observation by humanoid robot. For three training tasks it was shown how training can be supported based on tablets and corresponding applications. It was shortly demonstrated how collaboration of patients and robot can be modelled by task models. Using a textual domainspecific language allows the generation of code for other tools that visualize the task models and allow their animation. A comprehensive domain-specific language (DSL) for robot actions will be a challenge for the future.

Currently, a data base is under development that contains user models of the patients. Beside general personal data and any individual details regarding the prescribed training, the data base has to store goals of the patients they want to reach. Such goals can be: "I want to be able to hold playing cards in my hands to be able to play with my grandchildren". The robot will refer to these goals in order to motivate a patient. In addition, medical data will be stored that characterize the ability of a person like data characterizing the degree of (lack of) dexterity as assessed with the Boxand-Block-Test or the Nine-Hole-Peg-Test [START_REF] Platz | Reliability and validity of arm function assessment with standardized guidelines for the Fugl-Meyer Test, Action Research Arm Test and Box and Block Test: a multicentre study[END_REF]. From the point of view of a computer scientist, they are a kind of metrics [19]. These data allow very individualized hints. We hope to be able to exploit these resources in the future.

We will evaluate in the E-BRAiN project which kind of patients accepts the collaboration with Pepper using our apps.

Fig. 2 .

 2 Fig. 2. Humanoid robot Pepper from SoftBanks Robotics [20].

Fig. 3 .

 3 Fig. 3. Manual training task AIMING.

Fig. 4 .

 4 Fig. 4. Digitalized training task AIMING.

Fig. 5 .

 5 Fig. 5. Screenshot from the tablet application.

Fig. 6 .

 6 Fig. 6. Example of a training task of MACE TRACKING on a tablet.

Fig. 7 .

 7 Fig. 7. Specification of a simplified Training collaborative model.

Fig. 8 .

 8 Fig. 8. Role model of Pepper. After greeting the training pepper has to wait until all patients (most of the time there is only one) greeted. First a short introduction is provided. In parallel to the talk two pictures are shown on the tablet of the robot that demonstrate important elements of the training task. Afterwards the patient is asked, whether the training can start. If ready, the robot says:"Please start" and later comments regarding the performance are provided. Finally, the robot comments on the results of the training.Fig.9presents the captured situation at the end of a task while Pepper says the number of reached points and presents a graph with recently reached results.

Fig. 9 .

 9 Fig. 9. Training Task CANCELLATION with presenting previous results by Pepper.

Fig. 10 .

 10 Fig. 10. Generated cooperative model for CTTE.

Fig. 11 .

 11 Fig. 11. Object specification and component with iteration. A modified version of the component (without the new language constructs) was used to generate the CTTE model for an instance of the generic component askingForStart with the two instance parameters "Can we" and "180" . tThe instance is created by askingForStart[Can we, 180].The result is presented by Fig.12

Fig. 12 .

 12 Fig. 12. CTTE model for instance askingForStart[Can we, 180].


Joakim Klemets
email: joakim.klemets@ntnu.no

Tore Christian

Bjørsvik Storholmen

Towards super user-centred continuous delivery: a case study

Keywords: User-centred design, Continuous software engineering, Agile development, Super users, Qualitative research

To develop well designed socio-technical systems for a particular context user involvement is essential. Emerging software development approaches that enable continuous delivery of software functionalities provide new opportunities as to how users can be involved in shaping the design. We present a case study of a software project at a Norwegian engineering and construction company in their effort to move towards a user-centred development approach that leverages on continuous delivery principles. We investigate how users-representatives in form of super users have been involved in the process and their role in forming and implementing the system in practice. We conclude that utilising super users have been instrumental to design a system that meet users' needs. Providing opportunities to test the system in a production environment gave rise to new ideas on how to further refine the design. Involving super users also facilitated system adoption among workers.

Introduction

To remain competitive in a challenging market many companies seek to make work processes and procedures more effective through developing and introducing new digital tools. However, to utilise the new technology it needs to be adopted and be taken into use. From a socio-technical standpoint, developing and introducing new digital solutions is as much about forming new work practices and routines as designing the tool itself meant to support work [START_REF] Bossen | Chapter 5 -Socio-technical Betwixtness: Design Rationales for Health Care IT. Designing Healthcare That Works[END_REF]. Hence, in enhancing the possibility of the tool to be accepted into practice one should ensure that it aligns with organisational goals and values. Scandinavia has a rich history of politically empowering workers to 'have a say' in shaping their own working environment [START_REF] Van Der Velden | Participatory Design and Design for Values[END_REF]. The Scandinavian approach to participatory design has therefore emphasized principles that are today central in user-centred design approaches [START_REF] Simonsen | Routledge International Handbook of Participatory Design[END_REF]. User involvement enhance user acceptance and ease system adoption through generating more usable solutions [START_REF] Ritter | Foundations for Designing User-Centered Systems: What System Designers Need to Know about People[END_REF][START_REF] Mumford | The story of socio-technical design: reflections on its successes, failures and potential[END_REF]. It has also been singled out as an important factor for project success [START_REF] Abelein | Understanding the Influence of User Participation and Involvement on System Success -a Systematic Mapping Study[END_REF][START_REF] Mohagheghi | What Contributes to the Success of IT Projects? Success Factors, Challenges and Lessons Learned from an Empirical Study of Software Projects in the Norwegian Public Sector[END_REF][START_REF] Bano | User satisfaction and system success: an empirical exploration of user involvement in software development[END_REF]. Although user involvement has received limited attention in software engineering [START_REF] Iivari | The user -the great unknown of systems development: reasons, forms, challenges, experiences and intellectual contributions of user involvement[END_REF], there is a growing interest in looking to combine user-centred approaches with existing system development methodologies [START_REF] Abelein | Understanding the Influence of User Participation and Involvement on System Success -a Systematic Mapping Study[END_REF]. In Particularly agile approaches been singled out as a good fit with user-centred design.

While agile approaches are commonplace today, more and more companies are also moving towards continuous delivery, where new functionality is delivered to actual users frequently. To be able to release new functionality into production more rapidly, the development and operations (DevOps) teams collaborate tightly to automate parts of the delivery process. Whereas there are little empirical studies on DevOps implementations [START_REF] Lwakatare | DevOps in practice: A multiple case study of five companies[END_REF], there are even fewer looking at combining a continuous delivery with user-centred principles [START_REF] Dittrich | Researching Cooperation and Communication in Continuous Software Engineering[END_REF].

We report on a case study carried out at a large Norwegian engineering and construction services company that through a digitalisation strategy seek to transform its ITdevelopment towards a DevOps and user-centred approach. The research objective is to investigate the transformation from a traditional and linear software engineering model towards an iterative and user-centric approach. Particularly, we zoom in on the end-user involvement and ask the following research questions: how are end-users involved in different phases of the process and what are the challenges? How do the endusers representant, or the super-user, role facilitate system improvement and implementation?

Background

User-centred design in agile and continuous software development

A number of scholars have discussed different perspectives on how to integrate agile and user-centred practices as a mean to produce more usable software [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF][START_REF] Salah | A systematic literature review for agile development processes and user centred design integration[END_REF][START_REF] Hussain | Current State of Agile User-Centered Design: A Survey[END_REF][START_REF] Tsd | User-Centered Design and Agile Methods: A Systematic Review[END_REF]. From a process perspective [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF], many scholars advocate having up-front design activities that seek to explore the problem space and possible design solutions before conducting any actual software development. To better adhere to the lean principles of agile practices, little design upfront is advocated [START_REF] Tsd | User-Centered Design and Agile Methods: A Systematic Review[END_REF], where whereas this phase often is more extensive in traditional user-centred design. One approach to implement design up-front is through carrying out usability studies one iteration ahead of the development [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF]. Kuusinen [START_REF] Kuusinen | A Framework for Organizing Within-Iteration UX Work in Agile Development[END_REF] argues that the approach, which usually separates developers and usability-experts into separate teams, prolongs the time to feedback, as well as risk wasting development resources on unusable functionality. Instead, she proposes a framework where cross-functional teams collaborate. First, through a short up-front exploration phase and later within the same iteration. And that feedback is collected continuously from end-users (Fig. 1). Continuous involvement of stakeholders is another central user-centred agile software development principle that has received less attention in form of empirical studies [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF]. Particularly, finding good ways to involve the end-user in the process is important [START_REF] Harris | A new look at the relationship between user involvement in systems development and system success[END_REF]. However, user involvement in the development is complex, and whom to involve, when, and how is not straightforward [START_REF] Iivari | The user -the great unknown of systems development: reasons, forms, challenges, experiences and intellectual contributions of user involvement[END_REF][START_REF] Bano | User Involvement in Software Development: The Good, the Bad, and the Ugly[END_REF]. Whereas user involvement in the requirements phase has shown to be effective [START_REF] Bano | User satisfaction and system success: an empirical exploration of user involvement in software development[END_REF][START_REF] Haake | Configurations of User Involvement and Participation in Relation to Information System Project Success[END_REF][START_REF] Kujala | User involvement: A review of the benefits and challenges[END_REF], studies also indicate positive effects of user involvement throughout the process [START_REF] Bano | User Involvement in Software Development: The Good, the Bad, and the Ugly[END_REF][START_REF] Bano | Users' involvement in requirements engineering and system success[END_REF]. Doing so can, for example, enable users to feel greater ownership of the system [START_REF] Bano | User Involvement in Software Development: The Good, the Bad, and the Ugly[END_REF] and, hence, enhance adoption.

Haake et al. [START_REF] Haake | Configurations of User Involvement and Participation in Relation to Information System Project Success[END_REF] found that it is central that a large share of affected users are involved in the implementation phase, as failing to do so could have negative effect on project success. Bano et al. [START_REF] Bano | User Involvement in Software Development: The Good, the Bad, and the Ugly[END_REF] reports that failing to identify motivated and positive user representatives also has negative effects. With regard to continuous software engineering (CSE), where new software functionality is realised frequently to the end-user [START_REF] Bosch | Continuous Software Engineering: An Introduction[END_REF][START_REF] Fitzgerald | Continuous software engineering: A roadmap and agenda[END_REF], data-driven approaches have been developed that automatically monitor system use and quantified user feedback [START_REF] Wüest | Combining Monitoring and Autonomous Feedback Requests to Elicit Actionable Knowledge of System Use[END_REF]. However, Johanssen et al. [START_REF] Johanssen | How do Practitioners Capture and Utilize User Feedback During Continuous Software Engineering[END_REF] who inquired 17 companies adopting CSE, found that the companies also collected explicit (i.e. written or verbal) user feedback in addition to passively collecting user metrics. Yet, the feedback context was mostly neglected, which made it difficult to fully utilise the collected feedback [START_REF] Stade | Feedback Gathering from an Industrial Point of View[END_REF].

Super users and design-in-use

Whether it is super user, power user, or champion user, the role goes by many names.

Hansen and Anders [START_REF] Hansen | Super Users and Local Developers: The Organization of End-User Development in an Accounting Company[END_REF] define super users as 'regular employees with in-depth knowledge of one or more of the organization's computer applications without being programmers'. Hence, skilled workers in their own field that also play a significant role as user representatives in system development, implementation, training, and support.

To be successful in this role, the super user should be positive towards adopting new technology, good communicators and be patient teachers, as reported by McNeive [START_REF] Mcneive | Super Users Have Great Value in Your Organization[END_REF]. The use of super users has also been studied within end-user development, where users are empowered to make own configurations to a system or through the close collaboration with developers and IT-professionals [START_REF] Hansen | Super Users and Local Developers: The Organization of End-User Development in an Accounting Company[END_REF][START_REF] Dittrich | End User Development and Infrastructuring -Sustaining Organizational Innovation Capabilities[END_REF][START_REF] Amá | Incomplete by Design: A Study of a Design-in-Use Approach to Systems Implementation[END_REF]. End-user development or design-in-use has been suggested as an alternative to traditional system implementation, which takes place once the design is finished. The design-in-use approach acknowledges the idea that implementation is context-dependant and tightly coupled with work practices and processes. Hence, once a minimal viable version of the system is ready to be deployed, end-users continue the design of both the system and associated practices [START_REF] Dittrich | End User Development and Infrastructuring -Sustaining Organizational Innovation Capabilities[END_REF][START_REF] Amá | Incomplete by Design: A Study of a Design-in-Use Approach to Systems Implementation[END_REF].

Methods

Research setting

The Mill Co.1 is a large Norwegian engineering and construction company specialised in offshore constructs that recently has initiated significant digitalisation efforts. The company operates mainly on two different sites within Norway. Whereas one of the digitalisation aims is to make existing work processes more effective through developing new information technology, it also aims to empower employees to take more control and responsibility of their work. One particular project that seek to do so is the CoConstruct project. The aim of CoConstruct is to build a mobile platform through which construction workers (welders, electricians, plumbers, etc.) and their foremen can use smartphones to access information such as work orders, plans, and documentation. It is also meant to provide a platform for team communication and allow real-time work progress reporting.

Mill Co. has an in-house IT-department that lead development projects and are responsible for operating and maintaining existing systems. However, the majority of the development workforce is hired on a project basis from another software engineering company with whom Mill Co. has a long-lasting collaboration. As part of the CoConstruct project, the development team also made the transition from using a traditional waterfall model to a more agile inspired approach, incorporating DevOps practices to release new software version to production roughly every 2 weeks. This meant that during the span of the project, the team had to acquire new skills, adopt new practices, and adopt new development tools (e.g. Azure DevOps). Further, the team also decided to incorporate user-centred design principles into their way of working by involving usability and user experience (UX) experts.

The entire CoConstruct project team consisted of a project manager, two UX researchers, a UX designer, a system architect, five front-end developers, and four backend developers. Further, platform architects specialised in existing production systems were involved to ensure system integration. Two experts in mobile platforms (Xamarin) and cloud services were also included in the development team.

A pool of super users was established from the beginning of the project, including 15 users from each construction site (a total of 30 super users). The super users consisted of both foremen and construction workers that represented different disciplines. Particularly, super-users that were curious about new technology and positive about the project were selected. The development team tried to ensure variety by including super users that were not so experienced with digital technology, such as smartphones, and recruiting super users of different age groups.

Research design

A case study strategy [START_REF] Yin | Case Study Research: Design and Methods[END_REF] was adopted to investigate the development team's processes and practices, as well as experiences of the ones involved in the CoConstruct project.

Particularly, we focus on how the end-user representants have been involved in the project and its implications. The case study lasted for about a year, between 2019 and 2020. The CoConstruct project was still active after the data collection ended. Within this time period we collected qualitative data through semi-structured interviews and a focus group with a variety of people involved in the project (Table 1). An interview guide was designed that covered the different project phases: context study, requirement analysis, development, testing and implementation. A separate interview guide designed for user representatives (super users). Seven of the interviews were recorded and seven were transcribed. For the remaining we made notes during the interviews. We also got access to documents and presentations providing information about the CoConstruct project and associated work processes. All data material was thematically analysed by both authors. The study has been approved by the Norwegian Centre for Research Data (NSD) and informed consents was collected from study participants.

Results

User involvement in the development process

A high-level overview of the development process is illustrated in Fig 2, which also highlights where and how in the process users were involved. An up-front context study phase initiated the process (1), which was followed by requirement analysis (2), development (3), test/deploy (4), release (5), and implementation [START_REF] Abelein | Understanding the Influence of User Participation and Involvement on System Success -a Systematic Mapping Study[END_REF].

Fig. 2. User involvement in the development process

Context study. The first project phase was undertaken by a separate UX team, an assembly of 2 UX researchers, a UX designer, the project manager and a system architect. The aim was to gain an understanding of the context of use and user needs by investigating current tools, processes and practices at both sites. The UX team conducted data collection that lasted for 2-3 days, for each site, and included activities such as workshops, shadowing observations, interviews, as well as utilising WhatsApp2 and disposable cameras as cultural probes [START_REF] Gaver | Design: Cultural probes[END_REF]. The use of WhatsApp groups made it possible to collect great amounts of photos and live data, where workers described their work situations and the work environment. This activity continued after the team had left the sites, and was, according to the team members, particularly useful to collect data from the site that was located geographically distant from the development team. Based on the collected data, the UX team developed a timeline experience-map presenting activities and interactions between workers, as well as challenges and opportunities for new technology. The workers were invited for a co-creation session (same people that was shadowed), where they were encouraged to further refine the experience-map (Fig. 3).

Requirements. The UX team that figured in the context study phase, collaborated closely with the super users to write an prioritise initial use-cases in the subsequent phase. In order to make more accurate prioritisations, the UX team tried to understand how valuable a use-case is from both a user and business perspective. The team also aspired to estimate the technical complexity of implementing a certain functionality. A team member explained that 'a use-case could be very relevant, but if it would take four months to deliver the functionality it was assigned a lower priority.' This process led to the selection of 14 use-cases. The selected use-cases were presented to super users at both sites and to a steering-committee. The super users were also asked to individually prioritize the use-cases in an Excel-spreadsheet, which led to 6 more use cases being added.

Based on these use-cases, the UX team initially developed wireframes3 for the first planned features. Later the UX team created clickable prototypes as well. To get feedback on these early designs, the prototypes were presented to super users.

Development.

To hand over the initial system requirements to the development team, a 7-day kick-off workshop was held where the UX team presented the selected use cases. Initially a total of 60 features were examined to estimate a total development time for the project.

The development was carried out using a Scrum-influenced approach with a 2-week sprint interval. Two separate teams worked in parallel iterations but delivered functionality as one unit. If one team ran out of tasks within a sprint, it assisted the other team if suitable resources were available. The teams held daily 'scrum-talks' and review meetings after each sprint. Both UX experts and the developers involved in the initial UX team was also part of the development team, which allowed the team to more fully take advantage of the experience gained from the previous phase in the development.

Test, deploy, and release. At the end of each sprint, the development team arranged a meeting to present the newly developed functionality to the super-users, and to run a user acceptance test (UAT). The super users participated either on site or through Skype. The number of participants varied; some participated every time while others participated less frequent. During the UAT the super users installed a test version of the CoConstruct application on their smartphones and were handed individualised test scripts to carry out during the session.

The aim was to discover potential bugs and to prioritize these in different categories according to severity. Identified defects and issues were entered into the development backlog. After this session, the super users were provided the opportunity to use the application for two days and report feedback. If still no major issues were found after the 2-day period, the application was released to production, making it available for everyone. After the release, feedback was generally collected by superusers and communicated to the development team at the following UAT meeting.

Implementation (training, support, and dissemination).

To support the implementation and adoption of the CoConstruct application among construction workers and foremen, the development team are establishing web-based training courses. A separate department of education at Mill Co. was also prepared to train smaller groups in how to use the application. The project manager told that they are monitoring various use statistics, which is used to more easily identify departments that possibly are in need of additional support and training.

The CoConstruct project has also developed user manuals presenting core functionality of the application to educate users. The project group have been sending out newsletters on email to keep people informed and presented teasers on information screens in the canteens, reception, etc.

Reflections on the development processes

Involving super users. The CoConstruct project ensured user involvement by establishing a pool of super users. Some were recruited from the beginning of the project; others were onboarded later. The main idea was to involve the same users throughout the project for discussing and validating needs, desires, requirements, and solutions. They were also responsible for collecting and forwarding feedback from colleagues.

Dual roles. The super users interviewed were generally pleased with their role in the process, and some took great pride in participating. The super users admitted that the additional role sometimes caused stress due to the extra workload. The project manager suggested the possibility of rotating the super user role with others. He told: 'I believe some of them still want to continue as super users, but some are maybe getting tired.

They have spent a lot of time on this.' However, having a management that support and understand that the super user role will reduce time devoted to 'regular work' was considered important. As a super user explained: 'it has worked out nice to have the super user role in combination with regular work. The management understands that I spend time on this. This is no problem in my department. And I'm also passionate about making this work'. Further, having both a foreman and a construction worker from each construction team involved as super users was described as valuable, as it enabled them to support each other.

Super users' role in dissemination and training.

According to the project manager, superusers main responsibility was to be involved in the development and to provide feedback back to the development team. In addition, the superusers were also expected to serve as 'ambassadors' for the CoConstruct application. As well as to provide some support to their work colleagues. But providing training was not part of their responsibility, the project manager explained.

However, super users from two of the construction teams involved in the study (three in total) reported that they were very engaged not only in advocating use, but also in training their colleagues in how to use the system. The superusers in these teams were very active in taking the application into use at their workplace, which was done on their own initiative. One of these teams' strategy was to hold training sessions with groups of 3-4 people at a time. They preferred smaller groups that allowed for closer interaction as the users try out the application and ask questions during the session.

For people that were not used to smartphones, or otherwise resistant to new technology, they held individual training sessions. The interviewed superuser explains: 'there has been resistance among some individuals that do not want to use digital tools, that find it difficult. We have taken these aside and gone through and thought them one and one. Walking through and repeating the tasks that the person should carry out. And at the end things have went fine.' The superuser continues, 'One-to-one walkthrough is the best way to achieve this. If you take them on one-to-one, they become a bit more comfortable with the situation, and you can explain it to them slowly, and then they understand it better. A lot of it is about lack of knowledge and insecurity. If you do this one-to-one much of the insecurity disappears.' Feedback from test and production versions. Within the span of 1,5 years, about 30 new production versions of the application were delivered to the users. Whenever a new version of the CoConstruct application had been finalised, it was made first available as a test version only for the super users. The super users said that the initial test version they got was mainly checked for major flaws regarding the applications user interface and functionalities. And most of the times, the test version was accepted by the super user without any complaints.

However, releasing the version into production meant that the application also could be tested by a larger number of users, and in a real work context. Hence, how well the new features align with work practices, and the influence of a new version on work efficiency could be scrutinised more thoroughly. The super users told that is was during this phase (after production release) that most major issues with the application emerged. And that issues became much more visible once a lot of people started complaining or simply stopped using the application.

One super user said that the feedback typically came after using the application for a while and when people had been facing the same challenges over time. He explained: 'in the beginning, there are often few people who give feedback, because they haven't been annoyed enough about it. But as time went on, people stopped using the mobile to report progress. Because it took too long compared to just ticking off the job package, like you did previously. It's mainly when many people use it that you get feedback. When you face the same problem as your colleagues'. Similarly, both the super users and the development team anticipated that the application would improve as the user base grows, which meant more feedback on how to improve it.

Another super user also suggested to speed up the feedback process when facing critical usability issues. The super users were supposed to report feedback in the following UAT meeting, which could be sometimes a month away. Considering development time, it could take a significant amount of time before the workers had an improved version available. When asked about how the process could be improved, he told: 'maybe not having to wait for another UAT meeting to address critical issues we had. It took a few extra weeks to fix the problem as well, and I noticed that the motivation to use the app was very low at that time. We should have contacted the team directly and said that this must be fixed'. The super user regretted that he had not used more effort to get the development team to resolve the issue more quickly, saying: 'I should have pushed them regardless'. A similar story is also shared by another superuser, where a software update led to that operators went back to 'doing it the old way'.

The project manager also told that they could have spent more time with the users to identify their daily challenges. But he admitted that it is challenging to know how to allocate available resources. He said: 'we should have been more visible at the construction area to follow up on daily challenges, but this is challenging. Should you spend time developing or should you focus on follow-ups and support?' Screening of feedback. Currently the CoConstruct application has approximately 500 unique (not necessarily active) users. This generates an amount of feedback that the developers find hard to process. The feedbacks include either bug fixes, suggestions for new functionality or suggestions on how to improve existing functionality. The team has been considering how they should screen and prioritise the feedback more effectively. A member of the development team explained the dilemma: 'the more users you get, the more feedback you get. Huge amounts of feedback. And it's only positive that you get lots of feedback, but how do you screen it? How can we ensure that what ends up on the backlog is what the company actually need, and not just what users want. We need to look at this. How can a screening be conducted?'

The CoConstruct members are discussing if the construction department, the owner of the CoConstruct application, should establish and own a kind of 'change forum' where they discuss and screen incoming feedback. They already have existing arenas where different representatives meet and discuss topics related to work improvement, and the CoConstruct application could be a natural part of this, the project manager explains.

The benefits of involving super users. The people involved in the CoConstruct project found the involvement of super users in different phases very useful. An informant from the CoConstruct project said that the user-centred approach was highly appreciated by super users as it allowed them to have genuine influence on the system design. One from the development team explained: 'some of them stated that they felt heavily involved for the first time. This led to two great benefits; firstly, we got involvement from the users, and secondly; the word started spreading about what we were doing. The users were also feeling that we are working hard to adapt the app to the way they work'. This is also reflected by the super users, as one them said: 'the development team are very eager and want to hear what we think is needed and not. We've been listened to'.

Super users reported that the CoConstruct application provided benefits to both construction workers and foremen. Particularly, in terms of increased work efficiency and empowering operators to further take control over their own work progress. As a super user said: 'I notice that many engage in reporting work progress using the app. You can see your own work progress and completion. Then it is more enjoyable to do the work. I think it makes the workers feel that they own their work'.

Both super users and developers appreciated the use of visual tools prepared by the UX teams when discussing different solutions. The visualisations made it easier for users to understand the product and share their opinions. They also explained that the experience map, for example, helped to them establish a mutual understanding of the wider socio-technical system, not just the application. The wireframes and clickable prototypes were also highly appreciated by the developers. As one developer said: 'It is a lot easier to us programmers to talk about solutions when you see a UX design, rather than just reading text. I've been in the business for 10 years, and so far, I've never seen UX been used as a basis to development. It has often been a "developer design"; a design solution that the developer feel is a good design'

Discussion

A continuous delivery approach to user-centred system design

The super users had a central role as user representatives when the development team has taken its first steps towards a more agile and user-centred approach. Whereas the Mill Co. has a long tradition of utilising super users, they have not been involved in the development process to a similar extent before. Contradictory to agile principles, the CoConstruct project began with a rather extensive design up-front phase, in which super users were involved in defining the final system requirements that yielded a large initial work package.

While up-front discovery activities are recommended in the context of user-centred agile software development, there is a lack of knowledge regarding the recommended extent of this phase [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF]. In the CoConstruct case study, further development and refinement of the application was needed even after a majority of the initial use cases were implemented, which led to the project contract being extended several times. Particularly, delivering production versions continuously enabled users to identify application features that was not suited to their work, which led to additional backlog entries. In this respect, continuous delivery provides mechanism that could be aligned with a design-in-use approach.

Although issues related to system implementation is often discussed within information systems research [START_REF] Iivari | The user -the great unknown of systems development: reasons, forms, challenges, experiences and intellectual contributions of user involvement[END_REF], it should perhaps also take a larger role in software engineering. In particular, as when moving towards continuous software engineering the boundaries of implementation and development gets blurred. While super users had an important role in influencing the system design in this project, they also were integral to the application being adopted. Some even voluntarily committed to arranging training and extended support for those struggling to take the digital leap. To ensure continues software engineering that produces useful, usable, as well as used software, one perhaps need to take a more holistic approach [START_REF] Forbrig | Does Continuous Requirements Engineering need Continuous Software Engineering? 3rd Workshop on Continuous Requirements Engineering[END_REF]. Skilled workers continuously configure the socio-technical systems they are part of through working around technical deficiencies to enhance work efficiency [START_REF] Cabitza | Drops Hollowing the Stone": Workarounds as Resources for Better Task-Artifact Fit[END_REF]. A continuous, user-centered system engineering approach could allow them to re-design also the technical part of the system to support such workarounds as these occur.

The approach adopted in the project somewhat reassembles the framework proposed by Kuusinen [START_REF] Kuusinen | A Framework for Organizing Within-Iteration UX Work in Agile Development[END_REF] in that development was carried out in multidisciplinary teams collaborating within the same iteration. However, the rather long feedback loop after a crucial deficiency was identified by the user was a significant bottleneck. This issue is interwoven with the question on how to screen a large amount of feedback to rapidly identify issues that matters the most. In addition to an enhanced dialog between users and developers implemented, for example, through a change forum, a more systemised approach to collecting feedback could be developed [START_REF] Stade | Feedback Gathering from an Industrial Point of View[END_REF]. This could include combining descriptive contextually rich feedback with quantitative metrics of application usage. If issues related to a specific version for a specific department is detected early on, a simple version rollback could be instantiated for a limited group of people [START_REF] Agarwal | Continuous and Integrated Software Development using DevOps[END_REF].

Study limitations

Through a triangulation strategy, in which multiple data sources have been utilised and both authors being involved in the data collection and analysis we have sought to enhance research validity. Our prolonged involvement could also reduce respondent bias. A large part of the qualitative data was also recorded and transcribed to reduce researcher bias. However, due to time constrains not all interviews were transcribed verbatim. Another limitation of the study is the small number of involved super users. Further, as access to super users was managed by through a gateway inside the company, it is uncertain whether the selection was representative. While, there has been reported issues with adoption of the CoConstruct application at some departments, this was not the case at the departments of the super user that we interviewed. Whereas the user-centred approach investigated in this study mainly focus on usability and system adoption, there are several other aspects such as, business strategies, security and privacy that need to be considered when developing and implementing ITsystems in an organisation. To this end, end-user involvement might not be sufficient, but participation of experts in other domains need to be included. However, we consider this as future work.

Conclusion

Through a case study we investigate how end-users representants are involved in the software development process and their influence on system design and adoption. The study shows that super-users have been central in forming the developed system according to their needs. Continuous delivery of system functionalities provides an interesting opportunity for end-users to further shape the system design along with work practices. This allows considering also aspects of work that often is overlooked in upfront design. Super users also had a central role in system adoption, taking on a role as ambassador, providing training and support to their fellow work colleagues.

Fig. 1 .

 1 Fig. 1. The BoB framework [16].

Fig. 3 .

 3 Fig. 3. Workshop participants discussing the experience map.

Table 1 .

 1 Data collection occasions.

	Participant(s)	Data collection method	Duration
	Project manager, 1 developer, 1 UX researcher, 1 test engineer	Focus group interview	1,5 h
	Developer	Interview	1 h
	Test engineer	Interview	1 h
	UX researcher	Interview	1 h
	Project manager	3 online interviews	2,5 h in total
	4 super users from 3 different	4 separate online interviews	30 -45 min for each
	construction teams.	with each participant	interview

To preserve the anonymity of the people involved we use fictional names

A mobile messaging application

Non-interactive prototypes illustrating the applications user interface


Jose Barambones
email: j.barambones@upm.es

Xavier Ferre
email: xavier.ferre@upm.es

Elena Villalba-Mora
email: elena.villalba@upm.es

A scrum-based development process to support co-creation with elders in the eHealth domain

Keywords: Agile User-Centered Design, Experience report, eHealth, Elder users

Since the publication of agile manifesto in 2001, agile methodologies has been gaining significant interest in both software industry and research community. Agile User-Centered Design (AUCD) assesses the challenge of integrating agile development with user experience and usability techniques. Although both methodologies have similarities, their scope and perspective are different and difficult to integrate. The eHealth domain implies additional challenges in terms of usability, due to the differences between healthcare professionals, and lack of knowledge of the day-to-day work carried out in different care tiers. Therefore, the challenge is twofold: to achieve an adequate symbiosis of work between teams, and design a solution adapted to the needs of diverse stakeholders with vast differences in their context of use. We designed a lightweight AUCD process adapted to such situation, and we present our experience in the design and implementation of such development process for the development of a system to monitor frailty in elder patients with support for both community and specialized care. As a result, our UCD process has achieved both iterative and incremental value generation, maintaining a good coordination between developers and UX designers, and resulting on a usable solution with regard to target users.

Introduction

Scrum is an agile process framework for software development aimed to address complex adaptive problems, while productively and creatively delivering products with the highest possible value. Scrum teams are subject to a series of roles, rules, events and artifacts; and orchestrated through a set of well-defined relationships and interactions between them [START_REF] Schwaber | The scrum guide[END_REF]. In an agile process, development is organized into a series of short and fixed-length iterations or sprints. The outcome of each sprint is a tested, integrated, and executable partial system, including its own requirements analysis, design, implementation, and testing activities. The system grows incrementally with subsequent iterations, becoming an incremental development [START_REF] Larman | Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)[END_REF].

User-Centered Design (UCD) includes activities such as the specification of the context of use and the user requirements, producing design solutions, and evaluating them against such requirements [1]. UCD is inherently iterative to cope with the uncertainty of the human part in the human-computer interaction. Each iteration includes some kind of usability evaluation of the produced solution that determines if it is required to perform a new iteration, but repeating only the UCD activities that require some refinement.

Integration of UCD into agile approaches has traditionally found obstacles related to the lack of usability awareness and the different focus of Human-Computer Interaction (HCI) techniques compared to other development activities. The Agile User-Centered Design (AUCD) approach emerged to address these problems [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF][START_REF] Hussain | Current state of agile user-centered design: A survey[END_REF][START_REF] Hussain | Investigating agile user-centered design in practice: A grounded theory perspective[END_REF][START_REF] Silva Da Silva | User-centered design and agile methods: A systematic review[END_REF]; however, although scrum is considered a lightweight process easy to adopt, the integration of UCD with agile methods remains challenging. The agile Manifesto3 focuses directly on providing value as functioning software for the customer, whereas UCD aims for a proper understanding of users and their context to take design decisions according to their goals and expectations. Extensive user research activities, necessary for proper UCD, can be identified as big design up-front from an agile perspective, that defends having running software built from the very beginning. Both methodologies coincide in the need for and iterative approach and handle requirements and uncertainty in development from different approaches, either by integrating the client needs as the product owner or the objective user. However, there is a need to fit UCD activities into the overall agile process and to define how UCD findings drive redesign efforts in the software product.

Participatory design methods from UCD need to take into account technical and resource constraints. In our case we need to add the difficulties of applying UCD in the eHealth domain. User experience research with healthcare professionals show that they prioritize the medical error reduction to avoid unforeseen or harmful decisions to patients [START_REF] Ash | Some unintended consequences of information technology in health care: The nature of patient care information system-related errors[END_REF][START_REF] Kushniruk | Technology induced error and usability: The relationship between usability problems and prescription errors when using a handheld application[END_REF]. Accordingly, special effort is required for understanding and designing for all stakeholders. Healthcare professionals are a scarce resource, and it is difficult to have them continuously as part of the development team, as agile approaches suggest. From the patient perspective, user satisfaction is critical to preserve his/her engagement and ensure proper adherence to treatment. Designing any software product for elders requires considering their possible limitations in technology background and physical and cognitive abilities. These limitations linked to elder users require the consideration of specific usability guidelines.

We present in this paper the instantiation of an AUCD software development process for the development of a telemedicine system to monitor elder patients with risk of frailty, merging a scrum-based approach with co-creation UCD ac-tivities. We extract measures from both scrum and usability metrics to discuss how the process fulfills the project objectives.

Related Work

With regard to AUCD adoption, Brhel et al. conducted a literature review on agile and UCD integration techniques, resulting on a foundation based on a set of principles, such as to merge effectively iterative and incremental development, and continuous stakeholder involvement, among others [START_REF] Brhel | Exploring principles of user-centered agile software development: A literature review[END_REF]. Fox and Ferreira defined different approaches to integrate agile methods with UCD and compare them in respective study cases with experienced software teams from industry [START_REF] Fox | Agile methods and user-centered design: How these two methodologies are being successfully integrated in industry[END_REF][START_REF] Ferreira | Values and assumptions shaping agile development and user experience design in practice[END_REF]. Garcia et al. identify through an ethnographic study the artifacts used to facilitate the communication between designers and developers in an AUCD approach [START_REF] Garcia | Artifact-facilitated communication in agile user-centered design[END_REF].

Apropos of development and design for ageing, Ruzic et al. designed a set of guidelines to ensure usability of mobile eHealth devices by elder based on design principles from literature: universal design, design for aging, universal usability, and guidelines for handheld mobile interface design [START_REF] Ruzic | Development of Universal Design Mobile Interface Guidelines (UDMIG) for Aging Population[END_REF]. Lerouge et al. investigate how User Profiles and Personas techniques improve the design and development of consumer health technologies and devices for an aging population [START_REF] Lerouge | User profiles and personas in the design and development of consumer health technologies[END_REF]. The study provides guidelines to tap into the conceptual models of elder population to reflecting their preferences and capabilities, but user motivation and adherence is considered superficially.

Context

Elder-associated conditions, e.g. frailty, and other health-related conditions are becoming a huge challenge to the sustainability of healthcare systems. Concretely, frailty condition is an intermediate state in the ageing trajectory, preceding the onset of disability.

POSITIVE project (maintaining and imPrOving the intrinSIc capaciTy Involving primary care and caregiVErs), funded by EIT Health, proposes a new organizational ecosystem to manage frailty, based on the basic model centered into the Geriatric Comprehensive Assessment (CGA) detailed in [START_REF] Sánchez Sánchez | Integrated care program for older adults: Analysis and improvement[END_REF], but extending it to primary care professionals to allow for a closer contact with patients and their caregivers. This project implies the participation of health professionals at different levels (nurses, general practitioners, geriatricians, physiotherapists, occupational therapists, etc.), patients and their informal caregivers. The system allows professionals to carry out CGA in clinical settings and to remotely monitor patient's intrinsic capacity and prevent frailty through tailored intervention in community dwellings. Figure 1 shows the POSITIVE services offered through the developed platform. In a nutshell, POSITIVE system is composed by three main components: the professional app, the patient app, and the support ruled-based engines. Through the professional app healthcare professionals manage their activities such as patient monitorization, messaging and gathering patient data during clinical visits. The patient app includes the functionality to assist and assess in a remote manner the patient intervention at dwelling. The rule-based engines are a sever-side service that receives patient data from clinical visits and home activities. Later, the engine analyzes the data to support care professional decision process for referring to specialized care professionals. Co-creation activities defined and refined the screens of the Patients Dashboard (figure 4), New Visit, and Home activities (figure 5), and served for defining the rules of the side support components (alerts and referral engines).

AUCD process proposal

The project team is composed by two sections: Development (Dev team) and User eXperience (UX team). The UX team deals with user research and is responsible for the high-level design of the solution, through co-creation activities, while the Dev team is responsible for the implementation and software testing activities. A set of healthcare professionals participate in co-creation activities as a relaxed case of product owners. These participating stakeholders are exempt of backlog/project management, though the UX team acts as spokesperson for the users in the generation of the backlog, collaborating with the Dev team in such purpose.

Figure 2 shows the deployed AUCD process for the POSITIVE project. Subteams possess their own work pipeline, where each team processes the data from the other team at the previous iteration. Accordingly, the Dev team performs a scrum sprint given the backlog generated, whilst the UX team works in the design of the following iteration in co-creation activities. Prototype validation, design, and refinement are performed over subsequent releases, thus both iterative pipelines converge onto an incremental development. The following subsections describe the iteration process and its activities.

Sprint iteration

Figure 3 describes the activity flow over a single iteration from figure 2. As mentioned above, the sprint receives the design requirements and works over the last deployed release. In other words, the backlog from current iteration is generated and updated from design results obtained on the previous UCD iteration. As output, a new release is deployed and a new set of design requirements from co-creation and usability tests are delivered. In this way, development activities can be parallelized with the next design iteration. Indeed, this flow enables both teams to be coordinated through different meetings, appointments and common activities in such a way that ongoing decisions are made with up to date information. Team dailies are held with the entire team allowing for the status of both teams to be effectively shared and coordinated.

Kick-off: Previous work consisted on extensive user research activities, including observation at the Geriatrics Unit of the University Hospital of Getafe and semi-structured interviews with key stakeholders [START_REF] Sánchez Sánchez | Integrated care program for older adults: Analysis and improvement[END_REF], followed by several iterations of prototypes for the UI of the system to support the CGA carried out by geriatricians. The overall POSITIVE ecosystem, including primary care professionals, was designed at time of project proposal, so when the actual development started there was a clear product concept defined, even if the prototypes were outdated and needed to be considered from scratch due to the new organizational model implied in the project.

UX activities

Co-creation: Co-creation activities can effectively involve different stakeholders on design decisions, revealing hidden requirements and restrictions which may be difficult to identify otherwise. Based on participatory design principles, they are aimed to understand properly the potential users of a product, to identify the real context of use, and to ensure that the proposed design actually fits both users and context [START_REF] Jansen | The 7 Principles of Complete Co-Creation[END_REF].

Co-creation requires users to be actively involved in the design process. The aim of the scheduled co-creation sessions was to define the context of use through activities where stakeholders are actively implied. In our case, we have used two methods: focus groups and pluralistic walkthroughs. A Focus Group is a qualitative research technique that is specified as a meeting of potential users where participants give their opinion about one or more topics [START_REF] Krueger | Focus Groups: A Practical Guide for Applied Research[END_REF]. The most interesting output of this technique is the debate created between the participants, as this forces them to defend, argue and justify their ideas, and then to externalize their real mental model. Having a total of 15 primary professionals and 5 geriatricians participating in the co-creation activities allowed us to uncover different viewpoints and lack of knowledge about how other care tiers work. A single product owner would have not been able to provide enough information for such a complex care ecosystem. A pluralistic Walkthrough is a usability inspection method where stakeholders, including users of any role, designers and developers revise the design. This helps specifying in detail the tasks that must be developed from different role-perspectives and brought together [START_REF] Bias | The Pluralistic Usability Walkthrough: Coordinated Empathies[END_REF].

Hi-Fi prototyping: The early design output is generated from co-creation decisions. The Hi-Fi prototype is extended with that output, in such a way that design becomes incremental along the iterations. Subsequent usability testing the generated prototypes allows for the required design refinement. Figure 4 and 5 show some prototypes used later in UX activities. Requirements and tests: From co-creation activities, requirements are collected according to the professional knowledge and their mental model. This data is formatted into documentation for the dev team in different assets. The Hi-Fi prototype validated by stakeholders through co-creation activities embodies the system requirements. Such source of requirements include the set of acceptance tests for the subsequent evaluation. Requirements and tests are translated to simple input/output tasks or user stories with pre/post conditions and attached test cases. Such tasks are classified by story points from scrum estimation. In our case, the difficulty emerges given a backlog that is increased with new features or epics in further iterations. This implies that the estimation and priority can only be done with the information of the current iteration plus the remaining undone tasks. To overcome this, co-creation activities were scoped in initiatives or big epics, in such a way that iterations are differentiated, dependencies are minimized, and to ensure the critical tasks from each epic are prioritized.

Evaluation: Usability tests were performed with community and specialized care professionals, and with elders in their homes. During testing, participants were asked to complete typical tasks while observers watched, listened and took field notes with the aim of identifying usability problems, collecting qualitative/quantitative data and determining the user satisfaction. Quantitative results were collected using System Usability Scale (SUS) questionnaires, while qualitative findings were gathered through deep contextual interviews. The Think Aloud protocol was used for the usability tests to collect qualitative data allowing to explain when and why errors were made, and to identify the reasons for the user problems.

Dev activities

Development environment: The Dev team follows the Dev-QA-Prod pipeline. The Dev environment is used to code new features, to perform functional tests, and to fix bugs. The process is iterated until the code is ready for the next stage of testing. The quality assessment environment (QA) is used for testing by the UX team and domain experts carry out heuristic usability evaluation, with redesign decisions reported back to the Dev team if necessary. The end-user release is deployed in the production environment once the QA environment has been thoroughly tested and and its stability and performance has been checked. The pipeline is managed by a control version software with a continuous integration framework that allows to automatically deploy and test the releases in their respective environment.

Integration and Quality Assessment: Integration assets have been grouped in different test sets according to their purpose. Integration tests are non-functional tests related to networking and infrastructure assets, and incremental tests ensuring the correct integration of the new release onto the current deployment. QA consists on passing a set of test cases designed by the Dev team that ensure a proper system response according to the elicited requirements and acceptance tests.

Team Daily

Dailies are the most important activity of our AUCD process. Both teams participate in team dailies to ensure coordination between them. On the one side, the UX team provides information about the subsequent design decisions, shows the current prototype and provides feedback about the integration in terms of interaction with regard to the current release. On the other side, the Dev team provides the current status of the development, including dev planning, functionality priority and tests. From the output given by both teams, daily agreements are achieved. At this point, team objectives are well-defined: the UX team aims to control and support refinement tasks for developers to fix possible deviations or slips during development, while the Dev team evaluates and agrees design decisions based on their technical viability. Thus, the whole team information is up to date, and priorities, deviations and issues are properly managed.

Application results

The proposed process was applied during 6 iterations until the first release was completed. The team was composed by 4 software engineers and 1 dev lead senior, 2 UX researchers, and 1 scrum master. Figure 6 summarizes both usability and scrum results: bars represent the different SUS values obtained at the end of each iteration. It is important to note that SUS questionnaires were conducted with the involved stakeholders on the sprint, either professionals, patients, or both. Lines represent the story points progression, where the yellow line determines the estimated story points at the beginning of the iteration, and the green one the completed at the end of it.

The UX team conducted during this period a set of five consecutive walkthrough sessions to progress iteratively and incrementally co-design with the potential users. Those workshops ensure that all the required functionalities have been considered and that they are implemented based in the users' needs and preferences. Usability tests were always conducted by one UX researcher, and at least a second UX researcher observed, took notes and collected the data during the test. Usability testing results were used as the main criterion to iterate. Regarding the development pipeline, submitted releases are related to the different components briefly described in figure 1. The first iteration was focused on the first release of the CGA for specialized care professionals (geriatricians). Second and third iterations were focused on patients' tasks, monitoring, and intervention at dwelling. Iteration 4 was focused on tasks were primary and specialized care professionals converge (referral, communication, alerts, and sharing data, among others). In this iteration the Dev team participated in the walkthrough session due to the complexity of several tasks to be designed. Thus, issues, solutions and decisions related with viability, alternatives, and technical requirements were held from the beginning. Iteration 5 consisted on the incremental inclusion of the remaining stakeholders (technical, staff, caregivers, other professionals, etc.). The last iteration performed tackled the different pending tasks carried over from previous iterations, refinement of certain user stories, and low priority tasks.

In iteration 2, the first one with elder patients, users expressed they would like to interact with the system frequently, but at the same time, they thought there was too much inconsistency in the system, resulting on an overall SUS value of 62.92, which is below the average (68). The subsequent iterations were mainly focused on solving and mitigating the detected issues on priority tasks. Finally, patients stated that they would like to use the system regularly, in case they would need to monitor their health status, but still expressed that there were some problems about lack of well-described instructions for some complex tasks. Regarding healthcare users, they perceived that the system is easy to use, welladapted to their needs, and that they would not require help or further assistance by the UX facilitator to perform the tasks. On the other hand, we detect on later iterations the different work constraints between profiles. For example, primary care professionals have very short medical visits to attend their patients, so they are more reluctant to add a new system to their work routine. Due to these results, task refinements were critical in sprints 3 and 5, so the expected new story points to complete were significantly reduced. Later iterations reflect how once the main user stories were successfully finished and refined, the Dev team could focus on low priority and pending stories from the backlog. Indeed, this situation allowed to turnaround the trend where more stories were performed than estimated.

Discussion

Overall, the design and adoption of this AUCD process was successful in different perspectives. From an organizational point of view, to allocate team members to UX or Dev pipelines allowed to focus the best effort according to their skills. Activities where the UX and Dev team worked together, such as daily meetings and a pluralistic walkthroughs, allowed both teams to stay up to date and react to problems from different perspectives. Regarding the artifacts delivered by the UX team, such as prototypes, task descriptions and acceptance tests, they were easily adopted by the Dev team due to their similarity with common agile artifacts. From a product/value-perspective, incremental design and development has been usually accompanied by good acceptance by target users; where the different stakeholders found the app easy to use and well-adapted to their needs.

There were relevant deviations in the estimation of effort for different parts of the system, due the complexity of dealing with multiple stakeholders and the specificities of the health domain. In particular, some tasks were downplayed in the system after identifying that the initial overall approach for such section was not possible, and effort estimations had to be modified accordingly. In addition, from the UCD part, it is worth mentioning that, although patient acceptance was achieved, several difficulties during UX activities were found. Additional iterations were required to better accommodate the designed user interfaces to the elders and their caregivers, due to the specific interaction limitations of this user base.

In a project involving different care tiers, like primary and specialized care, it is more difficult to identify a single customer. Lack of availability of healthcare professionals for development activities may cause that eHealth projects cannot carry out a traditional scrum inception. In our case, this led to some prioritisation mismatches, that both teams had to deal with. Our experience is an example of the inherent difficulties of integration of UCD and agile approaches in the eHealth domain.

Conclusions and future work

We have designed and deployed an AUCD process based on co-creation and scrum activities for a frailty monitoring eHealth platform. The process was aimed to apply a scrum-based methodology in a context with strong requirements on usability that includes quite differentiated contexts of use. Such contexts include different roles/profiles: community and specialized care professionals, elder patients and other stakeholders like caregivers, occupational therapists and nurses, among others. The process consists of two interlaced pipelines focused on agile and UCD activities and their specialized teams. Requirements and prototypes from co-creation are used as input for Dev team as user stories and tests, whilst releases are submitted to UX team and users for validation and further design. The Dev-QA-Prod pipeline was used to properly parallelize development and tests with design, the validation and the staging. As a result, both iterative processes properly converge to contribute to incremental development and create value. Usability evaluation results state that users found the platform easy-to-use and learn, and adapted to their needs.

Providing tools and activities to improve the big picture of the backlog and help users to compare the value between different epics are proposals for future adoption. In our further steps, the platform will be deployed in a clinical pilot involving 75 elders and 25 professionals from Spain, Poland and Sweden.

Fig. 1 .

 1 Fig. 1. POSITIVE platform schema.

Fig. 2 .

 2 Fig. 2. Integration of UCD and base scrum sprints in our applied process.

Fig. 3 .

 3 Fig. 3. AUCD iteration flow with activities per pipeline.

Fig. 4 .

 4 Fig. 4. Hi-Fi prototype for the professional view.

Fig. 5 .

 5 Fig. 5. Hi-Fi prototype for the patient view.

Fig. 6 .

 6 Fig. 6. Quantitative results by iteration. On the left axis, SUS values are broken down by user profile according to the different focus groups during co-creation activities and evaluation. On the left axis, story points estimated vs. done in each sprint.

See http://agilemanifesto.org/