Intelagile
Agile Fails in Government Because the Contract Does
Sprints and standups cannot survive a fixed-price, fixed-requirements contract. The constraint is the modification clause, not the culture.
The Agile Manifesto (opens in a new tab) is four values and twelve principles, written in 2001 by seventeen people who had been shipping software and were tired of watching plans win arguments against working code.
Read the four values closely and notice what is missing. There is nothing about a contract. The closest line is "customer collaboration over contract negotiation," which is an aspiration, not a mechanism.
That omission is why agile adoption in federal programs produces standups, sticky notes and a delivery date that never moves.
The values assume a customer who can change their mind
"Responding to change over following a plan" only works if change is cheap. In a commercial product team, the product owner reprioritizes on Tuesday and the team starts the new thing on Wednesday. The cost of the change is a conversation.
In a federal contract, the requirements are in a document that both parties signed. Changing them is a modification. A modification takes contracting officer time, may require legal review, may need new funding, and may be protested. The team cannot absorb a priority change on Wednesday because the change is not the team's to make.
So the team does what the contract permits. It works the requirements in order. It holds a daily standup, burns down a sprint, demonstrates an increment, and then the increment sits while the acceptance process runs. Every ceremony is real. None of them can change what gets built next.
You cannot iterate against a baseline you are contractually obligated to deliver.
What the ceremonies become
Once the contract fixes scope, the agile apparatus starts serving a different purpose than the one it was designed for.
The sprint becomes a reporting period. The demo becomes a status meeting for the customer's leadership. The backlog becomes a deliverable list with better formatting. The retrospective becomes a place to discuss process friction that nobody has the authority to remove, because the friction is the modification clause.
This is not hypocrisy by the team. It is the rational response to the incentives. The team is measured on delivering the baseline on schedule, and the ceremonies are a way to show progress toward it.
The symptom to watch for is a backlog that never changes priority. If the top item in January is still the top item in June, the backlog is not a priority list. It is a schedule.
What actually permits iteration
Agile in a federal program works when the contract is built for it. Four structures do most of the work.
A vehicle that expects change. An IDIQ with task orders, or a blanket purchase agreement with a defined ordering process, lets the customer issue a new order without renegotiating the whole thing. The iteration happens at the order level, not inside a fixed scope.
A backlog that is the ordering mechanism. The contract has to make the prioritized backlog the thing the contractor works from, with the customer able to reorder it inside an agreed envelope of effort. That is a clause, not a culture change.
Acceptance by demonstration, in increments. If acceptance happens once, at the end, you have a waterfall with a scrum board. If each increment is accepted and paid for, the customer can stop funding work that is not delivering, which is the real risk control.
A contracting officer who is in the room. Not copied on a monthly report. In the demo, hearing the priorities, able to say what a change would cost. Programs where the COR and the KO are part of the cadence move faster than programs with a better framework.
None of this requires an agile coach. All of it requires somebody to rewrite the parts of the contract that assume a fixed scope.
The test I would apply
One question tells you whether a program is doing agile or describing it.
Can the customer change the priority of the next two weeks of work without issuing a modification?
If yes, the team can iterate and the ceremonies mean something. If no, the team is executing a plan, and the framework is decoration on top of it. That is not a moral failure. It is an accurate description of the constraints, and it is better to say it out loud than to spend three years pretending the retro will fix it.
The manifesto's authors knew the values were a preference, not a process. The line that matters for federal work is buried in the principles rather than the values: deliver working software frequently, and prefer the shorter timescale. A contract that cannot accept a delivery every two weeks has already decided against that, whatever the team writes on the board.