Incremental Delivery in Defense Starts with Architecture

Incremental delivery in defense programs is exactly where Polyrhythm operates. The idea sounds simple. The architecture is not.

CSO Gen. Chance Saltzman’s April 24 Commander’s Note made the case in plain language. Breaking Defense reported his argument for “minimum viable capabilities” and quoted the point that an 80 percent solution in warfighters’ hands today can be more valuable than a 100 percent solution that arrives late. The incremental delivery reporting is a useful signal from senior leadership.

That works only if the architecture supports it. Incremental delivery is not just a cultural choice. It is a structural one. The first increment has to be useful without blocking the second. The second has to compose with the first. The third cannot require the program to rediscover every interface.

That is why “MVP” can be dangerous in defense when it is used as a slogan. A commercial product can sometimes ship a narrow feature and learn from the market. A defense capability may have hardware, mission data, training, cyber controls, test ranges, logistics, and operational doctrine wrapped around it. A quick first release that ignores those constraints can create one-way doors.

The right first release is not the smallest demo. It is the smallest coherent capability that leaves the architecture open for the next increment. That means disciplined interfaces, baseline control, versioned data models, and test evidence from the beginning. It also means knowing which parts of the design must be stable before speed is useful.

The hard part is not getting the first 80 percent out. The hard part is making sure the second, third, and fourth increments compose. If each increment rewrites the boundary, the program is not delivering incrementally. It is running a series of disconnected prototypes.

Defense programs also need evidence that moves with each release. What changed? Which interfaces changed? Which tests passed? Which risks remain? Which operators gave feedback? Which cyber controls were affected? Without that evidence, incremental delivery becomes a paperwork fight at each gate.

The acquisition plan should reflect that cadence. Funding, reviews, and contract deliverables need to support repeated releases, not one big reveal. If the business system rewards a single final delivery, engineers will be pushed toward batching even when leadership says it wants increments.

Test assets need to be scheduled the same way. An increment that cannot reach a lab, simulator, range, or user environment will not generate the evidence needed for the next release. Incremental delivery depends on incremental learning.

Architecture-first incremental delivery does not mean slowing down to design everything. It means designing the parts that make change safe: interfaces, data ownership, release gates, rollback paths, test environments, and decision records. Those are the structures that let teams move faster later.

The upfront work can look expensive on a quarterly chart. It pays back over decades. A weapon system, training environment, or mission platform will change many times. The programs that can absorb those changes without reopening the whole system will deliver faster when speed actually matters, and with less surprise.