The Good, the Bad, and the Ugly of Agile Fixed-Price Contracts

Suggestions to Deal with Fixed-Price Bids

25 March 2014

Ashish Sharma
Cognizant Technologies Solutions


The good -- Most Agile projects are fixed price per iteration, by nature. You have a fixed team (Sscrum team) to deliver some feature (sprint backlog) within a fixed time (sprint).

The bad -- Usually when people say "fixed price," they mean fixing all parameters, i.e., price, time, and scope. This can create huge confusion and conflicts later unless specified.

The ugly -- The contract is signed with fixed price, scope, and time, with Agile in mind. The team is asked to deliver what is committed to the customer as per the contract. The team overworks and delivers the product, but by compromising on quality. The whole idea of Agile goes for a toss!

Let's look at some of the most common types of contracts for Agile:
  • Variable-price, fixed-scope (T&M bid) -- This works well with Agile projects. Fixed scope is delivered by having one or multiple Scrum teams working through one or multiple sprints.
  • Fixed-price, variable-scope (FP bid) -- This works best, because we can now fix product quality. Customers, however, must now deal with variable scope. We must prioritize the product backlog by business value and agree to get valuable delivery within a certain cost.
  • Fixed-price, fixed-scope (FP bid) -- This is the most difficult to navigate, simply because if we fix both the price and the scope, then the only remaining variable is software quality. Scrum teams fix quality by having a robust Definition of Done. By fixing all three constraints, price, scope, and quality, we have a recipe for a death-march project.
The bottom line: Whether we like it or not, fixed-price bid projects with Agile are a reality. Each contract will have its own set of problems and will need a unique solution. In the end, how easy or hard it is to go for a fixed-price bid with Agile will mostly depend on how well the customer understands Agile principles.

I have a few suggestions that might help in dealing with fixed-price bids:
  • The contract specifically clarifies that "fixed-price" does not mean "fixed-price, fixed-scope."
  • Come up with plan that says, "We have $X to spend and we need two releases, by September end and December end. We'll collaborate to come up with the best set of features to go live with on these dates -- which also means that we might not complete the whole product backlog."
  • Commit only for couple of sprints, understand the team velocity and other unknown dynamics, and then modify the release plan accordingly.



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (2 ratings)

Comments

Nirmaljeet Malhotra, CSP,CSM,CSPO, 3/25/2014 1:04:09 PM
It is interesting how fixed price projects become such a issue when comparing Agile to traditional methods. Even in the traditional world (from what I have seen), requirements go through churns during the entire length of the project. So logically the project scope is not fixed. And as we get to the tail end of the project, all "not so important" requirements get thrown away.

So while keeping the time and cost fixed with the scope remaining fluid is done either ways, its just that matter of how it gets captured in the contracts.
Tim Baffa, CSM, 4/8/2014 4:24:05 PM
Under traditional waterfall project management, PMI actually cites a practice called "Progressive Elaboration", which highlights the fact that more is learned about a project as the project progresses. Even PMI recognizes the futility of trying to predict project scope at a high degree of accuracy prior to project initiation.

I concur highly with the second suggested bullet point. In an Agile world, it is critical to identify the "core" features apart from the secondary or "nice to have" features, so that the work by the teams can be prioritized accordingly, and expectations around release dates can be communicated with confidence.

You must Login or Signup to comment.