The single most underrated barrier to enterprise Agile transformation is the contract. Fixed-scope, fixed-price contracts between clients and delivery partners create a structural incentive for Waterfall — because Waterfall is the only methodology that pretends you can fix scope and price upfront. Here is how to structure contracts that support Agile delivery.
The Three Commercial Models
| Model | How it works | Agile compatible? | Risk profile |
|---|---|---|---|
| Fixed Price / Fixed Scope | Agree everything upfront; client pays fixed sum | No — change is contractually penalised | Client absorbs scope risk; supplier absorbs delivery risk |
| Time & Materials (T&M) | Client pays for time used; scope flexible | Yes — supports iterative delivery | Client absorbs cost risk; supplier has low risk |
| Outcome-Based | Payment tied to delivered outcomes (metrics, milestones) | Best alignment — pay for value not time | Shared risk; requires agreed outcome definitions |
Why Fixed-Price Contracts Break Agile
When a supplier is contracted for a fixed scope at a fixed price, every change request costs the client extra money. This creates four predictable dysfunctions: scope freeze (teams build what was in the contract, not what users need), change request theatre (stakeholders suppress feedback to avoid contract amendments), blame culture (any delivery failure triggers contractual disputes), and gold-plating risk (suppliers pad estimates to protect margin).
T&M Contracts: Guardrails to Add
Pure T&M gives clients no commercial protection against runaway costs. Add these guardrails: a maximum spend cap per quarter (with extension options), a minimum velocity commitment (agreed throughput floor, e.g. "minimum 15 user stories per sprint"), a quality gate (defect rates, test coverage floors), and quarterly contract reviews with exit clauses. This gives the supplier flexibility while protecting the client from cost overruns.
Outcome-Based Contracting
Outcome-based contracts are the most aligned with Agile values — but require both parties to agree on measurable outcomes before delivery begins. Examples of outcome definitions: "Payment conversion rate improves from 72% to 82% within 6 months of feature delivery" or "Support ticket volume reduces by 30% within 3 months of self-serve feature launch." Payment milestones are triggered by outcome achievement, not deliverable completion.
Statement of Work for Agile Projects
When a Statement of Work (SoW) is required, structure it to describe: the delivery methodology (Scrum, with sprint cadence and ceremonies), team composition and roles, Definition of Done, backlog governance (who owns the backlog, who prioritises), and quality standards — rather than a list of features to be built. The SoW should define how delivery works, not what will be built.
What Scrum Masters Need to Know About Contracts
Most Scrum Masters are not involved in contract negotiation — but they are severely impacted by bad contracts. When a supplier SM is blocked from raising impediments because doing so triggers a change request process, the retrospective is useless. SMs should understand the commercial model they are operating within and escalate structurally misaligned contract terms as programme-level impediments.