Most clients understand a fixed price contract to be a fix of scope, budget and delivery date.
These would appear on the surface to be against the principals of Agile. So should Agile be recommended against in this situation or are there steps that can be taken to make Agile work in this scenario?
Yes, it is possible to use Agile for Fixed Price projects. However, I find it extremely rare that when you show the results of an iteration / sprint to your customer that they don't add or change something. It is these opportunities that allow you to then re-negotiate the scope or delivery date in order to accommodate their changes.
If you were allowed to go off in and build in a vacuum and then just hand off a working project with no changes from your customer you would be the envy of the software development industry.
One of the major selling points of Agile methodologies is that the iterative nature allows the customer to receive an updated deliverable after every iteration (e.g. 2 weeks).
In Agile, you don't have a fixed/signed-off scope or requirements - you maintain a Feature Backlog and every week you have a meeting with the customer in which they have the opportunity to change their mind about the priority of certain items, based on their testing of the deliverable they got last time.
Features in the Backlog will have relative effort estimates which will indicate how many of the top priority items can be implemented by the end of the iteration.
If you've got a fixed number of engineers working on the project, then your number of iterations is the contract price divided by the cost of an iteration.
It is highly unlikely that you'll get through all the requirements, so it is the job of the Agile PM to manage the customers' expectations accordingly so that they prioritize to get the most important ones. Indeed, when they see their product/service coming together, they often throw out the older items and come up with more relevant ones.
Given the flexibility and responsiveness to the customers' change requests that this method gives, I'm yet to see a customer who beat up the supplier for not delivering all the features requested at the beginning of the project.
It is very important that the specific feature list is not part of the contract. The contract should be on a 'Time and Materials' basis with a vision document guiding what work is going to be done.
The short answer to your question is, Yes!
The answer you are looking for is below.
In order to get my point across I will minimize Fixed Price Contract and Agile definitions.
In my own words, Agile methodology is nothing more than having short burst of full development cycles to ease the anxiety of the customer. Sorry that I am minimizing such a great platform in these words, but in essence, the reason it exists, is because with previous methodologies the customer was surprised too often.
Now, a fixed price contract is the contract that has a set scope, and the vendor has 100% the Risk (in most cases) of making sure he estimates before signing the contract with the buyer.
You can "easily" (nothing is easy) break the scope of the FPC in 1-n sprints, and use agile to work through it. Having a very minimal product always ready to be presented to the customer. This will make Agile and FPC work together.
I will go a step more to say, I have never done this myself, but I think this combination could be a winner, for the vendor to identify risk in his side early on, so that he can minimize any loss.
I hope this helps you.
Thanks, Geo
Absolutely - The DSDM Atern approach assumes a fixed deadline and fixed price.
The flexibility comes from the prioritised requirements list. If new features are added, the customer is required to look at that list, and remove features that he/she is willing to lose in their place.
I am working as a CTO, and we take projects on fixed price. Even when the client wants the price on hourly rate, he/she expects a cost estimation with deadline, eventually making it fixed price.
As I have teams in India too, we do projects from $500 and above. Now, Agile Scrum is philosophy and science both, and it means that we can use it by modulating its main parameters, that is:
Involving Client in developing SRS (Software Requirements Specification) and charging him/her for that other than the development cost. DURING COMMUNICATION (pre sales) explain to him/her that if she/he feels that this going over her/his budget then wait until she/he can afford it. If not, tell him/her the features which are not important and remove them. Trust me, when you do that with honesty, he/she will come to you and only you when she/he has the money to do it, but do tell her/him that rate might increase in this many days, as your development cost might change.
Everything agreed you start development as per SRS. Make the Short one liners of complete SRS and allocate daily tasks to team. Ask them what will be complete in next 15 days, 7 days and today.
Have daily meetings with what are the tasks in hand today, and we are going to finish everything today. Then ask each developer to smoke test it, and then check each others code on completion of a module, as defined in SRS.
Get it tested by QA. Define test cases. Once the issues are there, allocate people to resolve those. Developers tend to relax; keep them on high alert always.
Few more things, add time for R&D as developers are not Gods, Keep margins for issues, developers falling sick, and testing, UAT, and making the site live.
I have delivered projects in time and have done so successfully.
