Can Scrum and Medtech Coexist?

- Written by Sam Menasha & Eric Sugalski

Most medical device companies operate using the waterfall method. But most medical device companies don’t operate as quickly as they could or should.

The waterfall goes like this:

1. Write down your requirements – user needs, design inputs
2. Gather large groups of multi-disciplinary teams to review and approve the requirements
3. Design the product, analyze/mitigate risks, and create specifications
4. Gather large groups of multi-disciplinary teams to review the product design, risk analyses/mitigations, and specifications
5. Verify the product through bench testing
6. Gather large groups of multi-disciplinary teams to review the verification test data
7. Validate the product the clinical, human factors, biocompatibility, and/or other tests
8. Gather large groups of multi-disciplinary teams to review the validation test data
9. File with regulatory body for market clearance

Any one of steps 1-9 can be repeated, often multiple times. The age-old waterfall method works, but it takes eons. But, when you are developing a new-to-the-world medical device, you don’t have eons. You have 18-24 months before investors start getting itchy in the pants.

Enter scrum.

Companies call it different things, but the concept is simple. It’s to create smaller, testable versions of a product. It’s experimental. It’s non-linear. It’s focused on testing something specific. Scrum doesn’t wait for requirements to be written down before concepts are generated. It doesn’t wait for 12 people from various departments to schedule the “design review.” Scum doesn’t wait for the fully integrated prototype to start testing. Scrum is about speed, learning, and reducing risk -- rapidly. And when risk is reduced, valuation is bumped. And that makes everyone happy.

Ready to get started with scrum?

Here are 4 quick tips to set you on your way:

1. Figure out the right sprint interval – At Archimedic, we typically live in a 90-day world. This is enough time to make significant progress on a critical risk. By contrast, scrum for software typically operates in 30-day sprints. Building physical things requires more time. You need to wait for parts, assemble, debug, test. 90-day sprint cycles are generally a place to start.

2. Focus sprints on the “test” - not the thing – Too often, people are focused on the “demo.” A “demo” is generally useless. It’s show-and-tell for adults. The thing that you built isn’t what matters in medtech – it’s what the thing does. So, start there – the test. If there is a big concern about patient adherence to a new medical device, how can you evaluate that risk? If there is a clinical efficacy risk, how can you quickly understand if that risk has been reduced? If there is a commercial / payer risk, what is the test that helps you and the team understand if this risk has been reduced?

3. Avoid early integration – It’s tempting for teams to want to see integrated prototypes. But, doing this too early is universally a big mistake – that is if time matters to you. Integrating subsystems into fully functional designs means that one small change tips the domino that causes all the other subsystems to require revision. A better approach is to keep subsystems separate. Human factors risk? Build up non-functional usability mockups. Efficacy risk? Define the animal model and adapt an existing medical device to evaluate pathophysiology response. Commercial / payor risk? Review the clinical and economic endpoints with payors through the Early Payer Feedback Program (EPFP). Run these sprints in parallel. Repeat if more data is required. Resist the temptation to integrate until the critical risks have been reduced through the most efficient means possible.

4. Schedule the sprint review at the kick-off – Waiting until the sprint is complete to find time on team members calendars to review will kill your schedule. Instead, get that meeting on the books right at the sprint kick-off meeting. That’s the time when the key stakeholders will be present. Pull out the calendars and lock it in, right then and there.

When speed matters..

Don’t drown in the waterfall when developing new-to-the world medical devices. Scrum is designed for speed and can generate the right documentation needed for regulatory clearance when managed properly. Have questions or a need to go faster? That’s what we do at Archimedic. Get in touch with us if you'd like to explore a collaboration.