Secrets to Unlocking Agile Benefits for Medical Device Development

In my consulting work I often help clients incorporate agile methods into their medical device software development. There are many benefits to doing this but we often struggle with communication and alignment issues during these projects. So I was very pleased to meet Dorian Simpson and Vishal Sheth and discover their MAHD Framework. The framework provides a clear, practical way to adopt agile principles that aligns remarkably well with my recommendations for development of software-intensive medical devices. Rather than piecing together a solution from scratch, companies can leverage a ready-made solution in the MAHD Framework. In this article we describe how MAHD can be applied to medical device development and how it addresses some of the most challenging problems for development of software-intensive medical devices.

-Aaron Joseph

Dorian Simpson – MAHD Framework, LLC
Vishal Sheth – MAHD Framework, LLC
Aaron Joseph – Sunstone Pilot, Inc.

As healthcare technologies rapidly evolve, with more software and more interconnection, developing new medical devices at an ever faster pace becomes ever more challenging. Product teams need to design hardware, firmware, and software components to integrate seamlessly together, often with complex architectures and interfaces, and to deliver these new products on an accelerated schedule while maintaining rigorous compliance. Traditional processes for medical device development using waterfall-style NPD frameworks cannot keep up with these new challenges. 

Problems with Medical Device Development

From our experience with dozens of medical device development projects, we’ve seen the same problems over and over again:

• Products that don’t meet or beat customer expectations
• Long lead times to bring innovations to market
• Schedule overruns 
• Design flaws discovered late in development leading to expensive delays (or product recalls)
• Subsystems developed in silos leading to long delays in system integration and non-optimal system designs
• Compliance problems with design controls (best practices for product development vs. following the SOPs)

What are some of the root causes?

We often find a range of common patterns that derail even the best-intentioned medical device development efforts:

• Launching directly into development without clear insight into user / customer needs
• Waiting to truly investigate customer needs until a working product is ready for evaluation
• Having inconsistent alignment across all disciplines (hardware, software, clinical, regulatory, manufacturing, service, etc.)
• Underestimating the development time from a working breadboard to a commercial product
• Planning a single major integration milestone to combine subsystems developed in silos
• Proceeding through development without alignment on strategic constraints–regulatory strategy, applicable standards, key metrics for success, target dates
• Mismatched design control procedures that don’t align with best practices for product development
• Following a plan instead of responding to change leading to accumulation of risk and difficult trade-offs late in development

How might companies solve these problems?

Organizations that realize there is a problem, and attempt corrective action, often fall into one of three categories:

1. Keep the status quo!  Replace the project manager and hope for better results next time.
2. Incorporate more prescriptive process elements. Add more details to gates/reviews, more forms, and more controls for senior management to monitor each project at every step.
3. Adopt a better product development process. Change the way product development teams collaborate, learn, align, and execute.

While most will recognize that Option #3 is the best approach to solving development challenges and achieving long-term success, it’s also the only option that involves potential compliance risk. And this makes it difficult for organizations to pursue with conviction.

While there are many misconceptions and misapplications of “agile” methods, the core principles of agile can address all of the development problems we have listed. In this article we explain how companies can confidently pursue Option #3 with a proven framework–without sacrificing regulatory compliance.

Why not just use Agile (for Software)?

Over the past 20 years, agile methods have become popular and successful for developing non-regulated software. However, medical device companies that try to adopt these methods directly to their regulated products will immediately find that agile methods will conflict with their quality system and hardware development processes. The agile experiment often ends quickly with concerns of products that may be unsafe for their clinical application, cannot get regulatory approval, or are impossible to manufacture.

It’s been proven that agile methods offer many advantages in software development such as improving customer focus and value, flexibility in responding to changes, and finding defects earlier. However, medical device companies attempting software Agile methods will likely suffer from one or more of these traps: 

1. Teams struggle with trying to build physical components in 2-week sprints, 
2. Lack of a project timeline undermines alignment with all stakeholders, 
3. Compliance problems which result in rework or future audit failures, or 
4. Losing the advantages of agile methods when integrating into their quality system.

This has led to most medical device companies shying away from agile for product development. However, medical device companies can benefit from embracing agile principles, but need to modify the tactics to provide the governance, controls, risk management, and regulatory compliance so critical to medical device development.

Multiple Types of Project Risk to Address

Before sharing the details of what a modified agile for medical devices might look like, it’s important to understand the types of risks that are involved in developing innovative new medical devices. Any process we implement must be able to uncover, track, and mitigate each of these risks for any project:

• Technical Risk—Will the technology work (engineering/scientific challenges)? Are we trying to violate the laws of physics or biology? 
• Marketing Risk—Do we have the right product? Is the clinical job to be accomplished well understood? Does the product add enough value that customers are willing to pay for it?
• Regulatory Risk—Will we be able to get regulatory approval for this innovative device? What is the best regulatory pathway to get approval?
• Clinical Risk—Will the new product be clinically effective? Will the benefits of using it outweigh the costs of switching to a new product?
• Safety Risk—Will patients or medical personnel be harmed by the new product? 
• Business Risk—Can we produce this new product and be profitable? What are the basic assumptions on ranges for cost of goods and margin targets?
• Intellectual Property Risk—Do we have the freedom to operate? Can we build barriers to entry?

Overlooking any one of these categories of risk can be fatal for a project! This means a concentrated effort is needed early in the project  to ensure that the product team is headed in the right direction, and then throughout product development to systematically mitigate these risks to the satisfaction of all stakeholders. Simply put, our process needs to promote rapid learning to close knowledge gaps, while at the same time providing “guard rails” (clearly defined constraints) so the product team can safely proceed at high speed with maximum maneuverability and flexibility.

Traditional approaches to medical device development, such as in the figure below, just don’t satisfy these needs. They consume valuable time and energy at the beginning of a project (when enthusiasm is high!) on planning and requirements. This sounds logical but it delays crucial work and focused energy on addressing the project risks listed above. Further, many companies’ product development processes are defined by lists of Design History File (DHF) documents that must be written to pass gates (phase reviews).  This easily allows product teams to move the project forward without addressing the key project risks. Instead of reducing (or even identifying) risks at the beginning of development, they are allowed to become “project bombs,” ready to explode in later phases where they can devastate teams and are much more expensive to resolve.

Now that we’ve described the challenges of traditional approaches and hinted that an agile approach is a better way,  the rest of this article will explore the Modified Agile for Hardware Development (MAHD) Framework®. This approach, combined with modern design control procedures, eliminates the limitations of traditional project management, while addressing all of the risks and compliance needs associated with Medical Devices.

A Proven Agile Framework Purpose-built for Hardware

The Modified Agile for Hardware Development (MAHD) Framework  provides an agile-based product development process that is purpose-built for physical product development. Since 2017 the framework has been implemented successfully by hundreds of companies across multiple industries, including many medical device companies. 

The Benefits of the MAHD Framework

Organizations that have adopted the MAHD Framework have seen major improvements in quality, value, and time-to-market leading to significant increases in profit and ROI. They often see 25% to 50% improvements in time-to-market while reducing risk, increasing customer value and enhancing predictability. While these benefits are derived from Agile principles as a foundation, they are not achieved through commonly understood software-based Agile tactics.

The MAHD Framework defines methods and tactics that align with the needs of hardware development teams while enabling the benefits of intense focus, the ability to adapt to change, and leveraging iterative, learning-based development. These benefits and key MAHD principles are described further in Figure 2.

MAHD: Keep Agile Principles, But Modify the Tactics

The MAHD Framework focuses on five core success pillars, similar to those found in the Agile Manifesto, that have been found to drive the right mindset and effectively guide new hardware development activities:

1. 1. Strategic Vision: Success begins with clear priorities and “strategic intent”
   2. Empowered Teams: Give teams the autonomy to execute with optimal governance
   3. Customer Insight: Minimize opinions with data directly from customers
   4. Short Development Cycles: Iterate often to execute, learn, and adapt quickly
   5. Execution Excellence: Provide agile tactics that deliver benefits to hardware teams

To get the promised benefits of agile, while meeting the needs of hardware and medical device development, modifications of common agile methods are required. As shown in Figure 3, the MAHD Framework modifies four important areas in the development process:

1) MAHD On-ramp: Initiating a project for Agile success – While software teams may be able to write a set of User Stories and immediately get started, the nature of physical products requires additional upfront planning activities to structure and initiate projects in the right direction. 

2) IPAC Iterations: Alignment-based learning and execution cycles – Just as defined for Agile software, the MAHD Framework leverages short development cycles. But MAHD includes two levels of cycles to accommodate and align the range of disciplines and subsystems needed for hardware development.

3) Aligned Backlogs: A cross-discipline, flexible backlog structure – Hardware teams need a more flexible backlog to organize work by discipline and subsystem, track iteration milestones and manage other needs software projects don’t have.

4) Hardware-aligned Roles: Cross-discipline teams and appropriately defined roles – While MAHD includes the well-known agile role of “Product Owner”, it’s defined differently and you won’t find “scrum masters” on a MAHD project. Similar to agile tactics, MAHD defines roles to meet the needs of hardware teams.  

These differences are critical to allow rapid adoption of agile methods by hardware teams, but also help accommodate the additional needs of regulated medical devices, whether they are hardware-software products or software-only (SaMD).

Let’s examine each area of modification in more detail.

The MAHD On-Ramp

One of the biggest challenges and time sinks in product development is the “fuzzy front end.” The MAHD On-Ramp solves this by clarifying the project with just enough detail to get started on the right path at the right speed. Rather than project front ends taking months (and sometimes years!), it can be measured in days or weeks.

Once an opportunity is identified, the first step to initiate a MAHD project is the creation of an Agile Vision Brief. This is a short document written by a Product Manager to succinctly describe the strategic intent, constraints and priorities of the project. Rather than the traditional Product Requirements Document (PRD) that is passed off to R&D, the Vision Brief sets up the problem for the team to solve. From this short 1-3 page brief, the team is ready to dive into the project.

The MAHD On-ramp then defines five cross-functional team activities to clarify customer needs, set goals, evaluate risks, identify important areas for innovation, and develop a path to success.  These activities are designed to set the team in the right direction, establish clear constraints on development, and collaboratively plan initial development work (e.g., the start of Phase 1 work). After working through the on-ramp activities, which typically take a few days to a few weeks, the team is ready to execute. The five MAHD On-ramp activities include:

1. User Stories – Hardware teams often struggle to write and implement Agile’s User Stories. The MAHD Framework addresses this by using a systems-based approach tailored to defining physical products.
2. Product Attributes – Agile for software replaces requirements with User Stories and traditional development relies on product requirements. The MAHD Framework avoids starting with “requirements” altogether by establishing an early solution framework based on product attributes that will evolve to detailed features and specifications as needed by hardware solutions.
3. Focus Matrix – This critical activity and tool, exclusive to the MAHD Framework, serves as a crucial bridge to align the team while enabling Iterative planning, establishing the right prototype strategy, driving innovation, removing risk, and maintaining strategic focus.
4. Initial IPAC Iteration Plan – IPAC Iteration Planning and Reviews are central to the MAHD Framework, aligning all disciplines, including software, on every aspect of the project. The On-ramp isn’t over until the initial IPAC Iteration plan is agreed to, along with the specific deliverables for the first iteration.
5. Work Backlog – This Backlog is unlike typical software backlogs. It is structured around subsystems, disciplines, and Iteration milestones and filled with work items, not user stories. For medical devices, compliance activities and DHF documentation are tracked and executed as critical elements of the Backlog. The last step of the On-ramp isn’t to fill the Backlog with all project tasks but to agree on the structure and ownership, with just enough work to get started.

 

IPAC Iterations

An essential difference of the MAHD Framework compared to Agile for software is the use of IPAC Iterations. With each iteration, usually one to six sprints in length to allow flexibility, teams define meaningful milestones by working through four key project elements that reinforce and leverage agile principles: Integration goals, Prototype strategies, Alignment needs, and Customer engagement activities (IPAC). Effective IPAC Iteration planning  is a critical success factor in agile for hardware, allowing teams to:

1. Align subsystems, disciplines, and software with key milestones, often producing demonstrable outputs for learning or customer feedback;
2. Serve as an overall schedule to track and communicate project progress, ensuring management support;
3. Minimize meeting overhead by focusing on major milestones while enabling smaller teams to manage their own Sprints efficiently.

 

Solution Evolution through IPAC Iteration Deliverables

As shown in Figure 4, the nature of work evolves throughout the project with MAHD principles and key concepts providing the guidance to direct optimal effort. Early in development teams explore design options, marketing refines desired outcomes and teams systematically remove risk. With each IPAC Iteration, the amount of divergent thinking goes down and execution deliverables go up. Solution design and technical decisions are nailed down with each learning and execution cycle. As the team nears product completion, the design is frozen and IPAC Iterations focus more on production challenges and preparing for launch. 

One key concept MAHD teams focus on to optimize risk mitigation and learning is thinking of the solution in terms of “vertical slices.” These may be small parts of various systems that come together in the form of flexible fidelity prototypes to resolve technical or commercial risk. 

Unlike software sprints, IPAC Iterations are not constrained to a fixed cadence. The length of each iteration is determined based on the needs of the project allowing optimal use of time. For example, if it takes five weeks lead time for some hardware components and one week build time for a new prototype system then the length of that IPAC Iteration will be based on those timelines. A short iteration may then be used for capturing learning to inform the next, longer iteration. One essential outcome of the MAHD On-ramp is to establish a preliminary prototyping strategy that makes sense for the project, not a forced mandate to deliver “a working prototype every iteration” that is often heard in agile circles.

A common question from those new to agile for hardware is, “Isn’t it wasteful to iterate the design?”  Yes!  For simple projects with few unknowns, it may make no sense at all. Similarly, if the team has perfect knowledge, flawless communication amongst all stakeholders, and exactly zero changes in requirements throughout development. But if any level of innovation is required, these conditions are rare and teams universally find that an intelligent, iterative approach delivers more valuable solutions, faster.

MAHD Flexible Backlog

In software development, the backlog is usually a single prioritized list combining user stories, bug fixes, and technical tasks. In the MAHD Framework, Backlogs are divided into swim lanes to address the needs of cross-discipline teams, subsystems, and non-technical tasks. Since prioritizing tasks across disciplines is nearly impossible, each swim lane contains its own prioritized task list managed by an owner, typically a technical lead, responsible for adding and maintaining tasks.

Other items that are tracked in the MAHD Backlog include: 

• User Stories – Keeping these in the Backlog is good practice to track and validate, but the associated tasks to satisfy them through Product Attributes will be spread across swim lanes. This swim lane is owned by the Product Owner.
• Prototypes, Iteration Milestones and System Deliverables – These are tracked in their own swim lane to manage system-level outcomes and tasks, usually overseen by the Agile Project Leader or a systems Technical Leader.
• Other Stakeholder Groups – Marketing, Product Management, Manufacturing and other groups have their own swim lanes to track tasks and connect them to IPAC Iteration and Sprint goals.
• For medical devices – Compliance activities and DHF documentation. These are incorporated into all swim lanes.

During the MAHD On-ramp, the Backlog structure is established, swim lane owners are identified, and tasks are added to support the successful completion of the first Iteration. Once the Backlog preparation step of the On-ramp is complete, teams can plan their first Sprint and begin executing specific project tasks.

MAHD Roles and Teams

While Product Owners and scrum masters run the agile show in software, the MAHD Framework defines a set of flexible roles to meet the needs of hardware development. The most important difference is that the level of collaboration enabled between these roles can make or break agile for hardware success. More information about these roles is available on the MAHD Framework website but summarized here:

• MAHD Product Managers – This role is similar to how many companies define Product Managers, but they aren’t simply writing product requirements. They are externally facing collaborative market success enablers bringing in the best market and customer data to the team at the right time and guiding decisions to optimal outcomes. 
• MAHD Product Owners – This internal-looking keeper of customer success is often not a dedicated role, but a shared hat. They are the yin to the Product Manager’s yang to keep the team focused on customer value.
• MAHD Project Leaders – This soul of the team is the master facilitator. No tracking action items or tweeking Gantt charts, but a strategic member of the team to drive IPAC Iteration planning and remove hurdles. 
• Technical Leaders – The reason technical leaders love the MAHD Framework is that they are allowed and expected to be technical leaders. They solve problems, develop prototype strategies, investigate innovation options and are central to delivering optimal customer value. 
• MAHD Coaches – Not a dedicated role, but an amazing professional growth opportunity for a team member to build new agile, leadership and coaching skills to keep the team focused and leveraging agile methods.

This may look like a lot of roles. But they are similar to the roles people play today in hardware development. What changes in the MAHD Framework is their mindset, skills in agile development, and approach to project success. 

MAHD for Medical Device Development

The structure of the MAHD Framework as just described aligns well with best practices for medical device development. Figure 5 below illustrates key aspects of the MAHD Framework and how they can be applied to medical device development.  

• The MAHD On-Ramp activities complete Phase 0 (pre-design controls) and provide a plan for work in Phase 1. 
• The IPAC Iterations manage work from Phase 1 through to product launch. 
• Each Iteration establishes a milestone which can be tied to key aspects of product development phases defined in the company’s quality system. For example, completion of Phase 2 of the design controls can be marked by a design review based on the results of the latest IPAC Iteration. 
• Multiple work streams across functional groups are involved throughout the IPAC Iterations, with the intensity of each work stream varying by the stage of development.
• The vertical slices produced by each Iteration reinforce integration across subsystems and across functional groups. DHF documentation is produced and refined as part of the IPAC Iterations.

Early in development the Iterations focus on exploration of design options and tackling the “Big Rocks.” As described in the MAHD Framework, Big Rocks are the highest impact unknowns in each new product development project and must be addressed early. Subsequent iterations refine the product design while developing new manufacturing processes and the supply chain. Finally, in the later stages of the project, the Iterations coordinate complex, cross-functional activities: V&V testing, regulatory submissions, completion of design transfer, and readiness for product launch. 

MAHD Enhances Design Controls

Design controls and medical device development often seem to be in conflict, leaving teams to choose between best practices and compliance with their quality system. Unlike common agile methods, the MAHD Framework does not conflict with, and in many ways can enhance compliance with design controls. 

Focus on User Needs and Usability: The MAHD On-Ramp activities focus the product team on user needs and this is reinforced and refined through repeated evaluations of prototypes throughout development by users and other stakeholders. This is far more effective than a single usability evaluation at the end of development or discovering issues during a clinical study.

Effective System Integration: IPAC Iterations foster the repeated integration of work from multiple groups within the company and from external organizations such as development partners or UX designers or contract manufacturers. 

Defects Fixed Sooner: Repeated product testing throughout development, not just at the end, enables the team to find and resolve defects early.

Risk Analysis and Risk Controls: Repeated integration and testing verifies the effectiveness of risk controls and can uncover hidden risks.

Strategic Flexibility: The IPAC Iterations enable important design improvements late in development without jeopardizing the project schedule or compliance. For example, the team could add a software feature based on user feedback. 

Well-Written Requirements (design inputs): Requirements are understood and refined through the IPAC Iterations (solution evolution). This creates requirements that are comprehensive, testable, and fully reflect evolving understanding of user/stakeholder needs.

Complete and Up-to-Date DHF: Repeating design control activities reinforces the processes and improves the DHF documentation with each iteration—the team keeps repeating until the product design and the DHF documentation are correct.

Safety Risk Management

Can a general purpose product development framework like MAHD ensure proper safety risk management per ISO 14971?  The characteristics of the MAHD Framework combined with well-designed quality system procedures can support rigorous and efficient safety risk management. Because MAHD emphasizes upfront analysis of project risks, crucial early work on safety risk management readily fits into its structure (risk management planning, hazard analysis, etc.). And the IPAC Iterations naturally reinforce risk management through repeated development, refinement, and testing of risk controls.  Iterations are also an effective way to identify additional sources of risk such as hardware failures, software failures, use errors, etc. and to refine probabilities of known risks. 

QMS versus MAHD

We have described how the MAHD Framework can enhance medical device quality but that doesn’t mean that it won’t conflict with procedures in some companies’ quality systems. To take full advantage of MAHD, some modifications to SOPs and other parts of the quality system may be required. Here are some common areas of conflict:

Forced waterfall: Design control procedures that force a waterfall approach for all projects may conflict with the MAHD Framework. For example, mandating that all requirements are completed and released before development starts will delay crucial feasibility work (IPAC Iterations) early in development. Teams must be able to start without detailed requirements, collaboratively defining solutions and optimizing tradeoffs through rapid learning and execution cycles. The requirements are written as the teams proceed and are finalized before design freeze and V&V. Gates are completely compatible with the MAHD Framework; your specific defined gate deliverables may not be.

Extensive upfront planning: Requiring multiple detailed formal plans at the beginning of a project means that they will be written with only partial information and will delay the beginning of development work. Instead, plans can be skeletons with details only for the near-future and high-level for the rest of the project (sometimes this just-in-time approach is referred to as “rolling wave planning” or “appropriate planning”). The goal should be to start new projects in the right direction and to do it rapidly (in weeks not months).

Testing only late in development: If the design control procedures only require test results in the “V&V phase” then it may be difficult to get sufficient testing resources earlier and the team won’t be able to properly conduct IPAC Iterations.

One-size-fits-all change management: To take full advantage of the IPAC Iterations, the product team needs to be able to efficiently make frequent changes to the product design early in development. If the quality system manages these development changes with the same process as production changes (with numerous cross-functional approvals) then it will greatly slow down development. This will inhibit learning and slow reductions of project risks. Instead, a lightweight change process should be used early in development with greater rigor and approvals added as the project approaches V&V, leading to full production controls approaching product launch.  

Changes to quality system procedures may seem expensive but are well worth it to significantly improve product development outcomes.

Advantages of Using MAHD for Medical Devices

Returning to the common problems in new medical device development we listed above, here are key ways that the MAHD Framework addresses those problems.

Common Problems	MAHD Framework
Products that don’t meet or beat customer expectations	Upfront focus on user needs (On-Ramp activities) followed by repeated evaluations of prototypes by users and other stakeholders throughout development; prioritizing development around user needs
Design flaws discovered late in development leading to expensive delays (or product recalls)	Repeated system-level product testing throughout development to find and resolve defects early
Schedule overruns	Early decisions, systematic risk mitigation, progress measured in working prototypes and test data ensures clear visibility of “work to be done” and avoids overly optimistic schedules by managers
Subsystems developed in silos leading to long delays in system integration and non-optimal system designs	IPAC Iterations force integration of work from cross-discipline teams as well as from external organizations such as development partners or UX designers or contract manufacturers
Compliance problems with design controls	Repeating design control activities reinforces the processes and improves the DHF documentation with each iteration (iterating until both the product design and the DHF documentation are correct)

 

Conclusions

Agile methods won’t magically deliver great products faster—despite what some consultants may suggest. The benefits of speed and higher customer value come from several key underlying factors:

• Accelerated project initiation: By starting with focused, collaborative activities instead of lengthy document exchanges, teams can save months on the front end and move quickly in the right direction.
• Early and continuous alignment on priorities: Agile methods ensure focus, reduce risk, and help teams optimize solutions based on market and customer priorities rather than wish lists or opinions.
• Faster, more effective decisions: Through rapid learning and execution cycles, teams systematically validate technical and customer assumptions, enabling early, data-driven tradeoffs.

The MAHD Framework, grounded in agile principles, drives significant improvements in these areas—delivering tangible benefits like increased speed and higher customer value. When combined with appropriate risk management and design control procedures, the MAHD Framework provides proven processes for efficient and compliant development of software-intensive medical devices. 

 

Guest Authors

Dorian Simpson is a leading voice in agile hardware development and the creator of the Modified Agile for Hardware Development (MAHD) Framework. With decades of experience guiding product innovation across global tech and manufacturing companies, he helps teams break free from rigid processes to deliver smarter, faster, and more customer-focused solutions. A frequent speaker, trainer, and author, Dorian is passionate about reshaping how physical products are brought to life in today’s complex, rapidly changing world.

Vishal Sheth is a seasoned BusinessTransformation and Agile efficiency expert, with a proven track record in driving organizational peak performance. He ran PMO organizations at VISA and Thermo Fisher Scientific, enabling large, global teams to deliver a portfolio of industry-leading solutions driven by streamlined processes adapted to those organizations. Vishal’s expertise in Modified Agile for Hardware Development (MAHD), Agile, Lean, and data-driven strategies have helped organizations of all sizes successfully transform into high-performing market leaders. Vishal is passionate about aligning strategy and technology to maximize value and efficiency, and committed to fostering a culture of continuous improvement and innovation.

About the MAHD Framework

Since 2017, the Modified Agile for Hardware Development (MAHD Framework®) has helped hundreds of teams across diverse industries accelerate development, deliver greater customer value, and achieve stronger business outcomes. By tailoring agile principles to the realities of hardware, MAHD empowers cross-functional teams to learn rapidly, manage risk effectively, optimize trade-off decisions, and integrate seamlessly with existing processes like Stage-Gate or SAFe®.

To learn more about how the MAHD Framework can help your organization deliver smarter, faster, and more aligned innovation, visit: www.mahdframework.com.

Additional Information

Agile for Hardware the MAHD Way – recorded webinar by Dorian Simpson and Vishal Sheth describing key elements of the MAHD Framework (FEB 2025)

Adaptive Design Controls – a set of quality system procedures for managing development of complex, software-intensive medical devices; procedures that are adaptable to a variety of product development processes, including the MAHD Framework