How agile development projects are being sold vs fixed bid contracts
I've come across this topic many times and would be good to learn and read about real world success experiences on how consulting/software development companies are successfully selling its services under agile and what strategies work the best. One of the major concerns to overcome is the complexity to arrange a contractual agreement that accommodates change (let's say client is coming from a waterfall approach) since he is going to want to know how much the project will cost, and when they can expect to receive working software as done in fixed bid contracts.
What would be the best strategy to integrate a "fixed price" in a contract tied to a feasible delivery under scrum? Would breaking down the scope into effort and multiply it by an agreed upon rate would be fair/good? But... as well all know, scrum is based on empiricism and knowing everything from the beginning is impossible.
I've never been involved in this process, but could you determine the cost of a sprint (e.g. $50,000) and target to provide X sprints, but give the client the opportunity to end the development work with 1-2 sprints notice? That way the client gets to provide ongoing feedback on the requirements, and can stop at any point they are happy with the product. The end of dev work buffer would be there for any handover that may be required.
Fixed price projects are a very waterfall way of thinking, as you've mentioned, and can take some effort to convince others that a different way is better.
What would be the best strategy to integrate a "fixed price" in a contract tied to a feasible delivery under scrum?
Shouldn’t each Sprint result in a feasible delivery?
Why not sell a client a certain number of Sprints?
In addition to the approach suggested by Ben Brumm and Ian Mitchell, I'd also suggest that every fixed-price contract that I've seen has had some kind of change control process. It's almost as if there's a realization that some aspect of the project - such as the schedule or scope - will change and these changes will change the cost. However, change control is built into Scrum and most other Agile methods. The risk to the buyer is reduced.
Another observation I've seen when it comes to fixed price contracts is there's not always a lot of detail on scope because there is typically many unknowns at the time these contracts are being constructed.
This can result in inconsistent expectations across groups and a lot of change requests as Thomas mentioned.
'Selling Sprints' helps set expectation of what is being delivered based on the Sprint Goal and can mitigate risk in the process.
Clients normally have a ball park figure /Budget for a specific project /Product . The best bet for fixed price contact is to clearly indicate that X amount of sprints can be performed. Or the alternate is sell sprints as mentioned above,
The best bet for fixed price contact is to clearly indicate that X amount of sprints can be performed
Peter, the risk with the above suggestion is that it reinforces a fixed scope dynamic, and any change in scope (which is inevitable!) will be accommodated by simply increasing the # of sprints (x+1, x+2...), which is akin to extending a project timeline under the traditional waterfall approach.
Timothy Baffa , I have found that this is the best method to drive to MVP status. Y$$ = X sprints. Invoicing is being done per sprint and gives the customer an option to back out if they are finding that the devop is not creating value after a couple of sprints. Having said that its a highly collaborative framework with the customer to reach MVP status. Once that milestone is reached, the it becomes more of time and materials.
Not sure how others are managing this for creating new product for customers .