Should You Use Agile For Fixed Delivery Projects?

I had a potential client reach out to me recently about using agile with a fixed delivery project. By fixed delivery, I mean that they had a fixed price, fixed scope and fixed schedule project. This development project was to build an application and the timeline was one year. They had a binder of high-level requirements that were signed off by the customer. What could possibly go wrong?

I discussed this with one of my colleagues and we disagreed on what approach we should recommend. My colleague said that this was not a fit for agile delivery, while I thought agile was the best of the alternatives they had. Let’s take a look at why using agile for fixed delivery projects may or may not be a good idea.

What Does Fixed Delivery Mean?

As mentioned above, fixed delivery for this project meant that it had a fixed scope, fixed timeline, and fixed cost.

For the longest time, traditional project management focused on the “triple constraint” which was made up of project scope, budget, and timelines. This was also called the iron triangle. According to the thinking of the time, the triple constraint for any project was a balancing act between the three. If you changed one, you would likely have to change at least one of the others.

Today we know this is all wrong and those that focused on On Time, On Scope and On Budget delivery (also called OTOBOS), were misguided. Check out my related article on this topic Project Success Measures: Going Beyond OTOBOS.

The triple constraint was wrong for two main reasons. First, the relationship between the three constraints did not always hold up. Reducing the timeline did not always result in a cost increase and vice versa.

The second reason it is all wrong is that it focuses on three constraints and ignores other important constraints. Like quality. If you have ever been on a fixed time and fixed scope project you have likely seen people cutting quality in order to hit the dates. They simply don’t have any other levers. Even those slow to change like the Project Management Institute begrudgingly admitted that the triple constraints ignore other important competing constraints:

Tailoring should address the competing constraints of scope, schedule, cost, resources, quality, and risk. The importance of each constraint is different for each project, and the project manager tailors the approach for managing these constraints based on the project environment, organizational culture, stakeholder needs, and other variables.

—Project Management Institute. (2017). A Guide to the project management body of knowledge (PMBOK® guide) (6th ed.)

Even more important though is the fact that these three constraints only focus on your plan for delivery. They ignore the delivery of value which is the main reason that people have projects. Who cares if you deliver on time and on budget if the solution you provide doesn’t add value or work correctly?

Does Agile Work with Fixed Delivery Projects?

Agile is all about flexibility in delivery, collaborating closely with customers, and delivering in short cycles with generous amounts of feedback and continuous improvement. Having flexibility in your delivery approach is critical in times like ours when customers don’t always know what they want and teams are not certain about exactly how to deliver it. Using those short delivery cycles, getting feedback, and improving the way you work is essential.

But the agile approach begins to break down when teams are dealing with a fixed scope and timeline. Using agile for a fixed delivery project is like trying to chase a dog with a train.

You can’t chase a dog with a train.

— Unknown

To be fair, traditional project management approaches also break down when you have a fixed delivery project.

First, how do you know with any amount of certainty that you can complete the fixed scope with the timeline and budget that was identified? Unless you have done that exact project before, you are guessing. Oh you might have guestimates for the time and cost to build out the scope, but those estimates may or may not be accurate. According to the cone of uncertainty, the early estimates may be off by as much as 4X what it will actually take to deliver. Even after requirements are complete your estimates are likely to be 1.5X off what it will take to deliver.

Second, a one-year development cycle is a very long time for a technology project. Like it or not, things change.

Even though you have a fixed set of requirements for the project and assurances that nothing will change, things will change. Yes, things will change. The understanding of what was written will change. And the underlying customer needs and priorities will change.

Finally, with traditional approaches using phases, you often won’t be able to determine whether or not you are delivering all the budgeted work in the time allocated. Usually, this will result in snowplowing or pushing work from one phase into a future phase. Or, project managers will attempt to take sequential work and run it in parallel. Like starting user testing before development is complete.

I suppose you could use Earned Value Management with traditional project management and be able to track your completion. That can help you manage the delivery but you will spend all your time tracking variance from your plan. And despite the name, you won’t actually be tracking the value you deliver to the customer. [See Enough Already, There is No Value in Earned Value Management for more on why Earned Value is pointless with agile ways of working].

My point is, delivering a fixed project is risky whether you use traditional or agile delivery approaches. That said, I think there may be some advantages to using agile approaches for fixed delivery projects.

Advantages of Using Agile for Fixed Delivery

There are a few advantages to using agile over traditional approaches, even when you have a fixed delivery project.

1. Adaptability to Changing Requirements – As noted above, over the course of a year things will change. Even if the requirements have been “signed off in blood”, something is going to change. Using agile approaches allows for flexibility in accommodating change. It enables the project team to respond to new insights and feedback, ensuring that the final product meets the client’s needs. It also allows the client to make tradeoff decisions on what is most valuable.

2. Early Delivery of Value – Agile emphasizes delivering working increments of the product at regular intervals rather than waiting until the end of the year to deliver with a big bang. This enables stakeholders to start using and benefiting from the product early on, even if all features aren’t completed yet.

3. Improved Predictability – Using sprints rather than phases allows the team to better forecast the future. At the end of every 2-week sprint, the team can use the average throughput and the remaining backlog to forecast how long it will take to deliver the entire project. This level of predictability is not possible when using phases and delivering sequentially.

4. Improved Transparency – The use of timeboxed sprints and a prioritized product backlog provides transparency to the effectiveness of the team. This makes progress tracking more effective and speeds the identification and resolution of issues and risks.

5. Continuous Improvement – Agile approaches foster continuous feedback on the product was well as time for team reflection and retrospectives. Feedback on the product leads to a higher quality, more effective solution. And the team reflection and retrospectives drive improvements in the team’s processes leading to more effective and enjoyable teamwork.

6. Risk Reduction – Agile’s incremental delivery approach allows for early identification and mitigation of project risks. By delivering smaller increments, issues can be addressed promptly before they escalate.

Disadvantages of Using Agile for Fixed Delivery

It’s not all puppies and rainbows though. There are some risks to using agile for fixed delivery projects.

1. Managing Scope – While it is great to be able to easily accommodate changes in requirements, this has to be carefully negotiated with the customer. Assuming that the fixed scope you agreed to exactly matches the delivery timeline and budget, an increase in scope will blow everything up. This can still work if the customer understands that the scope is fixed and any changes to scope are a substitution of one scope for another, and not an increase.

A good analogy for this is a bucket that represents the scope. If the bucket contains the exact amount of scope that you need to deliver, adding something to the buck means that you will have to remove something else of the same size. Jeff Sutherland calls this, change for free.

2. People Costs – The agile approach to people costs is to have a fully dedicated team that stays together throughout the life of the project. Because of the continuous improvement efforts mentioned above, this team should deliver in the most effective and predictable way.

However, if your people cost estimates were based on specialists rotating on and off the project for specific tasks, you will likely find that your people costs are estimated to be lower than they would be with a dedicated team. Give me the dedicated team!

3. Contracts and Client expectations – This may be the single biggest issue. Agile works best when there’s a strong relationship between the client and the development team and everyone is seeking win-win solutions.

However, in a typical fixed delivery project, contracts are often win-lose. If the delivery team can deliver faster than planned, they will make more profit. Even if they don’t deliver what the customer actually needs. So there is often a tension between the customer getting everything that actually need (regardless of the requirements) and the delivery team estimates.

Bottom Line – Using Agile with Fixed Delivery Projects

Using Agile in a fixed budget, fixed scope, and fixed timeline project can be a double-edged sword. While it offers benefits like adaptability and early value delivery, challenges like scope and budget management, and contract-related issues can be significant concerns.

If it were up to me, I would never agree to a fixed delivery project. But if I were asked to help deliver one, I would definitely use agile ways of working for all the reasons mentioned above. Plus, agile approaches are more human and humane.