Agile for Fixed Bid – an Oxymoron?

I remember the struggles our team went through when we embraced “Agile” methodology for the first time on a fixed bid engagement.

While we managed to deliver the project to the satisfaction of the client, it wasn’t a smooth journey. There was a constant worry regarding schedule/cost overruns that we weren’t able to “enjoy” Agile to the fullest. Over time, we have figured out how to strike a balance between these two seemingly different worlds.

If you are wondering if “Agile” is a good fit for your fixed bid engagements, just take a look at these core principles of Agile methodology.

While Agile methodology offers several benefits, I think these are the ones most relevant to a consulting firm offering fixed bid projects.

Now if you have decided to go “Agile,” how do you ensure that you are able to meet all your “fixed” bid commitments amidst the Agile process? For this, let’s pay a closer look at the definition of Agile.

“An Agile methodology refers to the capability to break down tasks into really small chunks, and executing them in a way that they can be changed easily.”

It doesn’t necessarily mean that there is no predefined scope or timelines. The “change” would occur due to the usual reasons such as “missed out requirement,” “change in the marketplace,” “change in organizational politics” or “change in business priorities.” The change will not occur because the process followed is “Agile.” What “Agile” targets are embracing to make change easier and a more natural process.

However given the contractual nature of fixed bid engagements between two separate organizations, there are some extensions needed to the standard Agile process to make them successful. In my experience, there are primarily three such extensions required for fixed bid engagements.

1. Strong internal product owner
2. Granular backlog planning
3. Defined change control process

Strong Internal Product Owner

The area where a fixed bid team will need to go beyond the standard Agile process would be where interaction with the business stakeholders are required. Given the nature of the relationship between the two organizations, this typically is not possible. What usually works well in these cases is to have a representative from the consulting firm act as the Internal Product Owner. Let’s say you are following Agile SCRUM. The Internal Product Owner will be responsible for representing the client business team in the grooming meetings and daily stand-ups. It is important that this Internal Product Owner understands the client’s business very well to detail out the nuances of the business requirements. This role could be carried out by a single individual or a group depending on the complexity of the project.

The Internal Product Owner should be responsible for keeping the client business team updated on the product progress. One approach is to invite the client business team to the sprint review sessions so that your team gets the feedback directly from the client team. If the client team is not amenable to participating in your sprint ceremonies, the Internal Product Owner should act as the bridge between the client team and your own team.

Granular Backlog Planning

Another area to be considered is the granularity of planning. In standard Agile, the team works off a high-level plan, but the team is not expected to assign backlog items to any specific sprint. A fixed bid engagement requires more granular planning. For Example: all backlog items need to be assigned to a specific sprint. It is acceptable for the team to move items around as the project progresses. However, they need to have a clear plan at all times to address all pending items.

This will help in multiple ways.

• Provides an unambiguous picture to all stakeholders on when the project will hit its milestones.
• Effectively communicates with the client team on dependencies and their impact.
• Helps with change control (more on that in the next section), when the change being introduced has an impact on the timeline.

Defined Change Control Process

What about scope creep? The scope creep should be managed via a defined change control process. If your client is onboard with the idea, you could define the scope in terms of story points, for closer alignment with the Agile process.

The beauty of Agile is that it may be possible for you to accommodate some of the scope changes with no cost impact to the client, especially if the changes are pertaining to items way down in the backlog. Even if you are able to accommodate changes with no cost impact, you should get these items go through the change control route. This will help in two ways:

• Your client understands the value you are bringing in.
• Your client might see an opportunity to reorganize their internal processes with the better visibility you are providing (this is most relevant when you are dealing with multiple groups within the client organization)

So by having a defined change control process, you are not violating the Agile principle of “customer collaboration over contract negotiation.” On the other hand, you could be moving one step closer to becoming your client’s trusted partner.

In summary, it is clear that a consulting firm that offers fixed bid services can embrace ‘’Agile’ to its own benefit as well as its client’s benefit. All that’s required are a couple of well thought through extensions to the core Agile process. I wish someone had handed me the cheat sheet when that client approached us a long time ago!