Move Faster & Break Nothing Transcript: Audience Q&A

Randy Horton

Published on: January 3rd, 2022

Randy Horton:

We’re going to run straight into the Q&A. Michael and Bernhard are going to take it from here. We’ve got a number of questions submitted, so we’ll try to get to as many as we can now. For the ones that we don’t answer, we’re happy to take them up offline. We are certainly happy to bridge an introduction if the speakers are willing to talk more. With that, Michael.

Michael Iglesias:

I’m going to pick good questions that will spark conversations.

Agile Versus Waterfall

Question 1: In my experience, when it comes to deciding if the development process should be Agile versus waterfall, I have found that people play the most important role. How do you shift the organizational culture to adapt their mindset to the new Agile process or methodology and also keep delivery on time?

Michael Iglesias:

I can speak to that. From my experience, Agile can be a really great thing to get a product out on the market, as well as have an impact on post-launch and DevOps by making design changes and iterations a lot quicker. But I have seen teams that sign up to do Agile, that sell it to the business unit and the product owner as Agile, then throughout the development process and design control they find they’ve signed up to do a lot more documentation and a lot more reviewing. Is there anybody else that has any reflections or experience?

Larkin Lowry:

I think one of the keys is getting the company, the business and especially the product owners to think small. Small features, small increments, small amounts of scope. Small things tend to be easier to test and validate. If you try to bite off too much at one time, it’s very difficult to validate that you’re producing something that is safe, coherent and delivering value to your customers.

It’s really more about the mindset of Agile than anything else. With waterfall, you imagine this gleaming city with flying cars and jet packs, yet at the end of the day, you have to start cutting down some trees to clear some land because you can’t go immediately to that final vision.

To successfully adopt Agile, what’s really needed is a change in the mindset. You need to be able to think more incrementally. In the medical device space, it’s a challenge to deliver small and very modest increments, because we have to demonstrate that we’re producing meaningful value to our patients as we’re doing a delivery. Again, I recommend thinking small scope, discreet and testable.

Torrey Loper:

I agree with Larkin’s comments. Two week sprints make the product releases so much more manageable for the engineering team – especially if there are fixes that need to be made. These small releases are so much more manageable for the business. You can really execute on them. In contrast, waiting on these large releases is a lot more to manage. If anything goes wrong, and it inevitably does, that’s usually when the customer is most impacted. Small releases are a lot more manageable from a business perspective.

Michael Iglesias:

I agree. To add on to that: Whatever your cadence is for iterations, deliveries or sprints, those product demos that you share with the broader team are critical to ensuring that you build the right product, even if you are doing it in small increments at a time.

Bernhard Kappe:

In my observations, it’s typically easiest to get the development teams thinking that way. It’s getting the rest of the business thinking in terms of fast feedback loops that can be difficult – especially for a medical device company that is used to hardware. In my eyes, that’s where the biggest challenge is. I think looking for champions, people who are willing to adopt new methods – especially outside of the development process – is key in terms of getting that type of adoption and demonstrating the success that allows other people to adopt it as well.

Submission Strategy for the system of systems in a medical device versus SaMD

Question 2: What is your recommended submission strategy for a system of systems in the context of a medical device versus SaMD? Is a system of systems considered an accessory to a medical device, a standalone medical device, a standalone SaMD or as something else?

Michael Iglesias:

I’m not on the regulatory side, but I have seen how having those pre-submission meetings with the FDA can be critical. I recall one product, built and designed as a Class II medical device, that somehow got watered down to a consumer electronic device. At that point, they’re thinking it’s no longer a medical device. But at the FDA pre-submission meeting, the FDA said it was a Class II medical device.

Bernhard Kappe:

You have to think about the system of systems as a combination of parts you built and parts you sourced from a third party. You need to ask yourself: What is a medical device, what is not a medical device now, and how is that going to evolve? In a given system of systems, there are likely platform-level packages that aren’t going to be submitted to the FDA, but that the medical device software products are building on top of. Internally, you’ve got to instrument these packages in such a way that you can manage their dependencies.

There’s great guidance out there on interoperability and multiple function devices that you can leverage in this scenario. But I’m not sure there’s a one-size-fits-all strategy for submissions. Not to mention that the process of submissions, and what gets submitted, is always changing.

HL7 or FHIR Integration with Hospital Systems

Question 3: Torrey, could you explain your experience on the integrations with hospital systems? Did egnite follow a standard, such as HL7 or FHIR implementations, or any other kind of process?

Torrey Loper:

We’ve done 50 plus large hospital systems so far. We’ll do a SQL extract into a virtual machine, and then a secure file transfer via HTTPS. Hospitals do this with other vendors, so it’s the approach we take as well.

Document Tools from Gherkin

Question 4: Larkin, what tool do you use to generate documents from Gherkin?

Larkin Lowry:

Actually, we “hand rolled” our own tools to produce that documentation. Our objective was to match the standard documentation that we have within Tandem. We needed such a fine degree of customization that investing in hand rolling these tools made sense.

How Do You Get Cross-Functional Stakeholders to Review in Gherkin?

Question 5: Larkin, you mentioned that your requirements are peer reviewed. How do you get cross-functional stakeholders to review in Gherkin?

Michael Iglesias:

The person who submitted this question said they’ve had trouble getting non-engineers into Git.^[1]

Larkin Lowry:

The key to peer review from non-technical stakeholders is using the web interface of your Git repo. If your organization uses GitHub, GitLab, or even Bitbucket, these platforms have web interfaces. They’re designed to allow anyone to review code, submit their comments and view the interactions with other reviewers’ approvals, no matter their level of technical knowledge or understanding of Git. Anybody who can use a web application can do it.

It’s equally important to leverage Git’s web interface to submit code changes. We don’t want to make our product owners install Git and learn how to submit commands through the command line. Fortunately, Git’s web interface allows users to submit their code and do commits in a very user-friendly way. It makes the workflow pretty straightforward.

Advice for Company Transitioning from Typical Software Company to SaMD Company

Question 6: What advice do you have for a company transitioning from a typical software company to a SaMD company? How do you manage product and engineering folks who don’t have medical device experience and background?

Torrey Loper:

I’ll share a cultural thing that really worked within our organization. We spun off from a strict medical device company into our own Clinical Decision Support Software organization. It was important to our success that we gave our engineers and software developers a feel of the fabric of the new organization. We arranged facetime with our physicians and physician advisors to help them know why we’re doing what we’re doing. They got to hear about the big clinical impact we were making directly from our customers. It really impressed upon our team the importance of doing what we do right all the time, because if we present the wrong information to a physician, bad things could happen to their patients. When you can demonstrate the bigger picture, the processes and protocols fall into place.

Larkin Lowry:

Just to add to that: The folks who are responsible for your quality and compliance need to be flexible. The practices they followed when working on physical devices can be unnecessarily rigid or inefficient when applied to a software organization, which moves much more quickly and with a greater degree of automation. There are cases where what the QA organization requires is not the ritual they’re accustomed to, but a new fundamental philosophy and an objective to meet. It’s helpful to have a quality organization that can work cross-functionally with engineers to come up with more efficient solutions that are better tuned for software.

We’ve hired a tremendous number of engineers outside of the medical device space. Their typical first reaction coming in is, “What the heck is all of this? Why do I have to do all of this?” They react in a visceral, negative way. You do have to explain our obligation to our patients to them. If we’re meeting that obligation, then compliance is the easy part.

Randy Horton:

I have just a few things to add. First, we found that while people started out scratching their heads at all of the process and documentation, over time they started to get the value and the importance of it. They said, “Yeah, I wouldn’t want my mother or father, or someone else I cared about, to have an active implantable that wasn’t made right.” They want to make devices better and get them out to market faster. That’s how you convert people to this move faster and break nothing mentality.

In five years, I hope the stuff we’re talking about today becomes commonplace. Everyone in the medical device space will work this way, because just our team here can’t possibly work on every device that might be needed by someone we love someday.

Secondly, I wanted to bring up something Larkin discussed in one of the conversations we have preparing for today’s session. It’s the idea that the regulatory processes in our industry were designed to encourage behaviors that produce safe, effective devices. The how of those processes were defined by methods and tools we had available then. Now, we’ve got methods and tools that open up the third and fourth dimension, so to speak. So when we work with regulatory people, it’s important that we get back the original intent of making safe devices. We want to ask ourselves how we can use techniques that are better than what we have now while still being responsible.

Mark Brincat:

Also, because we don’t know the person who asked the question and what their particular situation is, it also depends on where they are with their SaMD product in the market. What they make could fall anywhere between entry level to very-high end medical device products. Knowing that would impact our advice. My general comment is, if you’ve got a group of disciplined software engineers that need to transition into SaMD, don’t think of it as frightening. Also, there are other highly regulated markets out there that are rich recruitment grounds for finding engineers interested in moving into SaMD.

Randy Horton:

Thanks to everyone in the audience for hanging here with us today. I hope you found a lot of value in what we had to say. I of course want to thank all of our panelists and speakers today. You gave us a tremendous breadth and depth of content.

As for the audience, we can try and get to your questions offline. You’re welcome to reach out to the panelists through LinkedIn:

Bernhard and I also have our contact information:

We’d welcome your feedback on what could make this session better, what you’d like to see more of and if you have any topics you’d like to see discussed in the future.

Below is a list of the other sections of our Move Faster & Break Nothing Webinar:

Reference

1. About - Git. Git-scm.com. https://git-scm.com/about. Accessed January 3, 2022.

Back to Insights