18

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?

13

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.

  • 1
    +1 really like the emphasis on renegotiation. Agile is a risk mitigation technique as much as anything else, but you can still get burned by scope creep, especially on a fixed price contract. – DaveParillo Feb 8 '11 at 4:11
  • The downside of renegotiation is that it can become a real time-sink. If you don't have an easy going client, it's very easy to become bogged down in contract re-negotiations. – Todd Ropog Apr 4 '11 at 19:17
2

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.

  • "It is very important that the specific feature list is not part of the contract." Then are you saying that Agile doesn't work with fixed price contracts? As specified by the OP, fixed price contracts include fixed "scope, budget and delivery date." Fixed scope would require a feature list. – Todd Ropog Apr 4 '11 at 19:15
2

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

  • So are you saying Agile works with fixed-price contracts as long as the contracts are only for one sprint at a time? So after each sprint you negotiate the contract for the next? I can see that in theory, but I don't think most clients will go for that. – Todd Ropog Apr 10 '11 at 20:54
  • @Todd, you are right, my point was to make my point clear. This was using theory to explain my point. The main objective of my answer is to make sure the person asking the question understand that is possible to have a fixed contract and agile on the same sentence. :) Thanks for your comment. – Geo Apr 10 '11 at 21:48
2

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.

2

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.