Thoughts about *How Scrum works in a fixed Price Projects"

The question can be answered this way:
"You will get what will be done up to the budget limit!" In scrum, each sprint will deliver potentially shippable increment to the product. This means that if the product backlog is well prioritized, high-value features will be done soon during the project, resulting in a product that quickly has value. Each sprint will add value to the product. When the budget is reached, normally you should have something to deliver. Maybe it will not offer all the inital features you were expecting, but maybe you could be surprised to finally deliver more, or even better, deliver something that fits the customer needs better!

Now... This question is often biased by a subsequent or underlying question: what happens if the budget is fixed, the timebox is freezed and we promissed to deliver all the functionalilities? This is what I call the "iron triangle", no variables, only solid-framed limitations... Get prepared to negociate! This is what agile tries to change!

Good morning, Leo.

(I really hate the expression "In a perfect world", but...) In a perfect world, "You will get what will be done up to the budget limit" is fine. In the real world... I have been consulting in software development for 34 years and I have never met a manager who would stand still for that.

This is a question to which I have yet to find a satisfactory, or even marginally satisfying answer.

Most engineering and manufacturing companies, that aren't pure "think tanks", when they envision a new project to develop a new product, have a time and cost budget in mind beyond which it is no longer time-effective or cost-effective to develop the product. Maybe they have to get it out into the marketplace by a certain time or they lose their window of opportunity. Maybe the product has to sell at or below a certain price point or no one will buy it.

Most Agile (upper-case "A") processes emphasize the time to complete the next increment (the next "sprint" or whatever one wants to call it) and don't pay much attention to how long it is projected to take to complete the whole project. Ditto costs... most Agile processes don't seem to pay significant attention to development cost targets.

So, precisely HOW is it that one convinces senior management of the benefits of Agile processes when the managers' major focus (it's in their job descriptions) is on time-to-market and total cost figures?

Note the difference between "Agile" (upper-case "A") and "agile" (lower case)... I consider the former to mean a defined process that conforms to the Agile Manifesto. The latter is what most people, particularly software managers, mean when they use the term... at best, they take it to mean "anything that is faster than how we have done it before" including any of the iterative processes that have been in use for decades.

Eric Poole
www.rkt-tech.com

Hi Eric and Usman,

Have you guys taken Professional Scrum Master Course already? The trainer will teach you about fixed price contracts in Agile.

Thanks, Joshua, but that's a little bit like saying "Buy this book and it will tell you". Forums (fora? fori?) like this one are for getting answers to specific questions, helping one another, and holding discussions, without having to go to the expense of traveling to some course or buying some book.

Hello.

I'm quite new to scrum, but I'm really trying to learn by reading and reading and participating in trainings, so my thoughts are:

Scrum does not mean "no plan/no estimation" In the beginning of a product development you have to figure out what the needs of a customer are, and of course, they are estimated.

Nevertheless it is clearly stated, that those estimates are only rough estimates to get a plan how many sprints you need to deliver if you know the velocity of your team.

I know, this does not sound like scrum estimates are really exact, but in my experience with waterfall projects I found the same but with more investment in the planning, because the best IEEE-requirement-sheet always only says "it is as described if nothing changes!"

So my project planes in waterfall most of the time show something like "exact dates" but this is an illusion MS project gives me ;-)

I heard about an interesting presentation about selling this agility to the customer: Jeff Sutherland talking about "Money for nothing, Changes are free" google it, I think it's quite interesting.

So estimating (and fixed price projects are much about estimating) is always hard and the bigger the project and the more unknown a domain is, the harder it gets. But scrum does not make it harder, it makes it faster and more flexible.

may I was able to bring a few things/thoughts in this discussion.

Br,
Philipp

Eric, one could have a good enough Product Backlog holding requirements and other ideas to build into the product, consider expected team size, look at past velocity or comparable figures to figure out the estimated #Sprints and have an indication of timing and cost. Actual implementation is still required to validate all these assumptions. If time and budget have been fixed, scope will become negotiable. Product Backlog and progress on it (e.g. burn-down) will keep all involved informed about the feasibility of the initial plan.
The amount of detail that's put in the initial Product Backlog depends on the level of trust in general. Creating an exhaustive, fully detailed Product Backlog is not helping much but may be required. Do note that this is not an obligation posed by Scrum, but a decision taken outside of Scrum.

There is always something like ("Yes, but reality"). As in my answer to Eric, always look for highest achievable. Nevertheless, if I give my honest opinion to people on the topic of fixed prices, in general everyone agrees with my statement: "Fixed Price bids. An open invitation to bribe, cajole, lie and cheat.". All my thoughts at http://ullizee.wordpress.com/2012/10/07/fixed-price-bids-an-open-invita…

My 2cents worth: The problem with Fixed Priced Bids is that it is based on a contract...and therefore the contract takes precedence over everything else. This would go against the AGILE Values of valuing customer collaboration over contract negotiation. In my experience (at various clients), once the AGILE mindset and the thinking behind scrum is explained to the client, the need or demand for a fixed bid price is dropped in favor of the client being able to continuously 'direct' the product. This is the value of SCRUM and AGILE in my world. Alas, Fixed price contracts are going to be around for a while though...

I recently applied Scrum within the DSDM framework to support public sector fixed price contracts. Essentially, this was done by treating a Sprint as a DSDM delivery timebox, and therefore as a trading space for negotiating requirements in or out of scope. Cost and time were fixed, but scope became variable. The tradeable scope consisted of the Should and Could requirements of a MoSCoWed sprint backlog.

Admittedly this was done before the Scrum Guide changed from sprint commitments to forecasts, but I suppose it might be possible to do something similar by placing the contractual emphasis upon sprint goals rather than upon a sprint backlog.

Fixed price work certainly presents challenges for agile practice, but I agree that it is going to be with us for a while yet.

Typically here is what we have seen:

If you fix cost/price and time (time is cost really assuming fixed team) and deliverables, then you can only affect quality (assuming fixed team or team changes wouldn't have significant impact). That is bad. So optimally you develop trust with your customer and fix budget and time and incrementally deliver. Because estimation for work further away is not optimal this is the best case.

However if your customer doesn't trust you yet to honor your commitments then you need a really experienced and stable scrum team with extremely consistent pointing skills. Then it is possible to take epics, break into stories and fix price many types of projects assuming the amount of research is minimal.

So if you are doing your fifth inventory system as a stable team it's doable using velocity based planning. Otherwise, you end up just lying to yourself and your customer and continuing the vicious cycle of them not trusting you or constantly compromising and trading off.

First question is what and who was used to Estimate the project to come up with the Price? Is it based on what a project of this size would cost when your usual project methodology was used?

If it's a project that only has the budget of what's left in the kitty, then it becomes a bit tricky.

The emphasis in my opinion should not be so much on the SCRUM Master, but on the Product Owner. He or she should be very mindful of the scope and therefor what can be done with the limited budget. If the business only has money for the basic version of the Toyota Camry, then the expectation should not be that the Deluxe version can be delivered, just because SCRUM is flexible in the requirements.

One of the main objections of using SCRUM is that the more experienced developers don't like it and many say that it 'dumbs down' their work... they may be right. For a fixed price SCRUM project that might be an advantage as you could get away with hiring less experienced and therefor less expensive developers... just a thought.

Nicko, never heard of experienced developers not liking scrum. I have heard of less informed experienced people not liking scrum because they don't really understand it as well as they think. They put the emphasis on the ceremonies instead of the planning and measuring and communication aspects. However it has been shown that a team that has a strong set of values and purpose are for more predictable in terms of productivity than experience alone. So I would rather have a focused set of less experienced developers that are motivated and focused and clear on our objectives and how we are going to execute our work than a bunch of experienced developers that want to act as independent silos and just code.

Of course experienced developers who are focused, clear on the objectives and truly understand the Agile mindset and have a long track record working together as a cohesive team would be best...

Sometimes FP is associated with waterfall. And it's partly true, 'cause you cannot make an FP bid if you don't know the requirements. But the question is about running a FP project, not initiating it.

I like the comparison heard somewhere: it is like a vacation. You have a budget and a time -- and it's up to you what you do tomorrow: relaxing, driving,hiking, or something else. It'll be over when you achieve the goal, or spent your budget.

I'm applying Scrum on a FP project. Have contract, have timeline, have predefined set of modules to deliver, and have estimates for each of them. When we have stories/requirements ready - we review them with the dev team against the original estimates on the BL refinement meetings. It's a good point to review the complexity and make a decision to lower/higher the grain. The result can be compared with the original plan, so I can even do EVM.
From other perspective - it's a little bit more challenging when the scope is changing (creeping). If it cannot be aligned with the original limitations - then the only right thing for me is to review the contract with the counter-parts and to execute an amendment if possible.

You should know, that fixed price projects have got not only advantages but disadvantages. Look at this picture published by Cleveroad - https://www.cleveroad.com/blog/time-and-material-vs-fixed-price--hot-discussion-of-the-best-pricing-model 

Scrum becomes probably irrelevant when one speaks about "fixed price". If the price and feature-set are fixed, then someone had already decided. 

I've another question, though. How do you deal with tenders? How do you attach a price to a tendered project knowing that you can't be too lax because you'll risk losing against a competitor or too strict because you'll lose money?

Interesting question, Yagiz.  Assuming you still mean a tender that requires Scrum, I think you have little choice but to assemble a team, build a reasonable product backlog based on the RFP, estimate it as best you can given the RFP, past experience, and the vendor meetings (if any), then come up with the most competitive cost you can to deliver the PB.

Remember that the tender will also include why you are a better vendor to go with than the others so hopefully the final decision will not be on cost alone.  That has been my experience.

I want to share my experience on that. I am working for an IT consulting company and we often have to deal with tenders. Fixed price does not mean "no updoming changes" and does not mean "no complexity". Somtimes it just comes from regulatory rules or not having a trustful releationchip.

When we have a project and see the risk of weak requirements, complexity in technology and fear that requirements will change, we use scrum to mitigate that risk. We still benefit from addressing problems as early as possible. Scrum still guides us the fastes way through complex scenarios, as we still can learn based upon experience. 

Another point is what happens to requirements changes in a waterfall project? You are changing the scope and renegociate the costs. Same happens to a fixed price scrum project, but with two advanteges. First, through transparency on the impact of that change and experience from past sprints it makes is easier to estimate and argue the upcoming costs. Second, through frequent feedback we will get to this point faster. Renegociation with budget left is much easier than at the end of the budget.

The agile manifesto does not say, that there are no contracts anymore. But it says that it is more important to deliver software. In our case it is more important to deliver a software that satisfies our costumer as this is the way to build a trustful relationship. We than have the possibility to change the working mode for further projects.

So the conclusion is that there are more important reasons than the pricing model to decide whether to use scrum or not. "Scrum employs an iterative, incremental approach to optimize predictability and control risk" (Scrum guide). This is still valid for fixed price projects.

Kind regards Benjamin

According to my experience, Fixed Price contracts are not that Agile, which makes the project somewhat risky for both sides. If the contract was drawn up correctly, then it means not only the price is fixed, but the tasks and the list of features as well. As the developmental process can't go smoothly all the time, everything is changing and you can't expect every failure you'd have. And if we are talking scrum and fixed price projects, in my humble opinion, it's better to choose a different development methodology. I think each team should pick the dev methodology that suits the project better, just be agile ;)

Instead of fixing scope, one can fix size and let scope remain variable. It's important to have a week or couple of weeks long workshop at the beginning of the project to discuss the work and come out with resultant size.

Now whenever you want to move something in the Product Backlog, you take something out of similar size from the Product Backlog.

More details of this approach can be found here

The only way a fixed price contract is feasible in Agile is if the scope is adjustable. The client needs to understand that the scope can never be final and Product backlog is an emergent document. So if the client wants to use Scrum for a fixed price contract he needs to be first come into terms with the concept of Product backlog being emergent and therefore his scope being transient. 

If the client agrees to this and focuses on what he wants most with the help of the Product Owner who can prioritize the most wanted functionalities/ requirements first, Scrum can then be applied for fixed price (bot with varying  scope but constantly reprioritized for best value output within that fixed cost)

Reading this thread it seems to me like proponents of agile methodologies have become very good at obfuscating the problem statement with high level terminology which might in fact be the only way they are able to get clients to buy into SCRUM in the end.



What it comes down to, in simple language, is this: You're not selling a product, you're selling your expert services in order to facilitate a project that will produce an end product. The custom solution they're looking for doesn't exist and has never been built before but you're there to help them make a dream a reality. Projects involve R&D and have many unforeseen things that can go wrong during development that effect the timeline. Projects also give the client the benefit of time to rethink what they want which influences the scope. The only question is this: Can you make a potential client understand that you're not selling them a product but a service. Can you make a client understand that there is no way you can say: "I'm selling you a bike with a headlamp and adjustable gears for $100 and will deliver it in a week". All you can say is: "I can start building the bike and I should have something you can take for a test ride for $50 in the next week, by the time we get to $100 you might only have a bike with a headlamp".



Some companies can't or won't function this way. Usually this is due to the way their finances are organised as mentioned above. They need to be able to buy what they need at a fixed cost. In those cases what most companies do in my experience is say: "I'm selling you a bike with a headlamp and adjustable gears for $300 and will deliver it in 3 weeks".

It may seem expensive to the client and it might seem like a long time (and it is) but it's usually the only way to do business and it's usually much more likely that you'll be able to sell those clients an inflated price than it is to sell them a pricing model that they completely unequipped to deal with.

With the added cost and time to cover the unknowns and overruns you can then run with any methodology you want and of course then a SCRUM methodology is recommended in order to produce a quality product.

Thanks for your widsom. I might tell you that your way of speaking seems a little intended to be rude, but maybe that is because I am not english native...

Here is the catch: if you don't feel like using Scrum, don't use it. It isn't the solution to all.



We are using it to improve things, to respond to the problems that are happening.

Too often in IT project, I've seen problems with cost, time, delays and lack of transparencies, but with Scrum it gets better for me and my clients.

For your bike explanation, what do you want to fix as value ? If you want to fix time and price(100$, and in x weeks), then the scope should be negociable: what are the type of gears ? how simple is it to build ? which quality ? Maybe to reduce cost you can improve the process for building your bike ? your tooling to deliver bike ? the decorations on your bike ? ....



No this is not "usually the only way to do business". This is what you think and a lot of people here could tell you otherwise. Now if you want to believe or not, it is up to you. I suggest you to learn from people, before thinking there is only "one way".



And again, if you want to use something else that Scrum, you are free and there are other great framework/methodologies.

 

Agile world permits scope only as variable dimension . Hence

1.  drive the release based on prioritized features. 

2.

create a good storymap and work towards developing minimal viable product first n then as per roadmap only  

3. 

Make sure creating good Agile reports n Sharing them with customers to gain their confidence towards honest efforts    Team is putting to make most out of the time available . As fixed price project with variable scope Must build the trust with customers about them getting most out of  the money they spent .

I disagree on scope only. There is nothing written on it in Scrum Guide.

Imagine you have a fixed scope, with fixed time, but with  a bigger budget than needed. For example imagine some huge functionnal fix for bank system. The scope is first rather well known, There is a deadline from state/Europe, ... .

But as it has to come true, you can hire more people (even if it is not linear to solve the problem).



How would it not be agile to use Scrum to do it ?