As an Agile Coach, I hear the question often: “Can Scrum work with fixed-price projects?” The short answer is yes, but it’s not a fairy-tale romance. It’s not an unknown fact that fixed-price contracts disincentivize change, hindering agility. Clients hesitate to ask for changes due to potential cost increases, while developers fear scope creep and budget overruns.

Here’s the rub: fixed-price projects love predictability, while agile thrives on flexibility. It may seem like the Twains can never meet, yet practitioners do have some tricks under their sleeves to make this unlikely pairing work:

Acknowledge the elephant in the room

A fixed price Agile project construct goes against the core Agile value of “customer collaboration over contract negotiation.” We must educate the customers about this if they are keen to run the project in Agile mode. Fixed prices thrive on the incorrect notion that time, budget, and scope can be fixed and planned upfront (remember the iron triangle of software development?). However, fixing time, budget, and scope can only guarantee one certainty, viz., the low quality of deliverables. Strive to promote contracts that are agile-friendly, welcome uncertainty, and put teamwork first.

Affixing size is better than fixing scope

Adjust the size (say, in story points) rather than the scope (features). As long as the total effort (story points) stays the same, this gives customers the freedom to change features in response to market feedback. Think of it as a flexible dress form, not a rigid mold.

Jeff Sutherland explained this strategy in a paper that offers alternatives to traditional agile contracts, promoting flexibility, value delivery, and collaboration. It proposes two key principles:

  1. “Money for Nothing”: The initial contract price covers delivering a minimum viable product (MVP) with high-quality core features.
  2. “Changes are Free”: Clients can freely add or remove features within the sprint cycle, as long as the overall scope remains constant.

Prioritize, then prioritize some more

Work diligently with the product owner to prioritize the features using the MoSCoW method (must-haves, should-haves, could-haves, and won’t-haves). In fixed-priced Agile projects, ideally, the “must-haves” should be limited to 60% of the project. This ensures that the core functionality is delivered first and fast, while the “nice-to-haves” can be potentially swapped. We have covered other prioritization techniques in this article.

An empowered team to deliver value

Ensure that your team fully understands the importance of delivering value within sprints and demonstrating progress to clients regularly. Honesty and open communication can save the day. By involving the development team in estimations, prioritizing features collaboratively, and presenting progress regularly, you can build trust, ensuring smooth sailing even in choppy waters.

Transparency is vital

Fixed-price projects demand transparency. It’s vital to regularly share your progress, challenges, and potential risks openly with your client. This not only builds trust but also assists the customer in making informed decisions, for example, by adjusting the scope or extending the timeline.

Software development is inherently complex and unpredictable, making fixed scopes and deadlines unrealistic and leading to low quality. Fixed-price Agile is difficult and probably not even recommendable, but it’s achievable. You can make this odd duo a success by encouraging open communication, accepting flexibility, and setting sensible priorities.