Agile-Friendly Contracts: What Good Looks Like Versus What Bad Looks Like
Agile delivery methodologies and traditional fixed-scope, fixed-price contracts are structurally in tension. Agile delivery assumes that requirements will evolve as understanding increases -- that the best product is discovered through iteration and feedback, not defined in full at the start. Fixed-scope contracts assume that requirements can be completely and correctly defined before work starts, and that the contractor will be held to delivering exactly what was specified.
In 2022, many public-sector and capital-project organisations are trying to apply agile delivery methods while operating within traditional contract frameworks. The result is often a hybrid that gets the worst of both worlds: the rigidity of a fixed-scope contract with the unpredictability of agile scope discovery. Here is what agile-friendly contracting looks like versus what to avoid.
What Bad Agile Contracting Looks Like
Bad: A fixed-price contract for a fixed scope with the words 'agile methodology' added to the delivery approach section. The scope is still fixed; the price is still fixed; the contract does not accommodate evolving requirements. Calling the delivery method 'agile' does not make the contract agile-friendly.
Bad: A time-and-materials contract with no outcome commitments. Time-and-materials contracts are agile-friendly in structure but can become open-ended if not paired with outcome milestones or velocity expectations. A contractor who delivers low quality work slowly has no financial incentive to improve under a pure time-and-materials arrangement.
Bad: A contract that requires full specification of requirements before work starts. This negates the value of agile delivery. If the contract requires a complete, signed-off requirements document as a precondition to development, the requirements discovery process has already happened before agile delivery can begin.
What Good Agile Contracting Looks Like
Good: A capped time-and-materials contract with outcome milestones. The contract has a time-and-materials payment structure (allowing scope flexibility), a cap on total expenditure (protecting the client from cost overrun), and milestone-based outcome commitments (creating accountability for delivery). The combination gives both parties flexibility and protection.
Good: Minimum Viable Product (MVP) definition at contract start, with defined processes for scope evolution. The contract defines a minimum deliverable (the MVP) that the contractor commits to, plus a defined process for adding scope, adjusting priorities, and resolving disputes about what was intended.
Good: Sprint Review participation rights for the client. An agile-friendly contract gives the client the right to participate in Sprint Reviews, to inspect the working increment, and to provide feedback that is formally captured and incorporated into the backlog. This is the primary mechanism for catching delivery problems early.
Good: A defined 'done' definition in the contract. The contract specifies the criteria that must be met for a deliverable to be considered complete -- including test coverage, documentation requirements, and acceptance criteria. Without a clear definition of done, the end of the project becomes a negotiation about what was delivered.
XNM provides advisory services to public-sector organisations on agile procurement, contract design, and delivery governance. Reach out to XNM's program & project delivery advisory team to discuss agile-friendly contracting and procurement for your organisation.