Is scrum sufficient for user involvement?
Case studies of overcoming scrum limitations in user
involvement in healthcare software development projects
Master thesis, MSc Supply Chain Management
University of Groningen, Faculty of Economics and Business
Pawel Kubalewski
S3240827
Supervisor: Dr. Hein Vrolijk
Co-assesor: Prof. dr. Jan Riezebos
5
Abstract
6
1. Introduction
Scrum is the most popular agile software development method (Dingsøyr & Lassenius 2016). Developers implement scrum to achive shorter product development time while using less documentation and delivering higher quality product (Machado et al. 2015). The scrum framework described by Schwaber & Sutherland 2013 provides different strategies for engaging users. It is recommended to apply the scrum methodology within small, cross-functional teams of 3 to 9 members. Agile has seen a steady increase in popularity, with scrum being the fastest growing in last 5 years (Dingsøyr & Lassenius 2016).
7 Subsequently the data was collected in the form of multiple case studies which were conducted in scrum teams developing software for healthcare. Each case is represented by different healthcare software project, with 3 cases being studied. The research approach is exploratory and focuses on scrum teams developing software for healthcare.
8
2. Theoretical background
This section contains a theoretical foundation of this study. First part will be a short description of scrum methodology. Second part is an assessment of types of healthcare software types, their categorization and development purposes. Next I summarise existing user involvement techniques used within scrum methodology and in a medical setting. Fourth part will comprise of scrum limitations and fifth part will contain the conceptual model and summarize the chapter by discussing predicted relationships between the constructs.
2.1 Scrum methodology
Agile manifesto was created in 2001 to provide “better ways of developing software” (Fowler & Highsmith 2001). It comprises of twelve key principles. Agile has enabled its users to achieve shorter time to market, customer and employee satisfaction and above all accommodation of rapid and unexpected changes. It is predominantly used in software development but lately has been adopted in all different kinds of industries such as manufacturing or marketing (Rigby et al. 2016). Turk et al. 2002 warns users of agile development methods of the defined size of teams, which can be especially limiting when experts from various fields have to work in one team, as it is the case in medical software. Flora et al. 2014 acknowledges that Agile is the best fit for developing software by empowering user experience and stakeholder involvement in the project. However the user perspective is not always considered in agile projects (Cajander et al. 2013).
10 Another way of segregating software is by level of medical training of the target user. Ventola 2014 mentions software used by doctors. As an example he describes apps that improve doctors’ skills by providing virtual training and as a result improve their performance in real life scenarios. Another group are the patients themselves. Their first hand knowledge about the medical condition can lead to solutions that are more relevant to patients concerns and dilemmas (Domecq et al. 2014). The techniques used to engage users can differ as users will provide the developers with different type of knowledge. Types of software and their potential user profiles are summarized in table 2.1. Carroll 2016 focused his study on identifying the key success factors of health software solutions. The study underlines the need for software developers to “immerse themselves in patients” in order to better understand the patient’s needs. Apart from knowing the user, software development team must understand who is the potential paying user for their software, to develop software that is intuitive to their target audience. Further analysis of differences in engaging patients and medical professionals is described in section 2.4.
11 Singh 2008 in his study presents scrum methodology variation called U-Scrum. U-Scrum is most adequate in developing products that solve problems which are not well understood. Alongside regular product owner second product owner focused on usability and user experience vision is introduced. Product owners have to share product backlog. As a result, the developers are able to focus more on the usability. Observed usability of the product is significantly higher than in projects that use traditional scrum methods. Main issue in U-Scrum arises from two product owners as they have to assign the priority to the items in the product backlog (Singh 2008). It can be expected that other scrum projects also have to prioritise user feedback in order to integrate it with the development process. Another challenge of U-Scrum comes from development team which may not rely on provided user stories and implement its own vision instead. The main premise of U-Scrum fits the needs of software developers that create software when problems that they address are not fully understood (eg. in healthcare projects) (Chowdhury 2012).
2.3.2. User involvement in medical projects
User involvement in medical projects has been an object of multiple studies (Shah & Robinson 2006; Fudge et al. 2008). Because target users differ between projects, engagement techniques must be adjusted depending on their knowledge and skill level (Johnson et al. 2005). Facey et al. 2010 acknowledges patients as crucial source of information on social and psychological aspects of living with an illness. Patient’s perspective can reveal values and expectations of illness and health technologies. Main concern of patients participating in medical projects is being only a guest of product consultation, whose feedback will not be implemented. Study of Shah & Robinson 2006 found that the most popular techniques for engaging patients in medical device development were in descending order: usability tests, interviews and questionnaires. Most crucial limitations of patient engagement considered by researchers are: representatives of given patients, biased views, quality of feedback and increased project length (Boote et al. 2002). Embi & Tsevat 2012 underlines that engagement of healthcare professionals is beneficial for research projects as those professionals have knowledge of real life cases, can come up with problems derived from practice and have possibility to recruit patients for further research. Furthermore lack of medical evidence in medical software development can lead to software that misdiagnoses or even harms the patient (Buijink et al. 2012). Medical professional play a role of an intermediary providing developers with evidence based medical knowledge (Timmermans & Angell 2001).12 Middle empowerment enables user to lead two-way dialogue with professionals. The highest level gives control of the project to the user (Boote et al. 2002). Healthcare professionals and patients are sources of different types of feedback. Depending on who is the target user of medical software the focus will be different. Software focused on diagnosing and monitoring diseases will need evidence-based grounds to offer reliable information to patients. On the other hand, software that is focused on helping patients cope with their condition will require patient engagement to gain better understanding of specific usability constraints.
2.4. Scrum limitations
Scrum is focused on delivering working increments of products quickly and efficiently (Schwaber & Sutherland 2013). User involvement makes the whole project last longer which in turn increases its cost. As noted by Niès & Pelayo 2010 developer-user dialogues are not sufficient for understanding user needs, because the developers often struggle with translating user feedback into a requirement. Furthermore Niès & Pelayo 2010 statement implies that engaging users in a way of informer as described by Boote et al. 2002 will not be sufficient as user feedback verification is needed in healthcare software projects.First limitation of scrum framework is identified by Cajander et al. 2013 and concerns not assigning the responsibilities regarding product quality to team members. This includes not assigning responsibility for product usability and user engagement. It is problem since group responsibility prevents the team from integrating user perspective in a consistent form in the project. Literature analysis has revealed that the most popular solution to this problem is inviting usability specialist into the development project and assigning this responsibility to them (Butt et al. 2015). Alternative solution is described by Singh 2008 and involves assigning a second product owner who is responsible solely for user engagement in the project. The effects of implementing second product owner have not been researched in healthcare setting.
13 states that lack of documentation creates issues for the teams as information exchanged is insubstantial and is not properly related to product backlog.
2.5. Conceptual model and research questions
As mentioned by Schwaber 2009 scrum provides developers multitude of user involvement techniques to choose from. Methods for engaging customers in the development phase can differ because of different type of information that is to be obtained. As doctors might be more difficult to recruit for participation in the project, the time they spend on providing feedback should be well planned. Patients are more available to participate in development projects. Another issue that developers must face is generalizability of information acquired from the patient. Developers must verify whether feedback is not only case specific. This study will focus on answering following research question and sub questions:
• How is user involvement managed in scrum teams developing healthcare software? o What are the differences between engaging patients and medical
professionals in the project?
o Does user type influence at what stages of the project users are engaged? o What is the influence of software type on the level of empowerment that
users are assigned in the project?
o What makes developers decide on certain engagement technique?
As a result, the approach of this study will be exploratory. Each case will be analysed in depth researching all specificities of the project that could potentially influence the development process such as: level of user empowerment, when is user engaged in the project, and last but not least user involvement techniques used. Figure 2.2 represents conceptual model. The aim will be to better understand what causes the differences in user involvement strategy depending on user that has been involved in the project. Figure 2.2 Conceptual model. User involvement strategy Product characteristics User type
14
3. Research design
This research uses case study method in order to investigate how is user involvement managed in scrum projects developing healthcare software. Case study is used to acquire deeper understanding of the researched topic and is primarily used for exploratory research (Runeson & Höst 2009). User involvement in healthcare software development is an under researched topic, and qualitative data needs to be obtained in order to answer research questions. As a result, case study is a suitable method for this research.3.1. Case selection
To gain more insight on how user involvement was managed in various projects the case study was conducted by interviewing 4 developers, working on 3 medical software projects. Single project represents one case study in this research. Using multiple cases increases the external validity of data and minimizes the observer bias (Runeson & Höst 2009). The trade-off comparing to single case study is smaller depth of the interviews conducted. Since the field of this research is weakly explored with suggestions of Karlsson 2016 the data for this study was collected in the form of in-depth case studies. The aim was to obtain rich qualitative data from the interviews. Interview questions aimed at finding answers to following questions: • Who was giving the usability feedback in the project? • What was the target user for the software? • To what degree was the development team willing to change the project to user guidelines? • Why were particular user engagement techniques used? • Why was certain group of users invited to provide feedback in the project? • At what project stages were the users providing feedback to the project?
• Did developers assign the level of user empowerment based on software type being created?
• Is engagement technique dependent on user type?
The questions aim at examining the constructs presented in the conceptual model. Following questions will investigate the relationships between the constructs and try to explore the cause of underlying relationship.
15 and contacting medical software developers working in the region of Groningen. Interviewing people with different level of scrum experience was taken into account in the interview protocol.
Requirements for selecting a case were developer that took part in healthcare related software project, the development team was using scrum or its variations as the main development approach and users were engaged in the process. Another distinction that has been made is the role of a developer in the project team. Obtaining multiple perspectives on a project will facilitate depper understanding on how user engagement was faced by the scrum team. The interview protocol is created in a way to address different levels of knowledge of team members. If necessary, scrum concepts were explained to the respondents. The interviews were conducted by asking previously prepared interview questions and follow-up questions. Questions were kept open to provide greater depth to answers. Usage of multiple data sources strengthened the construct validity of the research (Karlsson 2016).
3.2. Data collection
Data was collected with unstructured case study. Runeson & Höst 2009 notes unstructured interview is the most adequate method for conducting exploratory research. The interview consists mostly of open questions which minimize the bias of interviewer (Yin 2009). Answers were transcribed directly after each interview to minimize recall bias. To increase validity and reliability, protocol of the interview was created. The protocol contained checklist of all tasks needed to conduct the interview. The interview protocol was sent beforehand to let the interviewee prepare the answers.Interview recordings were transcribed directly after each interview to minimize recall bias. The transcripts were analysed thoroughly for common features and differences. Internal validity was assured by pattern matching the cases. Research is not free of risk as focusing only on development process limits the possibility to assess the influence of other factors that could have impat on the project such as budget or time constraints. Contribution of this research is expnding existing knowledge on user engagement in medical software projects and creation of new hypothesis for further research.
16
4. Results
The focus of this section is set on describing research results. Table 4.1 presents general information about each case. Table 4.2 shows which scrum artefacts were used in each project. Table 4.3 shows user engagement techniques that each project team decided on using. Figure 4.1 and 4.2 will show how the scrum methods applied to researched projects differs from standard framework shown in figure 2.1.Firstly, the projects studied are briefly discussed. Next, the approach taken to deal with user engagement in scrum context is described, following the customer engagement techniques used are summarized. Last the differences from standard scrum framework will be addressed. At this point a crucial distinction needs to be made. All interviews operated with similar team structure. The main idea creators were the ones that created the requirements, they also were in charge of testing product on end users. They will be referred to as domain expert in this section. Next were the coders who were in a big simplification translating provided requirements into working software increments. Patients and doctors that were involved in the projects were not a part of development team.
4.1. Focus of software projects
First project is called digi-tafel. The task was to develop custom software for an existing hardware. The hardware was a big tablet the size of the table that is used to help decision processes, learning and analysing behaviours. The software’s goal is to record all actions taken on screen, create a database out of it and analyse that data. This knowledge can later be used to identify common mistakes to enhance the learning process. One of main functionalities is to help visualise to the patients the procedures and potential decisions and its trade-offs that can be made. At the time of the interview digi-tafel was not yet commercially available. The end users for this device are doctors, patients and business professionals. The table was displaying flowcharts of medical procedures and this information needed to be obtained from the doctors. Other important information that was collected from users was testing if every user is engaged while using the product. The interview was conducted with the original idea creator of the product, who was involved in the project as a part of development team. He was an expert on psychological aspects of the project classified as domain expert for the project.17 project was already complete. The software needed to provide security and privacy. In this case the client was a co-developer and was also an end user of the project. The project required extensive communication with the client to provide a software that meets his expectations, because working with safety and privacy regulations results in some unexpected changes need to be made to the project. The client was the domain expert. Person interviewed was a coder. He had extensive experience with scrum. Selfcare4me is a platform targeted to patients to help them monitor all kinds of vitality data from steps taken to cholesterol intake and connect them if needed with their GP’s. The project idea became incorporated and currently operates with web application and is present on AppStore and PlayStore. Clients can access the features for a monthly subscription fee. Alternatively, a subscription can be purchased by e.g. company, smart city, insurance agency. To allow the platform to grow the product offering must meet customer requirements. The domain experts engage users and employ that data by testing the software with them. Users in this project act as an arbiter for ideas. Domain experts are responsible for the design and functionalities. Coders create the back end of application and everything they do is limited by the requirements provided from specification documentation so there is no ambiguity on what they should include or how should it work. Two domain experts were interviewed. One was a healthcare professional responsible for communication with the coders and the other was the original idea creator of the project.
Table 4.1 represents details concerning each software project. Number of people involved is not directly comparable since some people working on the digi-tafel did so only for a one day a week whereas for BRISP and selfacre4me developers worked every day of the week. The size of the digi-tafel team is further inflated by including all project members whereas for BRISP and selfcare4me coding was being outsourced. SOFTWARE
PROJECT SIZE OF DEV TEAM
PROJECT
AGE SCRUM USED TARGET CUSTOMER GROUP
USER
EMPOWERMENT SOFTWARE TYPE DIGI-TAFEL 10 - 12 2 yrs. Formally Patients and
doctors Low Informative
BRISP 3 – 5 2,5 yrs. Formally Healthcare
companies High Medical
SELFCARE4ME 6 4 yrs. Formally Patients Medium Assistive
18 The time at which scrum was introduced was about 2 years ago for all the projects. Before introducing scrum selfcare4me was working with a waterfall development method. An interesting observation that can be made from analysing the interviews is that the implementation of scrum was in all cases initiated from the coding team side. ∂Scrum used in BRISP and selfcare4me cases utilised most distinct scrum artefacts such as product backlog, daily scrum or sprint reviews. These projects used an online client which contained functionalities such as scrum board and product backlogs. Digi-tafel project utilised scrum in a traditional way having attributes such as sprints and review meetings. Overview of all scrum attributes used in the projects is shown in table 4.2.
* Meetings are done weekly. ** Uses multiple product owners.
4.2. User engagement strategy
Firstly, to supplement the dialogues with user, scrum teams utilise various user engagement techniques. In all projects user stories were utilised. In selfcare4me case the user dialogues were supplemented by a support system that allowed users to provide feedback, if the problem occurred frequently or if the domain experts agreed with its significance its solution would be implemented into the project. Collecting knowledge in forms of observations allowed domain experts to see the usage patterns and better customize software features for the user needs. This was done in digi-tafel and BRISP projects.
Secondly, the documentation is an inevitable scrum feature when dealing with user requirements regardless if it is formal or informal documentation. That is the reason why all studied cases had made use of documentation to implement user feedback in a project. Digi-tafel domain experts handled the documentation informally communicating the information obtained from doctors in mail. The mails were sent out by the project leader who acted as an intermediary between coders and doctors. The team were also in the process of developing an app that would automate the communication between the end users and developers. In BRISP project a special application was developed, its goal was to enable leading quick information exchange between customer and coders. Thanks to this application SOFTWARE
PROJECT SPRINTS SPRINT REVIEW SCRUM DAILY BACKLOG PROUCT SM PO MVP
19 customer contributes to the project on a continuous basis. The problem with empowering user to post requirements via this channel is that improvement ideas could come in indefinitely so for practical reasons a limit for how long can the requirements be posted should be acknowledged. In BRISP and selfcare4me case, a custom documents were created to handle the transfer of information between domain experts and coders. Such documentation contained development details, namely blueprints and screen mock-ups. This documentation had to be highly specific since coders did not posses the required knowledge and can only guess the actual user requirements. Thirdly, all projects had a designated person that was responsible for user contact. In digi-tafel case it was an expert who had direct contact with doctors since it was highly important to the project. In Case of BRISP and selfcare4me, a person from the scrum team was designated to provide the coders with user requirements. This person was selected based on personal traits that would minimise ambiguities during the contact.
4.3. User engagement techniques
Various user techniques mentioned in theory section were analysed during the interviews. The interviewees provided the advantages and drawbacks for each user engagement technique they used. The techniques used per each case are presented in table 4.3. In none of the projects were surveys used, the reasons for that being low accuracy of the outcomes, difficulty in getting the user response and time consumption. Digi-tafel, selfcare4me and BRISP employed interviews. Interviews made it easier to test perspectives of different users. In all cases user stories were a part of the project. In selfcare4me project a dedicated product owner was working on software interaction, he was also sharing the backlog with other product owners. Based on this the development approach for selfcare4me project was similar to U-Scrum even though the team had no knowledge of this technique. Observations were used in digitafel and brisp case. They were not used in selfcare4me case because that project had already developed working software. Prototypes were used in all projects, although selfcare4me equivalent of a prototype was working software.
SOFTWARE
PROJECT STORIES USER VIEWS INTER SURVEYS LITY POUSABI 3 VATIONS OBSER UAT1 DOCREQ 2 PROTO TYPES
20
4.4. Variations from scrum framework
Scrum is customizable, and developers took their chance to modify the framework to include the user voice in the project. Project structure described in BRISP and selfcare4me case is presented with figure 4.1. In both cases the teams working with scrum were not uniform instead opting for a split between coders and domain experts. Daily standup meetings were replaced by weekly meetings as online platform was used to handle the communication between teams. In all cases the teams were not uniform, the documentation was used to store user feedback and responsibility for user engagement was assigned.
In BRISP case an online platform to manage scrum functions is introduced (figure 4.1). This software could be accessed by coders and domain experts. The development team has access to product backlog, sprint backlog and burn down charts online. In this configuration in contrast to traditional method the domain experts can obtain feedback on progress instantly without disrupting the coders. They also have an ability to post comments or suggestions for coders. User feedback obtained by domain experts is translated into requirements and transferred to coders using online scrum platform. User documetaion was introduced in a form of highly specific documents. The documentation provided developers with explicit guidelines and played a crucial part in maintaining medical standartds of software.
Figure 4.1 Scrum framework extension.
21 transferred to coders. This creates a constant feedback loop. Customer was given medium empowerment level in this project. This approach creates more transparency and engagement between the developers and users. Customer remarks if accepted are translated into custom created documents of 40-200 pages and are transferred to the coders. Developers are the idea creators and act as an intermediary between customer voice and highly technical coding process.
Figure 4.2 Feedback loop
22
5. Discussion
This section draws conclusions on previously presented results. It includes answer to research question and sub questions. Conclusions are put to comparison with knowledge found in the literature. The findings are analysed with respect to conceptual model and limitations of conducted research are described.
5.1. Project structure
Although scrum framework pushes for cross functional teams that solve every task at hand together (Schwaber & Sutherland 2013) the results show a trend to split the teams into more functional groups with distinction between coders and domain experts. The domain experts would come up with initial idea for software and then hire the coders to translate the requirements into working code. The domain experts would possess specific healthcare or psychology knowledge. This can be classified as distributed scrum as described by (Sutherland et al. 2007).As a result the development teams focused on user engagement and coders focused just on highly logical programming, the domain experts would use their knowledge and soft skills to investigate user behaviours. This gives more distinction into who is responsible for user engagement. The biggest drawback of this solution is lack of person with technical knowledge that would participate in customer discussions. This would lead to situations where the coders would reject some requirements and suggest a simpler or more feasible solution to the problem.
23 Domain experts advise that gathering end-user feedback is most effective when users are presented with a working prototype. This would mean engaging users at the end of a sprint. Engaging at this stage fosters collection of rich qualitative data. The most important aspect of user engagement is checking if the software is intuitive and if all features are understandable to users. User involvement is less important in the initial planning since the healthcare software projects are conducted starting on a premise identified by empirical knowledge of domain experts. It is worth noting that users can be empowered to provide feedback on a continuous basis, this feedback is evaluated by the domain experts and can be translated into requirements for next sprint. It’s especially important to retain users as they quickly stop using software that doesn’t fullfill their needs. In respect to (Manikas et al. 2007) software classification, higher level of software interference in users health means higher empowerment of the user engaged in the project. Medical professionals have the low empowerment in the project since they acted only as a source of information. In case of software that was assisting the patient, evidence-based medical knowledge starts playing a higher role since the whole interaction with the software is based on providing feedback to user and could have an impact on his health.
5.2. Choosing user engagement technique
This subsection is an analysis of user engagement techniques. With respect to suggestion of (Shah & Robinson 2006) to fill the gap in knowledge of engagement techniques used in scrum. As techniques are a pivotal element of user engagement strategy, its impact on the project and their compatibility with user are discussed. Prototypes enable developers to examine how users are working with the product. Cui & Wu 2016 notes that prototypes help exchange tacit knowledge. When a product that is being developed doesn’t work it can be identified in an early stage saving significant costs and time to the development process. An attribute that is highly relevant in agile development. Prototypes can be implemented after each sprint, although they are used only when major changes are introduced to the project. Classifying change as requiring user test depends on the scrum team. Last but not least prototypes significantly USER TYPE SOFTWARETYPE EMPOWERMENT USER ENGAGEMENT TECHNIQUES WHEN ENGAGED
PATIENT ASSISTIVE Medium/High Interviews, UAT ,
User stories End of sprint
DOCTOR INFORMATIVE Low Interviews Before sprint planning
24 increase the cost of a project. One interviewee noted “Sometimes you don’t have time or money to develop the prototype”. Creating prototypes and distributing them to customers is time consuming. Prototypes are fit for use with patients and medical professionals. Dobrigkeit et al. 2016 acknowledges that main reason for using prototypes is assessing feasibility of software solution but user enthusiasm toward the product might be influenced by the enthusiasm of creators so developers conducting the testing should take this effect into account. Additionally the development can last indefinitely because each time the customer will come up with new improvements, to solve this problem a limit of rework should be set when negotiating with the customer. Interviews are a technique complementary to prototypes as after testing the developers would ask specially designed questions to assess the user interaction with the product. Singh 2008 noted that scrum doesn’t enable building prototypes before the development begins and as observed that was true for all cases. Interviews however can be used in the initial phase of the project to test out the project idea. In medical setting however the idea for software is derived from domain experts knowledge. Moreover whreas prototypes are not as frequrently used because of time and cost constraint interviews are used more frequently and help keep the contact with the customer. Aditionally interviews are a great way to study feedback taking into account perspectives of multiple users.
25
5.3. Conclusions
There is no straightforward solution when it comes to customer engagement in healthcare scrum projects. The information needed depends on development team and software created. The trend that could be observed along all the projects is that coders never had direct contact with end users. The conact was always moderated by the domain experts who were at the centre of the project. The idea origin in the projects were the domain experts who did not have the specialised coding knowledge. They were also the ones that would engage the users and translate their requirements into product features. All user enagement techniques are fit for both patient and medical proffesionall use. What distinguishes between which technique should be adopted is the type of information that needs to be obtained. Information that developers were collecting was concerning software functionality or software content (as in informative software).
Guha & Al-Dabass 2010 in his paper suggested to split agile teams into functional roles. This was accomplished in the cases by usage of online scrum environment. Main feature of using scrum platform online is instant communication in a distributed scrum environment. Providing feedback in a continuous way via an online scrum environment enables sprint review meetings to run smoother as domain experts can better understand what are the technical challenges and the process of creating software itself. The platform acts as a proxy for exchange of requiremets. This could mean quicker implementation of user requirements because it moves a planned discussion at sprint planning meeting to an online scrum client so the exchange can happen istantenously. Impact of described scrum client is presented in figure 4.1.
26
5.4. Limitations
27
6. Future research
An outcome of this research is suggestion for further study in the domain of scrum user engagement. The topics of user engagement in scrum that should require further research will be mentioned in this subsection with two more detailed research proposals trailing. The topic of user empowerment remains underexplored as it was mentioned only by a handful of articles. The relationship between software usability and level of empowerment assigned to doctors and patient should be further investigated. Moreover the teams adapted the online scrum environment but they didn’t include the user directly in the software. The effects on usability and project agility could be inevtigated in this seeting. The hypothesis being:
Working with patients/doctors in online scrum environment increases usability of created software. Firstly additional research can be conducted by reaching out to patients and doctor engaged in healthcare software projects. This research should be conducted in the form of survey and its goal would be to identify which user involvement techniques have the highest impact on user satisfaction or on retaining users to continue using the software. The interviews could be collected by reaching out to scrum masters that engaged users in their projects and collecting contact information of the patients and medical proffesionals. This research could provide scrum proffesionalls with rich quantitative information on which user engagement technique fits their project the best. The independent variable would consider which technique was used, with moderating effect of what software was created consequently dependent variable would consider user satisfaction from using the end product. Secondly online scrum platforms could be further investigated, as they are fit for use with scrum and developing healthcare software. This research can be realized in the form of a case study research with professionals that worked with both scrum used in traditional way and in an online web platform. The main focus should be put on effect of working in online scrum environment on amount of rework done in the project. Aditionally the effect on total development length can be examined. The research question that should be answerd in this study could be “How can using online scrum platform reduce the development time of a software project?”. The moderating effect in this research would be attributed to whether the team is working with distributed scrum, because online scrum advantages might be eliminated from working in a close proximity. The independent variable would be defined whether a team uses an online scrum platform and dependent variable the amount of rework and time span of the project. The hypotheis being:
28
7. Appendices
7.1. Case study protocol
Interview time and date ………User engagement in scrum projects – case study protocol
As medical software projects are often developed by expert programmers and coders, medical knowledge is required to ensure product safety but also to make sure that project meets actual patient needs. Therefore stakeholders knowledge (patients, doctors) must be obtained in some way. Scrum provides multiple techniques to involve user in a project but standard techniques of scrum make user engagement not explicit. This research focuses on exploring how is user involvement managed in healthcare software projects. The goal is to obtain rich data on detail of how are user requirements managed, what techniques are used to obtain user feedback and what is the level of empowerment of user in the project. 1. Set up the recording before beginning the interview. a. Inform about the fact that you are recording. b. Ask for permission to record. 2. Introduce yourself. State your own name and ask interviewees to state theirs. 3. Note the respondent/s details. a. Name b. Position in a company 4. Present basic information about the project (the part written in italics)
