“You’ll have to learn to pace yourself, pressure. You’re just like everybody else, pressure” – Billy Joel, Pressure
The quote above should resonate with anyone from the product development world reading this blog. Pressure is always present in product development. Get the product to market faster, cheaper and with more features.
“We have to hit this date!” “Can you incorporate this last-minute change? Sales says it will guarantee this customer’s business”, and “We have to remove this feature – it’s not passing our testing” are all common refrains within any product development organization.
What makes the Medical Device world unique is the added pressure of having to pass regulatory scrutiny. It’s all the above statements plus, “Will the FDA approve this?”.
Of course, the common answer to this challenge, is “Let’s implement Agile!” and while everyone around the table nods affirmatively, someone in quality or regulatory starts getting nervous.
That reaction is understandable. Agile is often presented as a way to move fast, embrace change, and reduce documentation. Medical device development requires traceability, risk management, and evidence that the work was done correctly. Those can sound like opposing ideas.
They aren’t! The problem isn’t Agile. The problem is applying Agile practices without understanding the environment in which the product is being developed. At agilityIRL, we believe the answer isn’t to choose between agility and compliance. It’s to build a way of working where they reinforce each other. That’s what we mean by “Agile that speaks FDA”.
Agile Doesn’t Mean Do Whatever You Want
Agile is not the absence of discipline. Instead, it is being disciplined about a simple set of practices and giving the team freedom outside of those practices to self-manage. This concept is crucial to understanding how Agile fits within the medical device world.
In a regulated environment, this discipline means that compliance work is part of product development. It shouldn’t be treated as something that happens after development is “finished.”
When testing, documentation, traceability, and other quality activities pile up at the end of development, teams can face a painful pre-release scramble. Work that appeared complete suddenly isn’t, problems surface late, and rework grows – resulting in a release that seemed close being months away. agilityIRL’s approach is to make releases more seamless by addressing that work throughout development rather than saving it for the finish line.
In other words, done should actually mean done.
Build Quality In
For years, Lean manufacturers have known that it’s cheaper to build quality into the product development process than it is to inspect in via post-development testing.
This idea is crucial to applying Agile within a regulated environment.
Using AAMI TIR45 as guidance, teams can integrate regulatory and quality activities into iterative development so that each sprint moves the product toward a genuinely completed quality product. The goal is to get to “Done: every sprint while maintaining the evidence and controls the organization needs.
That changes the conversation. Instead of asking, “When will development be finished so Quality can do its work?”, teams can ask “What does it take for this increment to meet our definition of done?”
Quality becomes part of the work rather than a gate waiting at the end of it.
Your QMS is Part of the System
Often the team isn’t the issue. In the words of W. Edwards Demming, “a bad system will beat a good person every time”. Your Quality Management System (QMS) is a part of that system.
Maybe your QMS was built around a sequential development model. Processes, documents and approvals may unintentionally push teams back toward large batches of work.
agilityIRL takes a systems view of organizational change. Moving toward a more adaptive way of working affects more than the team or its framework. Processes, organizational structures, leadership behaviors, and culture all influence how work actually gets done.
In medical device organizations, that means taking a second look at the QMS too.
The goal isn’t to throw out the controls that support compliance. It’s to evolve the system so those controls can support iterative delivery. Our goal is to create better visibility throughout development while maintaining traceability and audit readiness.
Transparency Matters Even More When You’re Regulated
Iterative development creates another important benefit: visibility.
In traditional development approaches, it can be difficult to know the true state of a product until very late. Status reports may say things are on track while significant validation, verification, or documentation work remains.
Working in small increments makes the actual state of the product easier to see. Stakeholders can inspect real progress rather than rely primarily on theoretical measures of completion.
In a medical device environment, that transparency can bring product, engineering, quality, and regulatory stakeholders into a more useful conversation. The conversation moves from “Have we hit our milestone?” to “Here is what is actually complete”.
That’s a much better place from which to manage both compliance and overall delivery.
Agile Can Work in Medical Devices
Billy Joel had it right: you have to learn to pace yourself under pressure.
For medical device teams, that pressure isn’t going anywhere. There will always be another deadline, another regulatory expectation, another quality concern, and another reason to get the product into customers’ hands sooner.
The answer isn’t to move faster by cutting corners. And it isn’t to let your compliance requirements turn every release into a last-minute scramble.
It’s to build a way of working that can handle the pressure: delivering in smaller increments, building quality and compliance into the work, and knowing what “done” really means every step of the way.
That’s Agile that speaks FDA.
Because you may not be able to turn down the pressure. But you can get a whole lot better at working under it. “You’ll have to learn to pace yourself, pressure
You’re just like everybody else, pressure” – Billy Joel, Pressure
The quote above should resonate with anyone from the product development world reading this blog. Pressure is always present in product development. Get the product to market faster, cheaper and with more features.
“We have to hit this date!” “Can you incorporate this last-minute change? Sales says it will guarantee this customer’s business”, and “We have to remove this feature – it’s not passing our testing” are all common refrains within any product development organization.
What makes the Medical Device world unique is the added pressure of having to pass regulatory scrutiny. It’s all the above statements plus, “Will the FDA approve this?”.
Of course, the common answer to this challenge, is “Let’s implement Agile!” and while everyone around the table nods affirmatively, someone in quality or regulatory starts getting nervous.
That reaction is understandable. Agile is often presented as a way to move fast, embrace change, and reduce documentation. Medical device development requires traceability, risk management, and evidence that the work was done correctly. Those can sound like opposing ideas.
They aren’t! The problem isn’t Agile. The problem is applying Agile practices without understanding the environment in which the product is being developed. At agilityIRL, we believe the answer isn’t to choose between agility and compliance. It’s to build a way of working where they reinforce each other. That’s what we mean by “Agile that speaks FDA”.
Agile Doesn’t Mean Do Whatever You Want
Agile is not the absence of discipline. Instead, it is being disciplined about a simple set of practices and giving the team freedom outside of those practices to self-manage. This concept is crucial to understanding how Agile fits within the medical device world.
In a regulated environment, this discipline means that compliance work is part of product development. It shouldn’t be treated as something that happens after development is “finished.”
When testing, documentation, traceability, and other quality activities pile up at the end of development, teams can face a painful pre-release scramble. Work that appeared complete suddenly isn’t, problems surface late, and rework grows – resulting in a release that seemed close being months away. agilityIRL’s approach is to make releases more seamless by addressing that work throughout development rather than saving it for the finish line.
In other words, done should actually mean done.
Build Quality In
For years, Lean manufacturers have known that it’s cheaper to build quality into the product development process than it is to inspect in via post-development testing.
This idea is crucial to applying Agile within a regulated environment.
Using AAMI TIR45 as guidance, teams can integrate regulatory and quality activities into iterative development so that each sprint moves the product toward a genuinely completed quality product. The goal is to get to “Done: every sprint while maintaining the evidence and controls the organization needs.
That changes the conversation. Instead of asking, “When will development be finished so Quality can do its work?”, teams can ask “What does it take for this increment to meet our definition of done?”
Quality becomes part of the work rather than a gate waiting at the end of it.
Your QMS is Part of the System
Often the team isn’t the issue. In the words of W. Edwards Demming, “a bad system will beat a good person every time”. Your Quality Management System (QMS) is a part of that system.
Maybe your QMS was built around a sequential development model. Processes, documents and approvals may unintentionally push teams back toward large batches of work.
agilityIRL takes a systems view of organizational change. Moving toward a more adaptive way of working affects more than the team or its framework. Processes, organizational structures, leadership behaviors, and culture all influence how work actually gets done.
In medical device organizations, that means taking a second look at the QMS too.
The goal isn’t to throw out the controls that support compliance. It’s to evolve the system so those controls can support iterative delivery. Our goal is to create better visibility throughout development while maintaining traceability and audit readiness.
Transparency Matters Even More When You’re Regulated
Iterative development creates another important benefit: visibility.
In traditional development approaches, it can be difficult to know the true state of a product until very late. Status reports may say things are on track while significant validation, verification, or documentation work remains.
Working in small increments makes the actual state of the product easier to see. Stakeholders can inspect real progress rather than rely primarily on theoretical measures of completion.
In a medical device environment, that transparency can bring product, engineering, quality, and regulatory stakeholders into a more useful conversation. The conversation moves from “Have we hit our milestone?” to “Here is what is actually complete”.
That’s a much better place from which to manage both compliance and overall delivery.
Agile Can Work in Medical Devices
Billy Joel had it right: you have to learn to pace yourself under pressure.
For medical device teams, that pressure isn’t going anywhere. There will always be another deadline, another regulatory expectation, another quality concern, and another reason to get the product into customers’ hands sooner.
The answer isn’t to move faster by cutting corners. And it isn’t to let your compliance requirements turn every release into a last-minute scramble.
It’s to build a way of working that can handle the pressure: delivering in smaller increments, building quality and compliance into the work, and knowing what “done” really means every step of the way.
That’s Agile that speaks FDA.
Because you may not be able to turn down the pressure. But you can get a whole lot better at working under it.