Agile In Fixed Bid Projects
Agile in fixed-bid projects
1. Agile in fixed-bid projects
2. Abstract or Executive Summary
It should be written when the white paper is completed, including the most attention getting insights, findings and recommendations (Should be effectively 150-250 words)
With little changes the fixed bid project can be executed using agile methodology,
3. Outline
It is a table of contents explained in a manner to let the reader know of how the white paper is structured so it becomes easy to know the flow
4. Introduction
It’s an opportunity to introduce readers to the problem, need or pain point that is the basis of the white paper, as well as the related solution (product or service)
Most of the time we come across customers will ask for fixed bid projects using agile methodology a real problem with fixed bid contracts is the scope, which is fixed in terms of what should exactly be built instead of how much we should build.
Why are clients so obsessed with fixing the scope? We understand that they want to know how much they will pay and when they will get it. The only thing they don’t know is what exactly they want to get.
5. Problem Statement
This section allows to expand upon this overview, and thoroughly define the problem statement
For example
- What is currently happening in the market today? (i.e., What’s the current situation?)
- What are companies and/or individuals struggling with most, and why?
- What are the specific problems, needs and/or pain points?
6. How the product or service solves the problem
This section allows us to go into the specifics of the solutions
- Introduction of solution
- Detailed description of the solution
- Targets of the solution
- Business benefits of the solution
- Provide examples
Use of graphs/charts would be helpful in visualizing the solution and the benefits it brings. This section should include any comparative product if needed.
How to fit agile methodology in Fixed bid projects, one of the projects we implemented as below
- Agile Contract
- Discovery phase
- Sprints Duration and Releases based on MVP/MMF
- Change Control board
- Engineering practices
- Acceptance criteria and Sign-Off
- Agile Contract
While we adhere on agile manifesto “Collaboration over Contract negotiation” however setting expectation on few of the following aspects becomes important for fixed bid projects.
- Create 2 phase contract approach – Discovery & Execution phase
- Scope finalization post Discovery phase
- Change Management through “Backlog prioritization & De-scoping” practices
- DoD at User Story, feature and Epic level, Acceptance criteria at project level
- Commitments based on Epics/features
- Discovery phase
- 10 to 15% of the project duration should be set for requirement analysis i.e., building product backlog (in terms epic and feature) with customer collaboration.
- Estimate the Epics and feature using relative estimation (e.g., T sizing)
- Identify the stakeholder
- Make available of required resource
- Setup all the required process, tool and environment required for execution (e.g., CI/CD, software/server setups).
- Come up with least 2 to 3 sprint of user stories with priority.
- Sprints Duration and Releases based on MVP/MMF
- Derive MVP/MMF
- Define Sprint duration and No of sprint required for the project.
- Change Control board
Agile is responding to change more effectively. This is where the actual problem arises in fixed-bid projects following agile methods. In a fixed bid contract the schedule, cost, and scope are fixed.
Maintaining change requests
we need to treat change requests differently in agile approach which is designed to avoid change requests. Careful analysis of the change request is required as we have baselined all the requirements. We can then exchange requests to swap stories of similar sizes. While sizing and exchanging the user story, it’s important to consider the impact of a new user story on the current design.
We should focus on changing the fixed scope into the fixed budget, i.e., changing scope within a defined size. For example: We can change a feature with a size of 100 story points by replacing existing user stories with new user stories of a similar size.
- Focus on Engineering Maturity:
Agility without having engineering practices in place is Myth – As we are talking about shorter sprints & releases –Tools & Automation plays a key role in enabling Effective Collaboration, Faster quality assurance through Continuous Testing, Integration and Deployment.
7. Conclusion
Here few pointers can be taken care of
- Summarize the white paper objectives
- Review the problem statement again
- Highlight the solution and their value
- Finishing with a strong statement
Fixed bid contracts are often considered harmful and against agile values and principles and many agile adopters say that we should simply avoid them. But most of the time they cannot be avoided, so we need to find ways to make them work for the goal we have, which is building valuable quality software.
In some aspects of fixed factors are even better for agile teams since we are used to working within time boxes and that is exactly what the fixed date in the contract (and also fixed price) are — just time boxes and boundaries. The only thing that actually bothers us is the scope and with this article we tried to gather together ideas on how to deal with that limit.
8. Additional Resources/ Resources used
This section mentions additions resources that can help know more about the problem and the solutions available. It should also list the resources used to build the white paper.
1,749 Comments on Agile In Fixed Bid Projects