Fixed bid and Agile are two different mindsets. Fixed bid project involves fixed cost, fixed scope and fixed time with visibility of when a project is completed. However, Agile is an adaptive approach. The agile philosophy recommends responding to changes over following a plan. Mainly, in agile all you can forecast with confidence is your next sprint. However, the value that agile offers makes a lot of sense to follow the agile principles for the product development.
For an organization, agile with fixed bid is best of both the worlds. Fixed bid projects offer great value to a company. It is important to know the project schedule. Leadership knows when a project is completing. They know how much it will cost. It assures predictability. It helps organizations in planning the next steps. They know when resources are available to allocate to another project. It gives organization clarity around budget allocation. For a client and vendor, it is a shared responsibility. Vendor has deadlines to meet. At the same time, the client wants to make sure they proactively remove any roadblocks or obstacles during the product development.
However, fixed bid projects have constraints. These are fixed cost, time and scope. Managing all three constraints determines the project quality. Any change to any of these can impact the other two. If there is a change in requirement or new feature is added, it can affect the timeline and cost of the project.
There is a widespread belief that fixed bids are not a good fit for Agile. Let’s discuss how we can make fixed bid projects successful in Agile environment.
Ingredients of a successful fixed bid projects in Agile environment
Discovery Phase
Knowing full requirement before start of product development is a myth. We need a discovery phase to understand the scope of the project. Depending on the project size, a typical duration of a discovery phase is 2-4 weeks. It helps in reducing project risks. During the discovery if we find complexities that needed to be addressed before the start of development, we can carve out a POC (Proof of Concept) phase. Here is an example at a high level how a typical discovery phase looks like:
Discovery Phase Duration: 3 weeks
Outcomes:
Project Estimates – <No. of months>
Sprint Plan – <No. of sprints>
Project Cost:<Amount is dollars>
POC (Proof of Concept)
POC addresses high risk technical use case of a project. The objective is to reduce technical risks and help in making sure the project is technically feasible. One of the important deliverables of a POC is a reference architecture. This architecture can be referred when development starts and can help in simplifying the development phase. After completion of POC, the estimates are reviewed and can be revised if needed.
Estimates
We need to make sure that all stakeholders understand that project is a fixed bid provided the scope is Fixed. The estimates should include all functional and non-functional requirements. For example, it should cover any security needs, third party dependencies or any specific compliances that needs to be taken care.
Assumptions play an important role in the estimates. Always provide assumptions with the estimates. These need to be explicitly mentioned in the plan. For example, if it is a mobile project supports only the iPhone, we need to put this as an assumption that the project only supports iPhone and does not support any other mobile device.
Manage Product Backlog/Scope
In the real world, the market conditions change over time and therefore requirements change during the product development. It requires prioritization/ reprioritization of the product backlog. If we add a new user story or a feature, we should remove a low priority/user story of equal story points (size). Ideally, we should be adding following provision to the contract – “Any new feature / user story can be swapped out for another equal size feature/user story”.
Size Not Scope
One of the important factors to consider when we do fixed bids, instead of Scope we should consider Size. Size is a number of story points targeted for the project. It will be the total effort needed to complete the project. This way we can still change the requirements, however the total effort or size will remain same. Therefore, there will not be any change on time or cost of the project. This is very important for successfully executing fixed bids with agile principles.
Sprint Forecasting& Scrum Master
In agile, initial few sprints are needed to determine your sprint velocity. After that, sprints should be predictable. Scrum Master has major role in managing sprints and forecast correctly. This professional should always be looking out for removing bottlenecks or dependencies in the process. For example, if a user story is waiting for peer code review before it is marked as done. Scrum Master should get a time on the developer’s calendar to get it reviewed. This way sprint can be seen progressing.
Transparency
In my experience, one of the things that really helped was to establish transparency with your leadership and clients about project progress. Highlighting risks early in the cycle can be very helpful. These can be technical risk, scope risk or external factors like resource unavailability, COVID etc. It helps in building credibility. This also helps in course corrections.
Manage Stakeholder Expectations
In an agile world, managing stakeholder’s expectations is very important. As I mentioned earlier, we should make sure it is explicitly clear that the project is a fixed bid with Fixed Size. It means we cannot just add new requirements to the scope. If new user stories are added, equal size user stories need to be removed from the backlog. We should send weekly reports to all the stakeholders to make sure they are aware of last week’s accomplishments, any roadblocks and plan for next week.
Doing frequent management retrospectives is very important for managing expectations. This is different from sprint retrospective. In this meeting, invite all the important stakeholders, reiterate project objectives at the start of every meeting. Discuss accomplishments, challenges and explore what can be improved. This way we can proactively identify any roadblocks or challenges and take corrective actions. Finally decide the next steps, it could be a near term roadmap or any other project milestone that is on high priority.
I have written this based on my experience on things that work well with fixed projects in agile environment. If you have any questions regarding the approach, or share your feedback feel free to reach me at my email or connect me on Linked-in.
Rohit Sinha
rohit.sinha@excellarate.com
