Skip to main content

How agile development projects are being sold vs fixed bid contracts

Last post 02:38 pm November 21, 2019 by Peter Dawson
7 replies
07:57 pm November 18, 2019

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.


09:32 pm November 18, 2019

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.


03:00 am November 19, 2019

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?


10:12 am November 19, 2019

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.


03:01 pm November 19, 2019

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. 


06:20 pm November 19, 2019

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,  

 

 


09:07 pm November 19, 2019

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.


02:38 pm November 21, 2019

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 .


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.