“You can’t be agile in a validated system” is a costly myth

Tell a validation lead you want to ship in increments and you’ll get a long pause, because they’ve seen agile used as an excuse to skip the evidence. They’re right to guard the audit record. The myth is that guarding it means waiting until the end.

I’ve heard “you can’t be agile in a validated system” in some form on nearly every life sciences engagement, and the people saying it are almost never wrong about what they’re protecting. They’re protecting patients and the audit record, and the regulators who will one day ask them to prove both. Good practice (GxP) guidelines, computer system validation, and Title 21 of the Code of Federal Regulations (21 CFR) Part 11 are not bureaucratic friction. They are the reason a system that touches a clinical trial or a batch record can be trusted at all. None of that is up for negotiation, and any consultant who treats it as an obstacle to route around has misread the room and the stakes.

So the question worth asking is narrower than the slogan suggests. Validation is non-negotiable, agreed. But does it actually forbid iteration, or have we just assumed it does because the first agile team anyone saw in a regulated shop treated documentation as optional? Those are different problems. One is a property of the regulation. The other is a property of how a particular team behaved, and it gave iterative delivery a reputation it doesn’t deserve.

What validation actually asks of you

Strip computer system validation back to its intent and it’s a single demand: prove the system does what it’s supposed to do, and nothing it isn’t, and be able to show your work later. That’s it. The regulation cares about evidence and traceability. It does not specify, and has never specified, that the evidence must be produced in one enormous push at the end of a multi-year project.

Now hold that demand up against two delivery shapes. In the first, a year of changes lands together: requirements, configuration, interfaces, reports, all moving at once, and validation begins after the system has already become a tangle of interacting parts. In the second, the same system arrives as a sequence of small, scoped changes, each one validated as it goes. Ask which is easier to prove correct. Proving a contained change behaves is tractable. Proving that 50 entangled changes behave, and that none of them broke something two modules over, is the kind of work that turns an audit into an excavation.

This is the part that gets lost. Small batches are not a compliance risk to be tolerated for the sake of speed. They are the form validation handles best. A team fighting iteration in the name of GxP is, more often than not, making validation harder on itself and calling the difficulty proof that it can’t be done.

Validation isn’t threatened by small, frequent changes; it’s overwhelmed by big, rare ones. Iterative delivery gives a validated environment exactly what it wants: increments it can actually keep up with.

Build the evidence in, don’t reconstruct it

The move that makes this real is to treat validation evidence as something the work produces on its way past, not something you assemble once the work is done. Requirements linked to the tests that exercise them. Approvals captured as records at the moment they’re given, by the person giving them, with Part 11 electronic signatures handled as a designed-in behavior rather than a screenshot pasted in afterward. Change history that exists because the system recorded it, not because someone remembered to write it down.

When the trail accrues this way, an audit stops being an archaeology project. The question “show me the requirement, the test that covers it, who approved it, and when” becomes a query rather than a week of three people reconstructing a timeline from email. And here is the quiet advantage the waterfall version never gets: in a continuous flow, the evidence is current. There is no gap between what the system does today and what the last validation package said it did 18 months ago. That gap is where risk actually lives, and big-bang releases manufacture it by design.

I want to be careful here, because this is exactly the point where agile gets oversold. None of this happens because a team adopted sprints. It happens because the definition of done for a regulated increment includes its validation evidence, and the team holds that line the way it holds any other. Drop the evidence from done and you don’t have agile validation. You have the reckless version everyone was right to fear.

The platform has to carry the trail

This discipline doesn’t survive on good intentions. It survives because the tooling makes the compliant path the path of least resistance. Jira and Confluence configured for traceability, staged approvals, and electronic-record awareness turn governance from a manual tax on every release into a property of how the work moves. Configured well, the platform refuses to let an increment reach done without its evidence attached, which is a far more reliable control than asking tired people to remember at the end of a long week.

We worked through this with a Food and Drug Administration (FDA) regulated company moving 350 people onto one platform, where auditability lived inside the workflow rather than being rebuilt after the fact. That placement is the whole game. Evidence captured in the flow stays accurate; evidence reconstructed later is only ever as good as someone’s memory. You can read how that came together.

The validation people protecting the audit record have the right goal. The teams pulling ahead in pharma didn’t lower their standard to move faster. They moved the proof earlier, into how each increment is built, and found that a validated system asked for small steps all along.

If you want to see where validation is really stalling your releases, see where delivery is getting stuck.