Thoughts about *How Scrum works in a fixed Price Projects"
The other day, I have been asked a question about how to bring scrum into fixed price projects... Interesting though.
I would like you expert guys to give some thoughts about this.
Any experiences would be highly appropriated.
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.
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.
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.
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.