It’s been 10 years since AAMI published TIR:45 2012, Guidance On The Use Of AGILE Practices In The Development Of Medical Device Software. Over the last decade, Orthogonal and its colleagues have taken part in the broad Agile transformation of medical device software, particularly related to the development of Software as a Medical Device (SaMD) and connected medical devices.
Our industry has learned a tremendous amount about the best (and worst) practices for accelerating the development of medical device software using Agile, Lean and other iterative product and software development methods. Now we’re ready to innovate with these methods even further – to move faster while breaking nothing.
Orthogonal is marking the 10th anniversary of TIR:45 by hosting a series of events and conversations. In the second half of 2022, we will bring together industry leaders to share cutting-edge insights, so collectively we can improve patient outcomes and drive business results.
On June 24th, 2022, we hosted a short but insight-packed kick-off conversation with two of the most sophisticated practitioners of Agile SaMD development. You can watch the full recording of the webinar below:
For other events in this series, check out our Move Faster and Break Nothing Webinar Series.
Michael Iglesias, who has worked on SaMD at a number of world-class MedTech firms (J&J, Eli Lilly, Novo Nordisk, and Philips) before joining Roche as a Global Advisor on Digital Health Quality & Compliance. Prior to working in SaMD, Michael was on the team at Apple developing the very first iPhone.
Larkin Lowrey, who most recently worked at Tandem Diabetes Care as a Senior Director for Software Engineering. He implements Agile best practices learned over 20+ years from building high-performance software engineering teams and products for two other critical infrastructure industries: telecommunications and automotive.
The following is a summary of key points discussed during the webinar.
“Everybody seems to have a different idea of what Agile is, how to employ Agile and how to follow Agile practices,” said Larkin. Agile isn’t a software engineering methodology. Rather, it’s a product development ideology that has wide applications. Agile can encompass every part of your business – including finance, customer service, and yes, software development.
Larkin addressed the misconception that Agile’s purpose is to make things faster. “To me, the point of Agile is to manage your risk.” Efficiency and speed aren’t the objectives of Agile – they’re the by-products of successfully managing risk.
To illustrate his point, Larkin described an organization he joined in the aftermath of the Dot Com bubble. It was like the Wild West, where everyone was “basically running around with scissors.” The product owner would come up with grandiose ideas for a product. But when the product was released to the market, it flopped. “We would get crickets,” Larkin said. The product owner came up with a Plan B; it also flopped. Plan C didn’t even make it through development.
Once they adopted Agile processes, things changed for the better. Shorter iterations cut the product owner’s big ideas into manageable pieces. Because they received feedback from the market sooner, they could make a product customers actually liked. By reducing risk and cutting down on their predictions about the market, they were able to work faster and more efficiently.
“What we have to do is try to reduce the time scale that we’re trying to make predictions about. As we start to pull in our horizon, our assumptions and our predictions get more accurate,” said Larkin. “When you think about what we have to do within MedTech, Agile is a natural fit. Everything that we do has to do with managing the risk of the product that we’re delivering. Agile is the perfect and ideal process for MedTech.”
“Being on the mobile software side, Agile is definitely something you have to do,” said Michael. “When mobile apps are paired with cloud technologies, Agile just makes sense.” Michael has seen multiple companies starting to embed Agile processes and phases into their traditional waterfall or V models. It’s becoming a hard requirement for software-based products.
With Agile development projects, Michael said it’s easier to spot early on when something is going wrong as the device takes shape. If, once reaching the market, a product has a lot of deviations, complaints or quality issues, it can become clear that something needs to change how an organization develops future products. Success using Agile, on the other hand, will look different for every company. For example, a well-made product might get pulled from the market for a variety of business reasons unrelated to what the team developed.
From an engineer’s perspective, Michael said that Agile’s emphasis on frequent testing gives developers confidence in their product. By doing testing early and often throughout the development process, engineers get a continually updated sense of if they’re headed in the right direction or not. Not only is the product delivered on time, but the risks have been managed and the requirements have been met.
From a product owner’s perspective, Larkin said that Agile gives them quick feedback on their “crazy” ideas. “Instead of thinking about how to reimagine the product or how to pivot the product, product owners are thinking about how to build upon the product that they’ve already created.”
Lakin credited Orthogonal with introducing him to Three User Thursdays: The practice of running a human factors study with every sprint. It enabled the team to get ahead of use errors, user preferences and provider needs, and made product owners more confident in their product.
Larkin sees Agile helping with software segregation. The FDA doesn’t have the time to regulate the non-medical device parts of SaMD. “It’s very important to make sure that we can develop our software, and have it be partitioned in such a way, that we can manage the software development life cycle for that particular slice independent of other slices,” Larkin said.
He also sees Agile methods extending into documentation. Larkin found success using the programming language Gherkin to automate requirements tests in a format that is easy to write and understand. (For more information on Gherkin and requirements testing, check out a (great) prior presentation that Larkin gave on this case study.) Using Agile processes to automate testing will reduce the workload associated with document management.
Michael sees Agile principles informing FDA documentation requirements. “From a regulatory perspective, the FDA is moving away from traditional computer software validation.” This reflects one of the pillars of the Agile manifesto: Spend time making working software rather than spend time documenting it. He believes the FDA will continue to accept Agile into its frameworks.
Michael also advised starting small using Agile by taking a piece of software and seeing what it needs to fulfill its purpose, rather than starting out with a big idea and trying to do the entire device using Agile all at once. He sees the value of applying the Agile spirit of working in small chunks to the gradual development of a well-documented medical device.
To conclude the idea, Larkin touched on how incremental building needs to get approval from higher ups in the business. If the very top of the organization wants to deliver on a moonshot, it’s going to be a “miserable experience.” He believes that we have to change as an industry and embrace the value that Agile brings to developing real working software. He also believes that we need to reevaluate the role of documentation and how we can make it accessible to someone who is not a software expert.
You can view the recording of the full webinar below.
If you are interested in future events in this series, sign up for our Move Faster and Break Nothing campaign mailing list.