Article Text
PDF
Abstract
Background The diffusion of innovation in healthcare is sluggish. Evidence-based care models and interventions take years to reach patients. We believe the healthcare community could deliver innovation to the bedside faster if it followed other sectors by employing an organisational framework for efficiently accomplishing work. Home hospital is an example of sluggish diffusion. This model provides hospital-level care in a patient’s home instead of in a traditional hospital with equal or better outcomes. Home hospital uptake has steadily grown during the COVID-19 pandemic, yet barriers to launch remain for healthcare organisations, including access to expertise and implementation tools. The Home Hospital Early Adopters Accelerator was created to bring together a network of healthcare organisations to develop tools necessary for programme implementation.
Methods The accelerator used the Agile framework known as Scrum to rapidly coordinate work across many different specialised skill sets and blend individuals who had no experience with one another into efficient teams. Its goal was to take 40 weeks to develop 20 ‘knowledge products’,or tools critical to the development of a home hospital programme such as workflows, inclusion criteria and protocols. We conducted a mixed-methods evaluation of the accelerator’s implementation, measuring teams’ productivity and experience.
Results 18 healthcare organisations participated in the accelerator to produce the expected 20 knowledge products in only 32 working weeks, a 20% reduction in time. Nearly all (97.4%) participants agreed or strongly agreed the Scrum teams worked well together, and 96.8% felt the teams produced a high-quality product. Participants consistently remarked that the Scrum team developed products much faster than their respective organisational teams. The accelerator was not a panacea: it was challenging for some participants to become familiar with the Scrum framework and some participants struggled with balancing participation in the Accelerator with their job duties.
Conclusions Implementation of an Agile-based accelerator that joined disparate healthcare organisations into teams equipped to create knowledge products for home hospitals proved both efficient and effective. We demonstrate that implementing an organisational framework to accomplish work is a valuable approach that may be transformative for the sector.
- Diffusion of Innovation
- Efficiency, Organizational
- Healthcare quality improvement
Data availability statement
No data are available.
This is an open access article distributed in accordance with the Creative Commons Attribution Non Commercial (CC BY-NC 4.0) license, which permits others to distribute, remix, adapt, build upon this work non-commercially, and license their derivative works on different terms, provided the original work is properly cited, appropriate credit is given, any changes made indicated, and the use is non-commercial. See: http://creativecommons.org/licenses/by-nc/4.0/.
Statistics from Altmetric.com
WHAT IS ALREADY KNOWN ON THIS TOPIC
Healthcare innovation can be slow and there is a large gap between knowledge and practice.
Agile methodologies are used in many sectors to rapidly create products, they have become more common in healthcare because they use fewer resources and improve quality.
WHAT THIS STUDY ADDS
We view this framework of organising work as something missing from most healthcare efforts. Lessons from our experience virtually bringing together teams to rapidly produce high-quality tools for wider home hospital implementation can help transform the adoption of healthcare innovation.
HOW THIS STUDY MIGHT AFFECT RESEARCH, PRACTICE OR POLICY
Scrum can be applied to many of healthcare’s complex problems and lead to rapid and transformative change.
Background
Introduction
A large gap in healthcare exists between evidence-based knowledge and evidence-based practice,1 often termed the ‘know-do gap’.2 In 1962, Rogers, a professor of rural sociology, published a seminal work on the diffusion of innovation.3 He and others posited that the perception of the innovation, the adopters and presiding contextual factors could impact the rate of spread.4 In healthcare, as in other sectors, nearly all of these clusters often drive against rapid innovation. Yet by employing an Agile framework to organise work so that it is iterative, predictable and joyful, other sectors have shown that rapid innovation is sustainable.5 We hypothesised that applying similar organisational principles to the work of healthcare could facilitate the diffusion of rapid innovation.6–9
Hospitals are the standard site of care for acute illness in the USA, but hospital care involves substantial risk and cost to the patient. One in 10 hospitalised patients will experience an adverse event, worse in older adults.10–12 For decades, literature has demonstrated that functional decline is a common adverse event associated with an acute hospitalisation and is often related to the processes of care, rather than the patient’s underlying illness.13 Despite evidence that movement improves patient outcomes, physical activity while hospitalised plummets.14–17 As a result, 20% of formerly independent older medical patients require assistance walking after an acute hospitalisation.18 While admitted, 20% of older adults suffer delirium,19–23 over 5% contract hospital-acquired infections,24 and many lose functional status that is never regained.10 25–29 The cost of hospital care to the patient is the leading cause of personal bankruptcy.16 29 Following hospitalisation, many patients cycle among care settings, moving between rehabilitation and hospitalisation and back again.30 31
Hospital-level acute care at home, or ‘home hospital’, was specifically designed to mitigate the risks associated with hospitalisation and improve outcomes that are important to patients. Home hospital is the provision of hospital-level care in a patient’s home as a substitute for traditional inpatient hospital care.32 Patients receive in-home nursing and physician care, intravenous medications, supplemental oxygen, laboratory and imaging diagnostics, and continuous vitals monitoring, among other services.33 Importantly, home hospital is neither traditional ‘home care’, ‘home infusion’ nor ‘home hospice’, which often involves much lower acuity services such as twice weekly nursing and therapy. Internationally, nearly 40 years of evidence, including several randomised controlled trials, demonstrated that home hospital improves outcomes important to patients.34–36 Home hospital patients have fewer 30-day readmissions, rate their experience of care more positively, feel more independent and less anxious, are more physically active and maintain greater functional status.33 34 37–42 From a clinical and administrative perspective, home hospital maintains patient safety and care quality while reducing cost.43 44
Despite this evidence base, diffusion of the home hospital innovation has been slow, with fewer than 20 programmes in existence for over a decade. The largest barrier was the lack of a payment and regulatory pathway in the USA.
In November 2020, the Centers for Medicare and Medicaid Services (CMS) issued the Acute Hospital Care at Home Waiver in response to overtaxed hospital capacity created by the COVID-19 pandemic.45 For the first time, the waiver created a nationwide regulatory and payment pathway for hospitals to deploy home hospital. The model has steadily grown from about a dozen programmes prior to the pandemic to over 250 hospitals in 37 states.46 This growth represents early adoption, yet a national survey of active programmes revealed that programme launch and growth remained challenging.37 Barriers to implementation included clinician buy-in, appropriate patient identification, feasible workflows and protocols, and local content knowledge and expertise to guide the programme. Many of these implementation barriers were so large that some programmes that were able to secure a CMS home hospital waiver never enrolled patients.
Widespread success implementing home hospital during the CMS waiver is a rare policy window that could influence the fate of Medicare coverage for decades to come. Home hospital’s extensive, well-documented benefits to patients, caregivers and hospitals and this time sensitive need for implementation support provided an opportunity to test a framework that accelerated the creation of tools necessary for home hospital.
Launching the Home Hospital Early Adopters Accelerator
Our goal was to bring together healthcare organisations that had interest in starting or had recently launched a home hospital programme to rapidly design and test knowledge products that could support programme implementation. Knowledge products could include a patient admission workflow to admit a patient, patient-facing welcome packet, market scan of technology vendors or list of requirements for commercial reimbursement contracts. We coupled our experience with home hospital and survey data from participating organisations to identify 20 knowledge products that would create a substantial portion of the tools needed to deploy a programme. To make high-quality tools available as soon as possible, we planned to create those 20 knowledge products in 40 weeks. We also planned to study the team’s performance.
Using Scrum to accelerate home hospital tool creation
Extensive knowledge of the home hospital model is often not common among healthcare organisations. To effectively deploy a programme like home hospital, a healthcare organisation charged with implementation needs access to deep expertise and experience, rather than a broad implementation guide or the abundance of available published literature. Traditional, one-on-one technical assistance approaches risk personnel-heavy, expensive, slow hospital-by-hospital diffusion of innovation.47 48 We searched for a methodology to bring together a network of healthcare organisations to accelerate their knowledge and expertise of home hospital. We gravitated towards Agile methodologies given their success in other sectors and their ability to break complex projects into manageable chunks of work.49 They have become more common in healthcare to rapidly organise teams, fulfil diverse needs faster and offer end-users involvement in the development process, all while using fewer resources and improving quality.7 50–54
Of the Agile methodologies, we chose to use Scrum due to its flexibility, low barrier to entry (eg, freely available tools),55 56 industry evidence that it accelerates work,51 57–59 and prior experience among our own team members. Scrum employs an iterative and incremental approach to optimise predictability, control risk and make work joyful. The members of a Scrum team collectively have all the necessary skills and expertise to do the work or can easily acquire such skills as needed. Scrum creates the structure for people to come together regardless of their background or area of expertise.55 Scrum began as a tool for organising software development teams, but it has been adopted across industries.55 57–64 Scrum has been used in healthcare to design electronic health record tools,65 develop communication tools for patients with cancer66 and develop a telemedicine care pilot.67 We hypothesised Scrum could catalyse coordination across disparate healthcare organisations to rapidly build the tools necessary for a home hospital programme to launch, instead of the often years-long pursuance of developing workflows, technology stacks and protocols.57 58 63 We also expected that the accelerator would break down the traditional siloed development that occurs among healthcare organisations.
The Scrum framework is purposefully limited to a few essential elements (online supplemental table 1) so the people using it can shape their work to best fit their skills, relationships and interactions. It involves three roles, five events and three artefacts (figure 1). The team roles include the product owner who has deep knowledge of the field and user requirements, the Scrum Master who leads and organises the team toward its products, and developers who have the knowledge to develop the team’s products. The Scrum process has several steps (figure 2).
Supplemental material
Scrum implementation. Refer to online supplemental table 2 for details on each Scrum element and adaptations made for the accelerator.
The anatomy of a sprint. Refer to online supplemental table 1: Scrum glossary for details on each Scrum element.
Step 1: backlog refinement
The Scrum process begins with backlog refinement (step 1), where the Scrum team defines the various products and breaks them into well-defined groups of tasks and minimum requirements needed to create a product that is ready to use (referred to as a product increment). To accomplish the product increment, the Scrum team creates multiple user stories that represent chunks of work. These user stories form the product backlog.
Step 2: sprint planning
At sprint planning (step 2), the developers select user stories from the product backlog to include in the sprint. Developers further refine the user stories and assign team members to the tasks required to complete the user story. These tasks form the sprint backlog. Then the Scrum team estimates the level of effort required to accomplish the user stories using story points (a relative measure of effort described below) and commits to the Sprint.
Step 3: daily Scrum
Each day the team holds a daily Scrum (step 3), where each member notes what items from the sprint backlog they accomplished, their impediments and what they will work on that day.
Step 4: sprint review
If the team believes the Sprint successfully achieved its goal, the team holds a sprint review (step 4), where they present a ready-to-use product to the project’s stakeholders (critical reviewers of the work) for feedback on how well the product meets minimum requirements for real-world use.
Step 5: sprint retrospective
The team holds a sprint retrospective (step 5) to identify successes and areas for improvement. The team then commits to an improvement by doing one thing differently in the next sprint.
Methods
Recruitment of participants
To solicit participants, we created a public request for participation in the Home Hospital Early Adopters Accelerator (referred subsequently as ‘the accelerator’). Any healthcare organisation was welcome to participate, including hospitals, primary care offices, home health agencies and healthcare insurers. As a partnership between Ariadne Labs (an initiative of Harvard T.H. Chan School of Public Health and Brigham and Women’s Hospital) and CaroNova (an initiative of The Duke Endowment, the North Carolina Healthcare Association and the South Carolina Hospital Association), the accelerator was available to sites in North and South Carolina free of charge while sites elsewhere paid a small participation fee. We asked sites to apply by describing their plans for launching a home hospital programme or to detail their current programme. We also required a commitment from executive leadership that the healthcare organisation would pledge to send staff to help develop at least five knowledge products over 40 weeks. We accepted all sites that submitted a complete application.
Adapting Scrum for the accelerator
As is common when using Scrum, we needed to make adaptations to the traditional Scrum processes to fit our goal due to the multicentre nature of the work and the accelerator’s constantly changing teams (online supplemental table 2). Typically, a Scrum team works together full time for months or years on end. Instead, we asked participating healthcare organisations to staff each sprint with developers who had content expertise in the planned knowledge product. Therefore, the developers were not long-standing colleagues but were instead thrust together for a maximum of 2 weeks without prior knowledge of Scrum or experience working with one another. Only the Scrum master, product owner and supporting project coordinator remained consistent from sprint to sprint (table 1).
The Home Hospital Early Adopters Accelerator team
In addition, all Scrum activities were performed remotely. It was unclear at the start of the accelerator whether we could achieve sufficient teamwork and assimilate team members to Scrum processes in such a short period of time. Because of the rotating developers, we asked a small cohort of accelerator participants to support our core team in producing the product backlog, instead of involving the developers. This enabled us to give the newly forming Scrum teams a head start with highly developed user stories that usually required only minor refinement and clarification during each sprint.
To run this fast-paced, distributed Scrum adaptation, we turned to a package of synchronous and asynchronous collaboration tools to connect team members. We used standard software tools like Zoom, Dropbox and Microsoft Office. To create a digital whiteboard and collaboration space, we used Miro. Our Miro board housed content for our sprint backlog, sprint planning, daily Scrum and sprint retrospective (online supplemental figure 1). It also served as a knowledge management platform housing a central repository for links and prior knowledge products. Developers created shared norms around collaboration for each sprint.
During launch preparation, we required role-based training (online supplemental figure 2). The team from CaroNova and Ariadne took the Scrum Startup for Teams training that taught the basics of Scrum (9 hours). Scrum additionally provided the team with a coach with whom we could consult as needed for Scrum methodology questions (10 hours of coaching time). To train the incoming developers from individual sites, we asked them to review two articles and a video about Scrum and home hospital (1 hour). We also asked developers to test their access to the tools ahead of the sprint planning and offered office hours with the Scrum Master and project coordinator to resolve any remaining technological or knowledge barriers to sprint participation.
Knowledge product creation
For developers, weekly sprints began with sprint planning, which included estimating the level of effort required to accomplish the selected backlog items. Level of effort is quantified as ‘story points’ instead of an estimate of the time required for each item. Story points represent the level of complexity and novelty of the tasks within the ensuing sprint, with more points equating to more work. Velocity represents the story points per sprint. A Scrum Master calculates the planned velocity at the beginning of the sprint and the actual velocity at the end of a sprint. High-functioning teams may, therefore, exceed initial Scrum velocity estimates if they are able to accomplish more work during a sprint. As an example, a team may plan to accomplish two user stories as part of a 1-week sprint. If each user story is estimated at three story points, the planned velocity is six story points. If the team is very efficient and decides to include another user story worth two story points, their actual velocity is eight story points.
Evaluation of the accelerator
At the end of each sprint, we collected developer feedback with an electronic survey using (Research Electronic Data Capture, Vanderbilt University, Nashville, Tennessee, USA, a fully HIPAA-compliant web application). The developer survey measured participant experience with the process of the accelerator and included items related to one’s experience participating in the sprint (Likert scale: 1, strongly disagree; 5, strongly agree) (online supplemental file 1). For example, to assess experience we asked, ‘The Scrum team worked well together’ and ‘It was difficult to create the knowledge product created during this Sprint.’ There could be multiple survey responses per Scrum participant because a developer who participated in two knowledge products would complete the survey twice.
At the end of the accelerator, we conducted semistructured interviews with developers and stakeholders to gather further depth and context on their experience as well as collect feedback on how the accelerator format could be improved (online supplemental file 1). A member of the study team (MD; female) conducted each interview with the participant over an encrypted connection. We audio recorded and transcribed the interviews for analysis using Dedoose qualitative software. A multidisciplinary research team with home hospital, Agile methodology and qualitative research expertise developed an initial codebook deductively based on the evaluation aims and interview guide questions. A member of the study team (MD) used an inductive coding approach, adding emerging themes or codes throughout the process. One coder (MD) performed a thematic analysis of transcriptions, and a second coder (SB; female) double-coded a subset of the interviews. Any disagreements were first discussed between the two coders to assess and improve intercoder agreement.68–70 If needed, the coders achieved consensus on any remaining disagreement through discussion with a third researcher (DML; male).
Results
Participants and sites
Of the 18 accelerator sites, most were large (62.50%), urban (83.33%) hospitals and hospital systems (online supplemental table 3). Less than half (44.44 %) of the sites had begun enrolling home hospital patients as of September 2021 when the accelerator launched.
There were 61 developers and 44 stakeholders. Overall, most developers were white (83.61%) and many were hospital administrators (42.62%), followed by nurses (24.59%) (online supplemental table 4). Most stakeholders also were white (88.64%) and most were hospital administrators (38.64%), followed by nurses (20.45%). Physicians accounted for 11.48% of developers and 18.18% of stakeholders.
Knowledge product creation metrics
The mean planned velocity was 2.4 story points per sprint (online supplemental figure 3). The mean actual velocity was 3.0 story points per sprint. This ultimately led to completing the 20 knowledge products 8 sprints early for a 20% reduction in schedule.
Participant and site experience
Quantitative findings
The results of this survey suggest developers were broadly satisfied with the process and the output of the accelerator (online supplemental table 5). Developers reported working approximately 5.65 hours (SD, 4.03) hours each week. Most believed the Scrum team worked well together (40.4% agreed, 57.1% strongly agreed), and the Sprints were productive (38.8% agreed, 59.6% strongly agreed). The majority of respondents also thought the Scrum team spent an acceptable amount of time working on each knowledge product (46.8% agreed, 48.1% strongly agreed). Most developers and stakeholders were pleased with the results, agreeing that the sprint produced a high-quality product (32.7% agreed, 64.1% strongly agreed).
Qualitative findings
From the qualitative analysis of developer and stakeholder interviews, we identified several benefits of participating in the accelerator including collaboration and knowledge sharing (box 1). We also found multiple perceived advantages of using the Scrum framework as well as some challenges.
Qualitative findings of developers’ experience*
Benefits of participating in the accelerator
Collaboration
‘I love the networking aspect with the people that were from other organizations and not just other organizations’ perspectives but the roles within those organizations… I learned a lot just from hearing their experiences with their own programs. I think another benefit was it felt like we were not alone in the struggles that we had, so there was a comfort level and validation… it felt like a normalization, if you will, sort of the growing pains that we were experiencing, which was actually really helpful. That was an unexpected benefit of participating in the program.’ (Nurse)
‘I think that the ability to collaborate across many different programs has been a huge benefit… [getting to] know other programs and their key team members…to just have everyone put their heads together to share the challenges that they're facing, how they work through them, and think through systematic ways that different aspects of patient care should be handled, I think, was incredibly beneficial and provided a lot of really helpful information that, I think, will be beneficial to our own program as well as to many others that are within the development and modification phase of their program.’ (Program director, nurse)
‘… I think the amount of sharing by everybody, I think, was probably the most valuable part. The willingness of people to talk about their own programs and talk about especially not only what worked but what didn't work, I think, was really one of the most valuable parts…’ (Director, non-clinician)
‘I appreciate learning these best practices and talking with colleagues doing this because sometimes you get stuck in your own system. You're in your silo. So it’s good to expand how you see the world, [laughter] how you see this new world of hospital in the home. So I guess learning best practices was number one, and then learning that we do have a support network out there.’ (Clinical specialist, nurse)
Knowledge sharing to inform home hospital program startup and implementation
‘We were able to identify gaps in our program that we had to actually focus on and improve once we had looked at something from a specific area in this accelerator program…it really helped us to enhance our program and elements that we hadn't thought about…I think being part of this program would have helped us start quite a lot sooner. It took us about two years to finally be comfortable to sort of launch our program, whereas I think we could have done it quite a lot quicker utilizing what we've learned from this accelerator program.’ (Administrator, pharmacist)
‘ I think another organization that is just starting with a hospital or home program, this is a great place to go get lots of information and a good place to find almost a full program. Definitely gives you the ideas of what you need to do to start it [home hospital program] within your organization.’ (Clinical manager, nurse)
‘Absolutely would recommend it [Accelerator] because it will put structure to your thinking about developing a program like this and reviews and points out issues that you hadn't thought of.’ (Vice president, MD)
‘I wish we had done this [participated in the Accelerator] before we launched…I wish we had been able to participate in this as we were working through creating some of these pathways and protocols in the months that preceded our launch.’ (Medical director, MD)
Perceived advantages of Scrum
‘It was great to see how quickly you could develop a product like that…thinking of my organization…sometimes it just takes forever to get any of those ideas off the ground.…I liked the way the Scrum team kind of kept you very focused…Very, very, very focused driven, specifically on the product. I think they [Scrum Master, Product Owner, project coordinator] did a great job of orchestrating that…and keeping people in check as far as what needed to be done.’ (Medical director, MD)
‘[In health care] I'm used to projects taking on a life of their own and becoming never-ending…I really appreciated the discipline in not only getting it finished but getting it finished basically in a week…I think creating the sense of urgency…really helped keep people focused.’ (Project manager, nurse)
‘I like the fact that they're peer reviewed right there on the spot during our Sprints. And there seems to be lots of thoughtful discussion. So I would say these are high-quality products just for the fact that these are people actually doing the work in the field.’ (Clinical specialist, nurse)
‘I think the thing it did was really hyperfocus everyone. I think that’s valuable to do, especially given the challenges that exist now in health care…I found it very helpful. And in fact, we're considering similar methods now at [redacted] to see if we can roll those out here.’ (Director, non-clinician)
Implementing technology designed for virtual collaboration in healthcare
‘Several of the teams had security issues with accessing the collaborative toolset…as a health care organization and a high-research organization, we have cybersecurity restrictions that literally prevented us from getting into some of the tools needed and some of the product. And in order to request access to those, to our cyber teams, that’s a three- to five day turnaround…We can't spend that in the next three days of sprints, we're already behind the curve.’ (Engineer)
‘ I did like the Miro board as a shared workspace. I think that having one place where you could pretty much see everybody at the same time and work together is always a great idea, especially…when you're dealing with people from all over the place.’ (Clinical manager, nurse)
‘…We had kind of heard about it (Miro), but we had never really tried it. So it did take a little time to get used to. But I would say the support of the project management team and the leadership were the best things about the accelerator program.’ (Nurse)
Time management challenges
‘It’s very time-consuming. I think for me, it was very difficult to make the commitment for the duration that was required for that program. And I know that there are other folks who opted not to participate because of the time commitment that I think would have had valuable input.’ (Social worker)
‘I have not had clearance from my director to have any extra time carved out from my hospital schedule…I wouldn't be able to [participate] until things change. right now, you're a hospitalist, so you have to have somebody cover for you, and that’s not really realistic.’ (MD)
‘The time component was incredibly challenging, as a clinician myself, I just don't have portions of every day over a two week period that I can devote to this… I didn’t realize how concise it was going to be within that first couple of days. And then there were portions that I was doing some of the QA review. And that was very date specific. And that wasn't clear to me when I signed up to do that part that it was on a day that ultimately ended up being a day that I was completely clinical, and so there wasn't much flexibility in my schedule. (Director, MD)
‘Despite all of the plans and information that was communicated, we did not understand the overall impact for the time and the commitment and the work. It became very clear quickly that it wasn't conducive to me as the senior director being able to keep up, (Director, nurse)
‘We actually repurposed [redacted]’s role and her job to carve out time to [allow] her [to] participat[e]’ (Director, Nurse)
I think this is definitely a time commitment doing this. So you have to—there has to be a significant desire and a need right from the health system to participate in this and understanding that you got to put the time in, but it’s absolutely worth it because the products are of such high quality.’ (MD)
Supporting developers along the Scrum learning curve
The first session doing it was very different… I know [Scrum is) fairly used in IT a lot more, but it was my first experience doing that. So there was a little bit of a learning curve for me. (Nurse)
‘[The] first accelerator that I did, I was completely overwhelmed… I take partial responsibility for that. Because the emails that I got regarding the Miro application and the Dropbox and all of those things really seemed to be a little bit self-explanatory. …while I've gone and looked at those sites, I didn't spend a lot more time with that… There was terminology that was foreign… I was utterly unprepared for what we were doing. … I thought, "What have I gotten myself into? How in the world are we going to do this in such a short period of time when I can't even literally navigate and follow what’s going on here.’ (VP, nurse)
I think the workload was quite a lot, especially if you are not used to all the terminology and what they expect from you. (MD)
‘I think the Sprint objectives were unrealistic from the get-go…I feel like some of the objectives were unattainable in a two week Sprint’ (Engineer)
I enjoyed it. I did enjoy it. In the first session I did, my head was spinning. But then, after, when we got to the second Scrum, I felt tremendously a lot more comfortable working in that fashion. Again, it was way different than what I'm used to. But I did like the active board Miro working as a group, tagging assigning. That was very helpful and nice.(Pharmacist)
*This table includes selected direct quote from qualitative data collected as part of the study.
Accelerator participants spoke at length about the benefits of collaborating within the accelerator’s Scrum framework. They saw value that it was not only with other home hospital programme, but with other individuals who had diverse backgrounds and expertise. Participants appreciated the opportunity to network with and learn from other home hospital programmes by discussing challenges, sharing and receiving feedback on new ideas, and hearing about the experiences of other participants.
Another perceived benefit of participation was the ability to learn firsthand how a healthcare organisation can launch their own home hospital programme. Participants from organisations that had an existing home hospital programme cited the benefits of cross-checking their existing tools and resources, like clinical and administrative workflows, with those being developed in the accelerator. This helped identify gaps in existing programmes and inform improvements. Through their experience with the accelerator, participants noted that the Scrum framework was a positive change from their standard way of working on projects in healthcare. Scrum helped focus and organise participants, it made the process of creating knowledge products efficient (without sacrificing quality), and the meeting format allowed for more collaboration. Overall participants said that more work was accomplished than thought possible.
The Scrum framework is highly collaborative and adapting Scrum to a virtual environment requires the use of virtual collaboration tools. Some Developers’ organisational policies and firewalls made it hard to access shared documents (box 1). This required workarounds, such as sharing the latest version of documents by email or designating someone with access to upload documents on behalf of a developer without access. When developers could access virtual collaboration tools, they were not universally familiar with them. The programme coordinator became adept at helping developers quickly log into and navigate both the virtual whiteboard and the shared cloud drive. Our model repeatedly brought together new, multidisciplinary groups of developers to work on each knowledge product. Matching the right individuals with the right expertise for a given knowledge product was vital but could be challenging. We provided sites with information about the required expertise for each knowledge product far in advance of Sprints so they could identify developers. However, some developers were not prepared for the hours of work required for each Sprint and found it hard to balance their other work priorities (box 1). Occasionally, developers felt their expertise was poorly matched to the knowledge product.
In most cases, developers were working on a Scrum team for the first time. Some felt overwhelmed by the unfamiliar Scrum terminology and the use of a virtual white board for live collaboration during the initial sprint review (box 1). Others found the format of the sprint to be very fast paced or with unnecessary components. This was a manageable learning curve, however, as developers consistently expressed that their second sprint was much easier than their first.
Discussion
Implementation of an Agile-based accelerator that brought together 18 previously unconnected healthcare organisations was feasible, acceptable and efficient in generating healthcare products faster than anticipated, requiring 20% less time. The accelerator successfully produced its desired 20 knowledge products ahead of schedule using an adapted Scrum framework. We believe organisational frameworks like Scrum are underused in healthcare as a method to drive collaboration and develop knowledge products to address various healthcare problems. Below we discuss the challenges we faced, lessons learnt and advice for future accelerators. We describe our overarching recommendations and the steps required to launch an accelerator in figure 3.
Steps to launch a Scrum-based accelerator. *Months noted reflect the time frame for scope to implementation of the accelerator. This timeline may be different for other programmes.
Implementing technology designed for virtual collaboration in healthcare
We recommend assessing developers’ comfort with tools before a sprint to facilitate targeted support. Consider holding early conversations with site IT staff to ensure needed access. Offering office hours for ongoing training and dedicated technical support helps further reduce barriers.
Recruiting engaged Scrum team members
We recommend having backup developers that the project coordinator can enlist should others have to bow out or be a poor fit for the knowledge product. We asked developers who might have to miss a daily Scrum meeting due to a competing conflict to use the digital whiteboard asynchronously to inform the rest of the team of their progress or any impediments. We also provided several subject-matter experts who could be brought in quickly when an area of expertise was lacking on the developer team. To make the time commitment explicit, we further recommend estimating for developers the total weekly number of hours they should reserve on their calendar for Scrum participation.
Supporting developers along the Scrum learning curve
To acclimatise developers to the Scrum framework, the Scrum Master included a 5 min Scrum overview at the beginning of each sprint planning, as well as weekly office hours. To adjust expectations for new developers, we also consistently communicated that after one sprint, the learning curve eased. We recommend clear training requirements for developers in preparation for sprint participation. This could include mandatory training session attendance or the use of learning management systems to ensure asynchronous completion of learning content.
This work has limitations. While we did have one international healthcare organisation participate in the accelerator, most of our participating sites were US-based organisations, therefore, limiting generalisability. In addition, most of our participating sites were large, urban hospitals. Further testing is required to see if smaller and rural organisations would have the capacity to participate in an accelerator of this nature. In addition, an adapted Scrum framework worked for our accelerator, but it remains to be seen if a similar method can be successfully implemented in other sectors of healthcare.
Conclusion
Healthcare has an innovation dilemma: innovative existing tools that need rapid deployment and implementation in weeks to months arrive at the bedside often years later. We believe this dilemma is partly due to how we structure quality improvement and implementation efforts in healthcare. Organising team members via Scrum facilitated productivity rarely seen inside healthcare while maintaining high-quality products.
We feel this framework could be easily applied to many of healthcare’s complex and simple problems and provide transformative speed and accuracy to a team’s efforts. For example, hospitals could use Scrum to develop a readmission reduction programme, a new surgical enhanced recovery after surgery pathway, or a discharge before noon process. Primary care could develop ideal cancer screening workflows, chronic disease management pathways or urgent care triage protocols. Researchers could use Scrum to optimise their machine learning model, to find chemical compounds more efficiently or to optimise deployment of a trial protocol in the field. To our knowledge, others in healthcare have rarely published metrics such as productivity velocity or the methods to organise busy healthcare organisations. We view this framework of organising work as something missing from most healthcare efforts. Changing the organisational principles by which healthcare practitioners work could counter the prevailing trends that prevent the rapid diffusion of innovation and lead to a transformative closure of the know-do gap for millions of patients.
Data availability statement
No data are available.
Ethics statements
Patient consent for publication
Ethics approval
This study involves human participants but this study was granted exemption by the Mass General Brigham IRB (2021P002411). All methods were carried out in accordance with relevant guidelines and regulations. Informed consent was obtained from all subjects. Participants gave informed consent to participate in the study before taking part.
Acknowledgments
The authors acknowledge Matthew Jacobs (Scrum) for providing guidance on how Scrum can be incorporated into the Home Hospital Early Adopters Accelerator. The authors acknowledge Margaret Ben-Or (Ariadne Labs) for early program launch efforts and project managers Adam Linsley (Ariadne Labs) and Carol Lucey (Ariadne Labs). The authors acknowledge Dr Carme Hernandez (Clinic Barcelona and Brigham and Women’s Hospital) and Dr Bruce Leff (John Hopkins University) for providing subject matter expertise to participants intermittently throughout the accelerator.
References
Supplementary materials
Supplementary Data
This web only file has been produced by the BMJ Publishing Group from an electronic file supplied by the author(s) and has not been edited for content.
Footnotes
Contributors MD is responsible for the overall content as guarantor. MD had full access to all the data in the study and took responsibility for the integrity of the data and the accuracy of the data analysis. SB carried out administrative, technical or material support. MD and MT-D conducted statistical analyses. MD, MT-D, SB, TT, DLG and DML drafted the manuscript. The study was supervised by DML. All authors contributed to study concept and design, interpretation of data and critical review of the manuscript for important intellectual content.
Funding The accelerator was supported by a grant from CaroNova (Mass General Brigham agreement: 2021A018173)
Competing interests The other authors declare that they have no competing interests. DML reports the following: Biofourmis: PI-initiated study and codevelopment; IM: PI-initiated study; Fees from The MetroHealth System.
Patient and public involvement Patients and/or the public were not involved in the design, or conduct, or reporting, or dissemination plans of this research.
Provenance and peer review Not commissioned; externally peer reviewed.
Supplemental material This content has been supplied by the author(s). It has not been vetted by BMJ Publishing Group Limited (BMJ) and may not have been peer-reviewed. Any opinions or recommendations discussed are solely those of the author(s) and are not endorsed by BMJ. BMJ disclaims all liability and responsibility arising from any reliance placed on the content. Where the content includes any translated material, BMJ does not warrant the accuracy and reliability of the translations (including but not limited to local regulations, clinical guidelines, terminology, drug names and drug dosages), and is not responsible for any error and/or omissions arising from translation and adaptation or otherwise.