- All requirements have to be detailed upfront to estimate properly
- Vendor usually pad estimates so it's more expensive and there is waste of resources.
- It puts vendor and client one against the other during the execution since vendor wants to reduce costs and client wants more for what was paid.
However, sometimes change the contract type is not an option. Although the disadvantages or how much we want to change that, many times the contract has to be a fixed price for external reasons (it’s a government contract, very old fashioned company, etc.). So, here is a list of alternatives for implementing agile practices in that environment and get the most of it.
First at all, Fixed Price contract usually fixes all variables (not only price). It means that scope, time and costs are fixed and any change on any of those variables must be agreed by both parties in a new contract thought a bureaucratic change control process. That’s why FPs are painful.
Note: If any of those variables is not fixed, 99% of the problem is solved. For example: you can agree to fixed total cost but keep variable the scope and time to be decided on each sprint planning. Once the budget is consumed, project ends.
In this case, there is a list of agile practices you can use or adapt to get a better execution.
- Changes: This is the most critical area since in agile methodology we embrace the changes but on a Fixed Price contract we try to avoid changes as much as possible. Anyway, you still can do a proper change control process and try to trade USs with the same Story Point size from the product backlog. So we can have the flexibility to prioritize a new feature leaving out of scope another feature of the same size. As shown in the picture below, all User Stories that are waiting the product backlog can be changed or traded for new ones. But, once we move them to the sprint, that moves the User Stories to the fixed part of the scope.
Warning: Changes for a fixed price are disruptive. It means that receive the change, estimate it, trade it for another User Story, update the plan and communicate it to everyone takes time and if you do this many times per week, team interruptions will affect the velocity and the whole plan. - Effort Estimation: Regardless the process implemented, you will need to estimate your effort in complexity and size before converting that to man/hours. So, using SP or ideal hours is a good approach to abstract the size from the execution hours. As this will be a fixed price, all the estimates needs to be done upfront, so we will need a release planning session and estimate all US in the backlog. Then, it’s also a good practice to repeat the estimate during the sprint execution and compare that new estimate with the original one. This point is particularly important since as the project progress our product knowledge may change as well as our estimates.
Warning: Since we are executing a fixed price we need to start tracking deviation against the release plan (something that is not used in a full agile mode) and adjusting our variables and release plan after each sprint. - Sprint Planning: This meeting is useful even though you have all the USs detailed and estimated since the project beginning because this is the best time to: 1. Review your velocity and deviation from the plan and take any preventive/corrective action to it 2. Take User Stories from the product backlog. This means that those User Stories will be moved from the variable part of the scope to the fixed part and won’t be able to be traded from that moment. 3. Ask any pending question or definition we may need to complete the sprint. Warning: The priority of the User Stories has to be agreed between the 2 parties. Sometimes the development team wants to start with the most risky ones and client is not interested on that order since has already transferred all the risk on development side using a Fixed Price contract.
This is a first list of good agile practices that can be implemented in Fixed Price projects.
No comments:
Post a Comment