Can you be Agile with fixed-bid Projects?

I always get one question from the candidates: Can Agile be applied in a fixed-bid project? When I ask them more information, their context is

They have

•  Fixed Date: A new or change request must be delivered by a defined deadline.
•  Fixed-scope: A release that must have a specific set of features delivered.
• Fixed-budget: A budget is already fixed which cannot be exceeded

The first thing to learn about agile is not to commit to something that you do not know and how incremental progress is the only way to predict the future. But, the reality is that over the last 20+ years of the Agile Manifesto, the context, use, and experience with agile provides some evidence that there is a fundamental attribution error concerning the approach to Agile Software development and its execution.

It can be a challenging leadership problem and problematic to resolve. However, there is no direct and clear answer to the query. For clearing the dilemma, I have to recall the elementary difference between a project mindset and a product mindset.

Is Agile Context-Dependent

In my view, the answer is yes and no. Even though the teams can be agile and collaborate to deliver value faster, fixing the upfront scope, time and cost reduce the opportunity to adapt to the changing market situation.

To illustrate this, I need to go back to the bit data. Today, the top 10 most valuable companies defined by market capitalisation are Apple, Microsoft, Saudi Oil Company, Amazon, Alphabet, Facebook, Tencent Holdings, Tesla, Alibaba, and Berkshire Hathaway. Of course, this list changes with the markets, but if you compare that to 2011, the list is 60% different. Compared to 2001, only one company on the list, Microsoft. It clearly shows that although Businesses love nothing more than resilience. Especially, In the RUPT – Rapid, Unpredictable, Paradoxical, and Tangled world, adaptability is essential over stability to stay capable and resilient. 

So, how can you approach Fixed-bid projects in Agile?

Fixed bid contracts are best for shorter-term engagements in duration and linked to a specific business or product goal.

Let’s take the example of Scrum, one of the widely used Frameworks, and see how one can handle fixed-bid projects. The business needs the flexibility to respond to the market, yet Scrum Teams need stability to do anything meaningful. Therefore, limiting significant direction changes to Sprint boundaries is a necessary compromise. I shall try to illustrate the same with the three variables we encounter in fix-bid projects.

Fixed-Schedule

If you consider approaching your contracts using Scrum, You can leverage Sprint. They are time-boxed events within which value is delivered. As per Scrum Guide, They are fixed length events of one month or less to create consistency. Therefore, each Sprint can be considered a temporary endeavour toward achieving a remarkable result. This definition applies in Scrum to every SPRINT. 

 Fixed Budget 

Though, Scrum is silent about how one can do budgeting in Sprints. In my experience, there are two ways one can execute fixed-budget projects in Sprints.

 

Several Sprints can be budgeted as a Single release with a “goal” agreed upfront. If you observe, I replaced the term “scope” with “goal”. The team is free to accomplish this goal as it sees fit, adapting to circumstances as best it can. But, by negotiating the scope and keeping the goal in “mind”, the teams can focus on what is essential. I do not intend to say that one can write the “Goal” on a stone. But, I mean the Project goal can be a commitment similar to a Product Goal.

Fixed Scope

 It can be challenging for a traditional organisation to move towards Agile working methods. However, out of the three variables, I am not in favour of fixing the scope upfront that kills the ability to focus on what’s essential.

In my experience, An organisation trying to move towards new ways of working may consider adding the following contract provisions while establishing Agile contracts.

• Any requirement that hasn’t already been worked on can be swapped out for another equal size.
• Order of execution can be negotiated in Agile environments.
• Both parties can terminate the contracts if they dont see any value.

Craig and Bas did an excellent job of writing how to establish an Agile Contract in their book.

Concluding Thoughts

In short, I would like to recall one of the Agile Manifestos

Responding to Change over Following a Plan

Source: Agile Manifesto

Breaking the conventional thinking and establishing Agile Contracts for software development is fundamentally different and challenging from traditional methods. Using conventional contracts for an agile development project can endanger the execution and push the company to fail to benefit from agile working methods. Furthermore, An “Agile” organisation identifies how to determine and focus on a value-driven approach. It is very crucial while undergoing an Agile transformation. As you know, Software development is not about calculations that offer pseudo-certainty; it’s about continuous inspection and adaptations. I have shared my perspective, and I am willing to hear your experiences in the comments.