Five Agile Misconceptions That Get Regulated Teams Into Trouble

A Scrum Master I worked with at a health system kept hearing the same sentence in every planning meeting. We can't do that here, compliance won't let us. After a while, the team stopped trying. They batched a whole quarter of work into one release, ran one giant review at the end, and treated every audit like a fire drill, because nobody could remember why a decision got made back in February.

Here is the part that took me a while to say out loud. The regulation never asked for any of that. It asked for evidence, for traceability, and for review by someone accountable. It said nothing about batch size, and nothing about how often the team was allowed to learn.

Most regulated teams carry a quiet belief that Agile and compliance are opposites, and that compliance always wins. I understand why it sticks. If the process is slow because the law requires it, then the slowness is nobody's fault. The trouble is that it is usually not true, and acting on it is expensive.

In almost every engagement I have worked, the law fixes the requirement, not the workflow. It fixes what must be true when you are done; it rarely dictates how you get there. Teams that confuse the two land in one of two ditches.

Both ditches, the team that drowns in self-imposed process and the team that skips the controls that matter, come from the same mistake: treating an assumption about the workflow as if it were the regulation itself.

Here is the thing nobody in the room wants to say. A good share of the rules people call "compliance" are not in any regulation. They are internal policies someone wrote years ago and never questioned again. So here are the five misconceptions I run into most, and what to do about each.

The five misconceptions, and what to do instead

1. "We can't do sprints because we need approval at every step"

Let me concede the real part first. Some changes do require review by an accountable person, and in many shops that is genuinely non-negotiable. That is not the misconception. The misconception is treating approval as a reason to stop iterating.

Approval is a step in your Definition of Done, not a replacement for iteration. A sprint does not mean you ship to production every two weeks. It means you produce a working, inspectable increment every two weeks. Approval can gate the release without gating the learning.

I had a payment client, PCI Level 1, whose developers were told they could not touch production or test their own code. That sounded like a hard regulatory wall. When we actually traced it, it was internal policy, written that way years ago, not the regulation. The real requirement was segregation of duties, and there is more than one way to satisfy that.

The evidence backs the lighter path. DORA's research found that heavyweight external approval, a change board or a senior manager signing off, made teams more likely to be low performers, with no sign it reduced change failures. Peer review captured in your development platform meets segregation of duties and leaves a cleaner trail than a meeting ever does. (For more on governance that protects versus governance that just slows you down, this earlier piece goes deeper.)

Source: DORA, Streamlining change approval: https://dora.dev/capabilities/streamlining-change-approval

2. "Our documentation requirements mean we can't work iteratively"

The real part: regulated work often demands serious documentation, design history files, validation records, audit trails. That is legitimate, and waving it off is how teams fall into the under-adaptation ditch.

But documentation can be iterative too. A requirement that an artifact exist and be accurate at release does not force you to write it all up front. Produce it increment by increment, alongside the work, so it stays current instead of getting reconstructed under pressure.

The practical adaptation is to make the required document an output of the Definition of Done for the work it covers, a little each sprint, verified as you go. A two hundred page document written the week before an audit is not evidence of control. It is evidence of a deadline.

3. "Our stakeholders require a fixed scope"

In regulated programs, stakeholders often do need certainty, and that pressure is real. Telling them to embrace ambiguity is not a strategy. So here is the distinction that actually helps.

Most of the time they require a fixed outcome, not a fixed scope. They need the system to be compliant, safe, and delivered by a date. How you get there can still flex. Those are very different commitments, and conflating them is what turns a program rigid.

Write the commitment as an outcome, like "the system is compliant and delivered by this date," and let scope be the variable you manage toward it. Fixing scope, date, and quality all at once, then calling it a plan, is one of the quieter ways regulated programs fail.

4. "Retrospectives create a discoverable paper trail"

This one trips up public-sector teams especially, and the underlying caution is fair. In some contexts, records are discoverable, and people are right to think about what gets written down.

Here is the reframe. A well-run retrospective is evidence of continuous improvement, which regulators generally want to see, not punish. The risk is not the retro itself. It is treating a raw transcript of everyone venting as the official record.

Separate the conversation from the record. Keep the candor in the room. Then document the decisions and the improvement actions you committed to, which is exactly what demonstrates a maturing process. You get the learning, and you get a paper trail that helps you instead of haunting you.

5. "Our release cadence is controlled externally"

Sometimes this is simply true. A regulator, a certification cycle, or a client change window may dictate when you can ship. I will not pretend you can release whenever you like.

But your internal learning cadence does not have to match your external release cadence. You can inspect, adapt, and validate a working increment every two weeks even if you only release once a quarter. The external schedule controls when users see the change, not how often you learn whether it works.

The adaptation is to decouple "done and validated" from "released." Build, integrate, and prove the increment continuously, then release on the schedule you are handed. (If you want the rituals that keep a learning cadence running independent of delivery, this operating model piece lays them out.)

Two traps that cut both ways

Watch for over-adaptation, where every new fear becomes a new gate until the process buckles under its own weight. The discipline that stops it is one question per gate: what specific risk does this prevent, and is there a lighter way to do it?

Watch for under-adaptation just as closely. A team hears "be more Agile" and trims the controls that genuinely matter, which is how you end up explaining a gap to an auditor. The fix is the same discipline pointed the other way: name the real requirement, and build it into how you finish work.

Do this Monday morning

Pick the one misconception on this list you recognized in your own team. Just one. At your next refinement or standup, take a single thing the team believes is blocked by compliance and ask one question: is this an actual regulatory requirement, or is it how we have always documented our own policy? Then trace that one example back to its source.

You will usually find one of two things. Either it is a real requirement, which you now build into your Definition of Done as acceptance criteria, or it is internal habit wearing a compliance costume, which you can change. Run the same trace on a second item next week. Two traced assumptions a month will reshape how your team sees its own constraints within a quarter.

If you are working through a "we can't do that here" conversation and want a second set of eyes before you lock in new structure, our coaching team works with leaders on exactly these calls. Often the most valuable hour is the one before the meeting that sets the process in stone.