Fixed price agile projects

Are fixed price contracts compatible with agile?

In an ideal world, Yes, they align perfectly.

Fix the cost, and burn down stories in priority order. Stop when the budget is spent.

Inspect the completed work and decide if you’ve got enough of an MVP. If not,

Allocate more budget and continue shipping features until you are happy.

You can even improve matters by first developing a high-level, ‘whole product’ backlog.

Then overlay a burndown chart to track progress, project an end date, and ensure the budget doesn’t run out unexpectedly.

Sounds simple, right? And it is simple, if you can agree to operate like this.

What ‘fixed price’ actually means

Unfortunately, the real world doesn’t initiate projects and allocate budgets like this.

Rather, governments and businesses prefer to solicit, and then award, fixed price software tenders.

Can you imagine a client agreeing to pay a fixed cost without knowing… a fixed scope for what they are paying for?

What is usually meant, or almost always implied, by ‘fixed price’ is actually ‘fixed price AND fixed scope’.

This leaves only one other variable left to flex, “quality”. Assuming the supplier doesn’t walk away or simply declare bankruptcy.

Mitigating fixed price work

If you really must operate as an agile team within any kind of a ‘fixed price’ arrangement, I strongly recommend:

1. Seeking (above all else) flexibility in the scope of work.
2. Developing a good product backlog, continuously prioritising tickets, and only working on those with the highest priority.
3. Constraining the initial backlog until a level of confidence exists that a ‘good enough’ MVP will very likely happen within the agreed budget.
4. Proactively seeking budget extensions, ahead of being required.

If you really can’t agree on a flexible scope, then Jeff Sutherland’s Change for Free is worth considering.

Avoid fixed price & fixed scope

In my experience, fixed price & fixed scope engagements almost never work. And certainly never works well for both parties.

And the few times I’ve gone down this route, I’ve (almost always) regretted it.

For the same pitfalls Gunther Verheyen clearly articulates here.

Seriously consider the implications of working under a fixed price, fixed scope arrangement.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.