How to Create an Agile Organizational Structure

Randy Horton

Published on: March 3rd, 2026

Executive Summary

Most MedTech organizations developing Software as a Medical Device (SaMD) don’t struggle to implement Agile. They struggle to make it work.

In our recent webinar on Agile organizational structure, the panel focused on what actually gets in the way of successful Agile implementations. The issue isn’t Agile itself. It’s how the organization is set up around it.

Many teams adopt Agile in engineering, while product, quality, and regulatory continue to work in more linear, siloed ways. That’s where things start to break down. Work moves forward, but alignment doesn’t. Delays and rework follow.Software doesn’t stop changing after release. It evolves as products are used in the field. But many MedTech and SaMD organizations are still structured for slower, phase-based development. As systems grow and more teams get involved, that gap becomes harder to manage. Teams fall out of sync, and coordination gets more difficult.

Teams push decisions up the chain when they don’t need to. And when quality or regulatory input comes in, it’s often after key decisions are already locked in.

Agile isn’t just about moving faster. It’s about making better decisions and learning earlier. To achieve this, organizations must align their structures so that decisions happen at the right level, involving quality and regulatory teams early enough to prevent delays and rework, yet without slowing progress.

Agile Isn’t the Constraint. Organizational Alignment Is

Agile has been used in medical device software for years. However, it hasn’t necessarily been used in many instances to yield the intended benefits successfully.

One of the major challenges arises from combining iterative SaMD development with regulated MedTech systems that still expect work to move through phase-based, functionally segmented processes.

Software also behaves differently from hardware. It continues to change after release as platforms evolve, integrations shift, and new requirements emerge. That ongoing change puts additional pressure on organizations that are still structured for phase-based delivery.

When software teams work iteratively, but the rest of the organization doesn’t, problems show up quickly. Teams interpret requirements differently. Input from quality, regulatory, and human factors professionals comes in after the software is already built. By then, fixing those issues is much more expensive.

That’s why many teams adopt Agile practices without actually improving outcomes or decision-making.

When Agile Becomes Process Without Impact

Teams often implement the mechanics, sprints, standups, and tracking tools in Agile, without seeing meaningful changes in outcomes.

As a result, teams can become highly efficient without becoming more effective. They deliver work quickly, but not always the right work. Without strong feedback loops to keep teams’ work and output aligned with business success, they risk becoming very good at building features that don’t solve real problems.

“it was very effective and efficient at producing the wrong features.”
– Larkin Lowrey

Agile can also shift, in unproductive ways, from a value-creation tool to a management tool. In some instances, it becomes a way to track activity and increase visibility, but it loses focus on actually improving how products are built or the value of those products to the business, customers, and patients. In these situations, teams often focus on demonstrating progress to the detriment of repeatedly confirming that the work is actually valuable.

Customer Proximity Shapes Better Decisions

Teams building SaMD make different decisions when they stay close to the people using their products.

The panelists pointed out that proximity to users and the usage of systems change how problems are understood. When teams stay close, they can see how products are actually used, where friction shows up, and what matters most. That context carries over and improves the decisions they make going forward.

When that connection is weak, the work starts to drift. Product management leaders, rather than actual users, become the primary filter for user input, and important details can get lost in the shuffle. Even the insights of extremely strong product teams are not a replacement for direct exposure to real-world use.

The bottom line is that feedback loops aren’t just a process. They connect how the product is used to how decisions get made.

In MedTech, gaining direct access to clinicians and patients can be challenging. However, establishing structured feedback loops through virtual user testing, remote interviews, or simulated environments can help teams stay close to users and avoid working off incomplete assumptions, ultimately improving decision quality.

Too Late Feedback Drives Rework

Most rework in MedTech and SaMD development can be traced to feedback arriving too late.

Teams often interpret the same requirement in different ways. But that misalignment often does not become apparent until later in the project, during verification or validation. By then, the software is already built. What could have been a small/early adjustment becomes a later/larger correction, often requiring the time and attention of multiple teams.

That is the problem “shift left” is meant to address. In a previous webinar, the discussion focused on what happens when key stakeholders are brought in too late (or too early). Teams make decisions based on assumptions, move forward, and only later find out that those assumptions don’t hold. At that point, they are no longer refining the product. They are trying to fix decisions that have already been implemented.

The earlier those assumptions are tested, whether they relate to regulatory constraints, user needs, or technical feasibility, the easier it is to adjust direction. Early input at this stage is usually simple. It might be a constraint, a risk, or a concern that changes how confident teams are in their direction.

Without that input, teams commit to decisions too early. Once those decisions are built into the product, changing them requires rework across design, development, and verification.

The Role of Quality and Regulatory in Development

When quality and regulatory input come too late, teams end up reworking decisions. When it comes too early or too often, it can slow progress. Getting that balance right is what keeps work moving without unnecessary delays.

Many organizations try to solve this by involving quality and regulatory earlier. That helps, but only to a point. Bringing them in too early or too often can slow decision-making, create confusion about ownership, and make it harder for teams to move forward.

What matters is when their input affects a decision. Teams don’t need continuous involvement from every function. They need quality and regulatory input at the points where it can change how the work is approached.

Quality and regulatory teams have the greatest impact when they influence decision-making, not when they review completed work.

The panelists pointed out that these functions are often brought in after implementation. At that point, the product has already been designed and built. Their feedback then leads to rework, rather than helping teams make better decisions.

When involved at the right moments, quality and regulatory help teams define product boundaries, identify risks, and clarify how the system should behave in real-world use. That input shapes how features are designed before they are fully implemented.

“…by productivity, it’s like delivering the right thing, not just delivering something.”
— Megan Graham

This matters most when teams are defining workflows and system architecture. Decisions made at that stage determine how the product behaves and how risks are handled as it evolves.

The goal isn’t to have quality and regulatory involvement at all times. It’s to bring them in when their input actually changes the outcome.
In practice, that tends to happen at three points:

Early: define constraints and system boundaries before development begins
During development: guide risk decisions as features are implemented
Later: confirm alignment across requirements, risk, and verification

Quality isn’t owned by one team. Different groups contribute to it at different points as the product comes together.

Siloed Teams Undermine Agile

Agile does not fail because of the methodology. It breaks down when teams operate in isolation.

A common theme the panelists see is that Agile is adopted in engineering within MedTech organizations, but the rest of the R&D organization (and the entire MedTech enterprise, for that matter) continues to operate as separate functions. Each group may be working effectively on its own, but the gaps between them slow everything down. Work has to move between teams rather than be handled within a single team.

As organizations grow, this becomes more noticeable. Teams operate on different timelines, follow different priorities, and are measured in different ways. Decisions take longer because teams have to coordinate across functions instead of resolving issues within the same team.

The shift is not just about adopting Agile practices. It is about how teams are designed. When product, engineering, and quality operate as a coordinated unit, teams can work through tradeoffs earlier and move forward with more consistency. Without that structure, teams spend more time managing handoffs and dependencies than actually progressing the work.

Ultimately, Decision-Making Determines Whether Agile Works

How decisions are made ultimately determines whether Agile succeeds in benefiting an organization and its devices.

Agile is meant to improve how decisions are made, not just how work is organized. It moves decision-making closer to where the work happens, so teams can act on the information they have in real time. When this isn’t set up well, the opposite happens. Decisions default upward, teams wait for approvals, and progress slows. Even when teams are capable of making the call, they defer, which limits responsiveness and creates unnecessary delays.

More effective organizations push decision-making closer to the work, within clear boundaries. Teams understand their objectives, constraints, and level of authority. This doesn’t work in command-and-control structures where every decision requires approval. In those environments, teams hesitate and lose momentum.

At the same time, teams need support to operate this way. Organizations need to build confidence and allow room for learning. When that foundation is in place, decisions happen faster, and teams can adjust as they learn.

When Agile Efforts Stall

Many organizations have already tried Agile and did not see the results they expected.

In those situations, the answer generally isn’t to restart with a new framework such as SaFE. Instead, it’s about diving in and identifying what’s not working.

“Whether you call it Agile or not, it’s less about that than about the overall process.”
– Bernhard Kappe

What’s important for the organization is to figure out where things are breaking down. Work gets redone during verification or right before release. Decisions happen without the right people involved. Timelines slip because teams aren’t aligned.

Instead of asking how to “do Agile better,” the panelists kept coming back to a simpler set of questions that organizations struggling with Agile need to ask of themselves:

When and where does rework show up late in the process?
Where are decisions happening without the right input?
What problem are we actually trying to solve in our process or decision-making?

Once these questions are answered, changes to Agile processes tend to become more focused. Leadership finds that small adjustments to timing, feedback, or ownership often go further than overhauling an entire Agile implementation.

A Practical Way to Assess if Agile Is Working

One of the simplest ways to assess this is by listening to how teams talk about their work. The strongest signals can show up more in day-to-day conversations than they will in metrics such as velocity.

When things are off track, team conversations center on status updates, sprint rituals, or progress tracking. It’s also a red flag when other functions, such as Quality and Regulatory, aren’t part of the conversation.

When agile is working, the tone is very different. Teams talk about how the product is used, where it’s falling short, and what needs to change. Hard decisions about trade-offs surface and are made much earlier and more frequently in the project.

When it’s going well, “Done” doesn’t just mean the feature works. It means it’s ready for use in a real-world context. Similarly, bugs are defects, but defects are also seen as requirements and issues that should/could have been caught earlier.

The Takeaways

Agile in MedTech and SaMD is not defined by the practices teams adopt. It is defined by how the organization supports software development and enables value creation.

Teams get value from Agile when they are structured to learn quickly, make decisions at the right level, and involve the right perspectives at the right time.

When that structure is in place, teams spend less time revisiting decisions and more time improving the product.

Finally, software doesn’t stop changing after release. Organizations need a way to keep up with those changes while still managing quality and risk.

Watch Webinar Recording

Randy Horton, VP of Solutions and Partnerships, Orthogonal