Agile Meets Reality: Fixed-Price Contracts, Deadlines and Architecture

Version note: This post is based on the Agile Manifesto and its 12 principles (2001), DSDM's (Dynamic Systems Development Method) MoSCoW prioritization guidance (Agile Business Consortium), Jeff Sutherland's "Money for Nothing, Change for Free" contract proposal and SAFe's (Scaled Agile Framework) definition of the architectural runway; contract clauses here are not legal advice.

Guess First

Bookstore's software team is going to build a B2B (business-to-business) ordering portal for a corporate customer. The customer's procurement department wants a fixed price, fixed scope and a delivery date in three months. The customer's product team says "let's work Agile, show us a demo every two weeks, and update the scope if needs change". Both demands are in the same contract.

Guess: does this contract make Agile work impossible? Or is there something that can change inside a fixed price? And at the end of three months, will the date that doesn't move eat into the scope, the quality or the team's health?

Turning the Project Triangle Upside Down

In traditional project management scope is fixed; time and cost are derived from that scope by estimation. If the estimate is off, one corner of the triangle gives: either the date slips, the budget grows, or, the sneakiest one, quality quietly drops. The Agile approach turns the triangle upside down: time and team, and therefore cost, are fixed; scope is the variable. DSDM was one of the first methods to put this idea at its center as fixed time and resources with flexible features.

The basis for this inversion is the manifesto's second and fourth values: scope written up front is nothing more than today's best guess about what is wanted. Fixing scope turns that guess into a commitment. Fixing time and keeping scope variable is the commitment "in this time, with this team, we will build what is most valuable". The second commitment is both more honest and keepable.

Of course a contract where scope is completely open may be unacceptable to the customer. In practice, what you look for is to discuss up front how much of the scope is fixed and how much is flexible.

Working Agile Inside a Fixed-Price Contract

Jeff Sutherland's proposal, known as "Money for Nothing, Change for Free", adds two clauses to a fixed-price contract. The first, "change for free": the customer can swap an item that hasn't been started for another item of the same size at no cost, as long as the total amount of work doesn't change. The second, "money for nothing": if the customer decides it has received enough value, it can end the contract early at the end of any sprint; in that case it pays an agreed portion of the remaining fee. Sutherland presented the idea at the Agile conference in 2008 and covered it as a chapter in his 2014 book "Scrum". The proposal also has a condition: if the customer doesn't actively take part in the process, that is, in Product Backlog prioritization and reviews, the contract reverts to a time and materials model.

Let's adapt this idea to the contract for Bookstore's B2B portal. The scope goes into the appendix as a Product Backlog whose sizes were estimated together with the team. After every sprint review the customer can swap items that haven't been started for new ones of equivalent size. When the request to paste orders from Excel comes up in a sprint review, instead of a change request and a price negotiation, the conversation is about dropping the "multiple delivery addresses" item of the same size. If in the sixth sprint the customer decides the portal meets its needs, it can close the project by paying the agreed portion of the fee for the remaining two sprints.

These clauses don't suit every customer, and the legal text needs to be written with a lawyer. The important idea is this: a fixed price doesn't have to mean a fixed scope. While price and duration stay fixed, what is inside the scope can change.

A Team with a Deadline: Keeping the Must Have List Truly Small

Some dates are not negotiable. Bookstore's biggest campaign period is the end of November; the new discount code infrastructure has to be in production by that date, a week later is useless. Against a fixed date, Agile's answer is again scope: find the smallest slice that absolutely has to be there on the date and finish it first.

The MoSCoW method from DSDM gives the language for this slicing: Must have, Should have, Could have and Won't have this time. The method's most often skipped rule is the size of the Must haves. The Agile Business Consortium's DSDM guidance recommends that Must have effort typically not exceed 60 percent of the total effort, so that it stays at a level the team is confident of delivering. The rest, the Shoulds and Coulds, is in effect contingency: if things go wrong, they drop first.

In Bookstore's campaign plan the Must have list consists of: applying a single discount code at checkout, checking the code's usage limit, and reflecting the discount correctly on the invoice. Should have: a countdown on the campaign page. Could have: combining more than one code in the same order. Won't have this time: generating personalized codes. In the first two sprints all Must haves go to production behind a feature flag; the remaining time goes to the Shoulds and Coulds. When a payment provider issue creates two days of extra work in the third week of November, what drops is combined codes, not the campaign. A comparison of prioritization methods is in the Introduction to Product Management series post on prioritization frameworks.

Architectural Decisions: The Architecture Runway and When to Decide

The question Agile teams struggle with most is this: when should architectural decisions be made? At one end there is BDUF (Big Design Up Front), designing everything up front; at the other, a team that leaves every decision to the last moment and paints itself into a corner. The idea of the last responsible moment, popularized by Mary and Tom Poppendieck's book "Lean Software Development" (2003), suggests postponing a decision until just before the cost of not deciding exceeds the cost of deciding. For this idea to work in practice, you need to separate two kinds of decisions.

Decisions that are cheap to reverse can be postponed: an endpoint's response format, a cache duration, a class name. Decisions that are expensive to reverse have to be thought about early. For Bookstore's B2B portal they are clear: the database engine and schema strategy, the authentication and authorization approach (through the customer's own identity provider, or Bookstore's account system?) and the multi-tenancy model (each corporate customer in a separate database, or the same tables with a TenantId column?). Changing any of these three in the third sprint means rewriting most of the portal.

SAFe describes this balance with the concept of an architectural runway: the existing code, components and technical infrastructure needed to implement near-term features with minimal redesign and delay. The airplane analogy is clear: if the runway is too short, features can't take off; if it is longer than needed, the effort invested is never used. For this, the Bookstore team sets aside part of every sprint's capacity for the infrastructure upcoming features will need, and keeps this work visible in the backlog with a separate item type.

Expensive decisions made early should be documented briefly and readably. An ADR (Architecture Decision Record) captures a decision's context, options and consequences in a page or two; the answer to "why did we choose a single database for multi-tenancy?" stays even when the team changes. The details of writing ADRs are in the Architecture Decisions series post "Writing ADRs", and trade-off analysis in the same series' post "Trade-off Analysis".

When Is Agile Really Hard?

To be honest, there are situations that limit Agile's benefit. If requirements are legally frozen, for example if every field is described one by one in a public tender specification and a change requires reopening the tender, there may be no legal way to keep scope flexible. In an environment where feedback can't be obtained, for example a system end users can't access at all before delivery, the real payoff of short loops, real user reaction, never arrives.

Even in these situations part of Agile still works: short iterations, continuous integration, automated tests and team reflection let you see risk early even when scope is fixed. Which model to choose when was covered with decision factors in the last post of the SDLC (Software Development Life Cycle) series.

Production Notes

Before the contract is signed, put in writing what is fixed and what is flexible: which date is fixed, which budget is fixed, which part of the scope is Must have, how change will be handled. If this conversation happens after the contract, every change turns into a negotiation.

Re-measure the size of the Must have list every sprint. Every item quietly added to the list eats into the contingency, and the team is pushed into overtime toward the deadline; the manifesto's eighth principle, sustainable pace, is broken most often this way.

List the architectural decisions in the first two sprints and answer the question "how expensive is it to reverse?" for each. Make the expensive ones early and documented; consciously postpone the cheap ones.

Common Pitfalls

Accepting a fixed date, fixed scope and fixed team at the same time is the most common pitfall. If all three are fixed, the only thing that gives is quality: tests are skipped, technical debt accumulates, and the maintenance phase after delivery gets expensive.

The second is making everything a Must have. A plan where Must haves are 90 percent of total effort looks like it uses MoSCoW but is really a fixed-scope plan.

The third is postponing decisions that are expensive to reverse by saying "in Agile, architecture emerges on its own". Emergent design works for cheap decisions; the multi-tenancy model doesn't emerge, it is either chosen consciously or by accident.

The fourth is putting Agile clauses into the contract without involving the customer in the process. Change for free doesn't work unless the customer comes to reviews and sets priorities.

A Small Experiment

★☆☆ In the work your team is doing, which of time, cost and scope is really fixed, and which is flexible? If all three are fixed, what is giving today?

★★☆ Label the backlog of your next release with MoSCoW and calculate what percentage of total effort the Must haves are. If it is above 60 percent, which items would you move down to Should?

★★★ List the three decisions in your project that are most expensive to reverse. Write a short ADR for each: context, options, decision and consequences. If one of these decisions hasn't been made yet, when is the last responsible moment?

We have seen the friction between Agile and the real world. In the last post of the series we look at how Agile has evolved from 2001 to today: Heart of Agile, Modern Agile, the Agile Fluency Model and the debate about scaling Agile in large organizations.