A few weeks ago I had the privilege of standing in front of 300 employees at the Dallas County Tax Office. They'd set aside a day of enrichment for their people, and I got to talk about customer service. Now, think about that job for a second. Nobody chooses where they go to pay their taxes, and the employees don't have much authority either. They can't change the law, the state regulations, or the process. The whole thing can feel pretty powerless on both sides of the counter.
So my entire message that day came down to one sentence: just because there's nothing you can do doesn't mean there's nothing you can do.
If you work in healthcare, financial services, government, technology, or defense, you've heard a cousin of that line. "We can't do that here. Compliance won't allow it." I hear it constantly when I'm trying to help teams be more agile, as if "regulated" and "agile" were mutually exclusive. So today I want to take that apart, respectfully. The people saying it aren't wrong about their constraints. What they're wrong about is what the constraints actually constrain.
The Health System That "Couldn't Run Sprints"
I'll keep this anonymous, but a few years back I started an engagement with a health system company. Smart people, good intentions, genuinely a pleasure to work with. Their product owner told me flat out: we can't run sprints. Every release has to be signed off by audit, by compliance, by a whole chain of people. So they batched everything into a six-month cycle. One big review at the end, one giant approval, and every audit turned into a fire drill, because nobody could remember why a decision had been made that many months earlier.
So I did what I always do. I played the wise fool. I asked a lot of questions, dug in, and talked to the people who actually owned the policy.
And guess what I found? The actual regulation didn't require anything the product owner was describing. It required evidence. I'll give her that. It required traceability. It required that certain changes be reviewed by somebody accountable. But it said nothing about batch size. It said nothing about how often we were allowed to release, or, as I'd rather call it, how often we were allowed to learn.
I'd seen the exact same thing at a company I worked for directly. We were PCI Level 1 compliant, a payment system, and our developers couldn't touch production, couldn't touch test, couldn't release their own code. I remember thinking, that's a massive bottleneck, because I try to give developers everything they need. Turns out it was a documented policy. That's all it was. So we rolled up our sleeves, dug into the political science of unraveling it, and we got the policy changed. I'm not saying that work is easy. But it can be done.
The Law Fixes the What. You Own the How.
Here's the trap. The regulation fixed the what, and the team assumed it also fixed the how.
This is the tax office all over again. The clerk can't change the tax code. That part is fixed. But the clerk absolutely decides whether you walk out feeling helped or humiliated. Same building, same law, completely different outcome. Why wouldn't we apply that same thinking to our own work?
In regulated software, compliance fixes the requirement. You still own the workflow. I don't know why so many teams give that ownership away without anyone even forcing them to.
And auditors, bless them, don't really help here, because their job is to mitigate risk, not to weigh the cost of that mitigation against the actual risk exposure. Everything they find becomes a fire drill that has to be fixed. But have you ever stepped back and asked: is the business risk here even worth mitigating? Sometimes the honest answer is, "That's a risk we're willing to take." In the corporate world we assemble all these roles, everybody does their job well, and nobody's playing the wise fool who asks whether the whole arrangement still makes sense.
Why Heavyweight Approval Gates Slow Regulated Teams Down
The traditional move in a regulated shop is a change advisory board, or a senior manager who signs off on everything before it ships, someone who ironically usually knows the least about the change. It feels safe. It feels responsible. It checks the compliance boxes.
The data says otherwise.
According to DORA's research, organizations that relied on a heavyweight, external approval process were 2.6 times more likely to be low performers. And here's the part that should stop you cold: there was no evidence that the formal approval process actually lowered failure rates or reduced risk. The gate slowed everybody down, but it didn't buy any of the safety it promised.
What works instead is peer review during development, supported by automation, with reviews and approvals captured right inside the development platform. That satisfies segregation of duties. An auditor can see who proposed a change, who reviewed it, and when. You keep the control and you lose the bottleneck. That's more rigor than a single sign-off ever delivered, and it leaves a cleaner trail for the auditor.
That pattern held across every variation in the data: different tech stacks, team sizes, regulatory environments. Regulation didn't exempt anyone from the fundamentals. The win is the same one it's always been: small batch sizes and solid testing. In a high-stakes environment, those fundamentals matter more, not less. (The same body of research also found teams leaning hard on AI tooling saw mixed effects on delivery, which only reinforces the point: the basics still rule.)
Frequent, Transparent Increments Are a Compliance Dream
Now connect this back to Scrum. The Scrum Guide is built on empiricism: transparency, inspection, and adaptation. You make the work visible, you inspect it often, you adjust to reality. The increment is your evidence that the thing actually works.
Read that again with an auditor in mind. Frequent, transparent, inspectable increments are not a compliance risk. They are a compliance dream. You're producing documented proof of working product on a regular cadence, instead of one anxious pile of paperwork at the end that throws everybody into a tussle.
And for the teams adding AI into regulated work, because I know that's on your mind, the NIST AI Risk Management Framework gives you four functions: govern, map, measure, and manage. Those aren't one-time gates. They're continuous. You map the risk, you measure it, you manage it, and you keep doing it as the system changes. That's an iterative loop with built-in governance, and it fits an agile cadence far better than a single, linear approval at the finish line.
How "Slow" Got Mistaken for "Safe"
Put it all together and a pattern shows up. Every one of these sources is making the same case from a different angle: heavyweight, end-of-line approval gates are a weak design, and frequent, transparent, evidence-producing work outperforms them every time.
Regulation never asked you to be slow. Somewhere along the way, slow just got mistaken for safe.
I love what they say in the military: slow is smooth, smooth is fast. I'm all for that. But somehow our regulations have convinced us that grinding to a halt makes us safer, when it's actually costing us enormous money, both in people and in pure system waste.
Three Ways to Build Compliance Into the Work
So I asked myself: how do you do this now, not someday? I landed on three moves. They all start from one discipline: separate what the regulation truly fixes from what you only assumed it fixed. The difference between the two looks like this.
1. Treat compliance requirements as acceptance criteria, not process overhead
The thing isn't done until it meets the regulatory requirement. Take a real one: every patient data access must be logged for audit. The old habit is to make that a separate phase, a checklist somebody runs at a gate. Instead, write it onto the story as acceptance criteria. The story isn't done until access logging is implemented, verified, and maybe even produces a report. Now the real requirement travels with the work. It gets tested like everything else, every single time you change it. Your tester checks it, your reviewer sees it, your auditor can trace it to a specific moment.
2. Build audit readiness into your Definition of Done
Acceptance criteria and the Definition of Done are two different things. This is the difference between scrambling for an audit and being ready for one by default. Some requirements apply to every increment; some apply only to certain categories of work. You can structure your Definition of Done to hold both, without turning it into a 42-item monster (yes, I've counted one). Audit readiness is a property of how you finish the work, not a department that visits you later.
3. Run retrospectives that survive public-records rules
This one trips up government teams especially. The fear is that a retrospective creates a discoverable paper trail, so people clam up. But a genuinely well-run retrospective is evidence of continuous improvement, and regulators tend to value exactly that. So document the decisions and the improvement actions. Don't transcribe who said what to whom; show a maturing process. Separate the learning conversation from what becomes the official record. You keep the candor in the room, and you keep the proof of improvement on paper. What auditor wouldn't want to see that?
Notice what all three share. None of them lower the bar. None of them skip a requirement. They take the real constraint and design it into the flow of work instead of bolting it on at the end.
Your One-Trial Challenge This Week
Let's try this next week. One trial, not two. One.
Find a single backlog item your team currently believes is blocked by compliance. Just one. Something where you've heard "we can't do that," or "it has to go through this process." Bring it to your next refinement session. Put the product owner, a developer, and if you can find one, someone from your compliance or risk function in the same room.
Then ask one question: What does the regulation actually require here? Not what have we always done. What does it require?
Take that answer and rewrite it as one or two acceptance criteria on the item, in plain, testable language. "Access is logged." "Approval by an accountable reviewer is captured in the platform." Whatever the real requirement is, it's now captured.
Done looks like this: the compliance requirement lives on the story as acceptance criteria, and the story can move. You'll have turned a wall into a checkbox. Do that once and your team will start spotting walls they can convert everywhere. It's slow, but it's a lot less slow than a fire drill every quarter.
Regulated Teams Don't Have a Compliance Problem
I'll leave you where we started. When you work in a regulated industry, just because there's nothing you can do doesn't mean there's nothing you can do.
Regulated industries don't have a compliance problem. They have a workflow-design problem around compliance. And the answer isn't less agile. It's smarter agile.
If you lead a team that keeps saying "we can't," or you sit on the team that keeps hearing it, this is the conversation worth having. Big Agile runs training and coaching built for exactly this: helping regulated teams design compliance into the way they work instead of bolting it on at the end. Explore the classes and coaching at big-agile.com and let's see what your team can actually do.