As Agile continues to grow in the software development arena, more and more companies are asking whether fixed-price contracts are practical anymore.
The Agile process requires constant re-evaluation of development resources, backlog items, and the compatibility of features and business goals. In this constantly evolving flow, it seems impossible for anything to be “fixed.” However, in reality, many companies who work with software development agencies are still looking to work with fixed budget, scope, and time for their projects.
This article will outline what fixed-bid projects are, the challenges that come with them, and some solutions that can be implemented to prevent scope creep and ensure project success.
What are fixed-price contracts?
Fixed-price contracts, also known as fixed-bid contracts, refer to agreements to complete projects for a flat rate. The final cost is set at the beginning of the engagement, and it operates on the idea that the budget, scope, and time frame are fixed and guaranteed.
Time and materials contracts are found at the opposite end of the spectrum. These agreements are based on an hourly rate and allow for billing the client based on the costs associated with the project once it’s completed.
Fixed-bid projects are popular because they offer financial certainty and simplicity. Many companies prefer to outsource development projects based on fixed-price contracts because it’s an easy way for them to decide who to outsource the project to—whoever promises the lowest total cost upfront wins the bid.
But fixed-price contracts don’t fit smoothly into today’s agile software development practices.
What are some of the challenges that come with fixed-bid projects?
The reality of today’s Agile software development process is that budget, scope, and time are unpredictable at the beginning of a project. As a result, fixed-price projects can experience scope creep and misalignments as they progress.
For instance, when dev teams are working on a project, they might have to deal with problems that are impossible to foresee before beginning work, including feature changes, time frame shifts, and technical debt.
In fact, the Agile methodology states that it is time-boxed and flexible in scope, highlighting the fact that contingencies are unpredictable. Any project that claims to implement the Agile methodology will need some wiggle room in terms of either the budget, scope, and/or time frame.
The following chart illustrates the relationship between fixed budget, features, and deadline.
The above chart can also be seen as a triangle, with each side being the budget, scope, and time frame. If one of the three factors changes, the shape and size of the triangle changes. For instance, if the scope increases, either the budget would have to increase or the timeframe would have to increase.
Modified versions of fixed-bid contracts
Some modifications are needed to give enough flexibility for Agile principles to be applied in a project. Instead of opting for a fixed-bid project where all three factors—budget, scope, and timeframe—are fixed, it’s more practical to choose two of the three factors and set up a modified Agile contract built on the fixed-bid project principle.
Fixed-scope and fixed-deadline
If you must have a fixed feature set and a fixed deadline, you must also be willing to cover any amount of costs incurred by the dev team to complete the project. In this case, it would be more practical to sign a time and materials hourly-paid Agile contract. The time and materials approach is particularly suitable for projects that need more flexibility and long-term projects with dynamic requirements.
Fixed-scope and fixed-budget
Alternatively, a client could insist on a fixed feature set and a fixed budget. In such Agile contracts, the feature set and the budget are predefined and cannot be changed. Since features cannot be dropped, the dev team will most likely need more time at the beginning of the engagement to clarify all the proposed features. Additionally, since all features are locked down at the beginning of the contract, the dev team must fulfill all requirements, regardless of how long it takes. You could expect the estimated timeline to change as the project progresses.
Rather than sacrificing important components of a project, however, development agencies have found more collaborative ways to price their work.
How clients and software teams can collaborate to ensure the success of fixed-bid Agile contracts
Fixed-price and Agile can exist simultaneously. The key is to redefine how we express the scope. Following are two ways to do this.
MoSCoW methodology
According to the MoSCoW methodology, not all features are equal—they should be broken down into “must haves,” “should haves,” “could haves,” and “won’t haves.”
The “must haves” and “should haves” are the features that align with higher level business goals, while “could haves” are simply nice-to-haves that may not be as important to the overall success of a project.
To ensure that the dev team can deliver the most important feature sets in the MVP, the client and the dev team should spend one to two weeks before the project officially kicks off to determine which feature sets are the most important to their business goals.
If the dev team has additional resources after completing all the “must haves” and “should haves,” they can then move onto the “could haves.” However, if there is no budget or time left after all “must haves” and “should haves” have been delivered, the “definition of done” would have been achieved, and the Agile contract would come to an end.
Fixed size of backlog to limit scope
Defining the size of the backlog as a means to limit the project scope upfront is another way to make a fixed-price contract compatible with the Agile methodology. This frees you from having to figure out every deliverable at the start.
One of the biggest reasons why Agile software development projects experience scope creep is an ever-growing backlog of items to complete. To prevent the backlog from growing into a monster, the client and dev team should agree on a set size for the backlog. The size of the backlog can be defined by a set number of man-days (e.g. 30 man-days).
If the client would like to add new features or items into the backlog, the client would have to eliminate other items in exchange. This way, the size of the backlog would remain constant. This approach lets the Product Owner exchange more important features when needed.
Communicate early and often about priorities
While fixed-bid contracts are often considered incompatible with Agile practices, there are ways to ensure their feasibility.
You would do well to incorporate an early discovery workshop to make sure you and your dev team are aligned regarding your most important business goals and deliverables. Make sure to participate in every stage of the development process to continue to bring to light your priorities.
Project managers at VeryCreatives are skilled in navigating Agile development practices within the needs of your business. Talk to us about how we approach agreements that help our clients plan for scope, time, and budget.
After all, it’s not about the hours we put in but rather the value we deliver.
