Why Agile Breaks in Accreditation-Constrained Programs

Agile works where teams can deploy when the software is ready. Many organizations are not those environments.

This isn't a criticism of agile. It's an observation about the conditions agile was designed for — and what happens when they don't exist. The sprint model assumes the team controls release. The retrospective assumes the team can change what isn't working. The definition of done assumes that "done" is literal and not dependent on outside approval.

In compliance-constrained organizations, legacy structured enterprises, and siloed teams that are overwhelmed, none of these assumptions hold.

Where the model breaks

The sprint closes. The software is ready. The engineering team has done the work, run the tests, and met the acceptance criteria. The sprint is done by every measure the team controls.

Then the change goes to the change control board. The board meets next week. The approved change then goes to security review, which takes a week or two if there are no findings, longer if there are. The current release authorization covers the system as it was certified — and the new capability isn't in that certified baseline. The authorization must be updated before the capability can reach production.

The sprint that was "done" in week two is in production in week nine. At best.

The velocity metric the team has been tracking doesn't measure the rate at which value reaches users. It measures the rate at which work clears the team's internal gates — a different number entirely when the gates the team doesn't control are the binding constraint.

This is the first place agile breaks: the definition of done doesn't account for the approval chain.

The second break: the retrospective

Agile retrospectives are designed to surface process problems and fix them. The team identifies what slowed the sprint, and the next sprint is adjusted accordingly.

In most organizations, the constraints that slow a sprint down are seldom within the team's control. Board meeting cadences, security reviews, periods of no work; all external to the team. A change control board meets when it meets. Security review timelines are directly correlated to workloads and the risk profile of the change. The authorization process follows the framework established by the compliance authority.

Retrospectives that reveal these constraints and cannot resolve them result in frustrated, and, worse yet, confused, teams. After enough of them, the team stops surfacing the real problems, and the retrospective becomes a ritual without a function.

The third break: the backlog

Agile backlogs prioritize tasks by value — highest-value items first, sequenced by the product owner's judgment about what matters most to the user. In a compliance-constrained organization, the backlog has a second ordering principle: what can be approved.

A high-value capability that will touch a certified component, cross a controlled data boundary, or introduce a new configuration will obviously face a longer lead time getting approved. Whereas a lower-value capability that sits squarely within the already-approved scope will reach implementation sooner. A backlog ordered by value alone will produce a sequence that faces significant friction against an approval chain.

The adaptation that works

None of this means agile doesn't work in a constrained environment; every environment faces some constraints. It means agile has to be adapted to account for the gates the team doesn't control. Even to the point of looking at different versions of Agile.

The adaptation starts with practically defining done within the constraints of the operating environment. Done means in the authorization pipeline, not cleared for production. The team tracks two things: the rate at which work clears internal gates, and the rate at which it clears external gates. Both are important, and the gap between them is the organization's cycle time. This is an important point that needs management buy-in.

The second adaptation is sequencing the backlog against the approval timeline. High-value items that will take twelve weeks to reach production have to be started earlier, not prioritized later. Lower-value work that can clear the gates sooner can be pulled forward. The backlog isn't only a value queue — it's a production scheduling tool, and part of that schedule is set by gates the team doesn't control.

The third adaptation shifts compliance activities from being parallel to being completed within the sprint. This makes legal, security, and regulatory checks part of the daily development cycle, rather than delaying them. If these activities are left parallel (devs code - security reviews a week later), the result is late delivery, leading to greater distances between done and deployed.

The organizations that deliver consistently well in challenging environments are the ones that can adapt methodologies to the constraints, rather than expecting the constraints to adapt to methodologies.

Agile is not for every environment. If you've been on a team that has 45-minute daily staff meetings and calls them a scrum, you’ve seen the problem. I’ve seen traditional engineering teams pushed into agile methodologies without any education or training. The result is frustration, confusion and loss productivity.

Cybaris Consulting advises organizations on delivery architecture in a variety of environments — sequencing work against the gates that determine when value reaches users. If you're navigating those constraints, start a conversation at cybarisconsulting.com.