Can fixed scope + fixed deadline + fixed price contract ever be made to work with "agile"?

Question

Some projects we run internally using are Scrum, while still being "fixed everything" to the customer. We're experiencing mixed success on our part (the customer likes the visibility of the burndown chart). Can the types of projects we work be successfully executed using the agile methods?

Answer 1

Well, I've worked mostly in "agile" environments (although we don't use the lingo), and I've done fixed cost things. Generally what it amounts to is cost-plus, since no company can afford to do everything for free, and requirements do change and evolve as the customer figures out more clearly what they want.

The initial requirements for the fixed cost portion have to be done much more carefully than they are done in a typical iterative environment, making the process somewhat less iterative. The "plus" part of the contract can be more iterative, provided we have fulfilled the fixed cost portion more or less satisfactorily to the customer.

Answer 2

I would like to pose a counter-question:

Can fixed scope + fixed deadline + fixed price contract ever be made to work, period?

The "good/fast/cheap - pick two" saying isn't just some silly engineering joke. Every project manager worth his salt knows about the Project Management Triangle:

You're telling us that the cost, scope, and schedule are all fixed. That leaves no room for maneuverability or error. None. You could choose to view "Quality" as an attribute, but it's not a "real" attribute, it's more like a meta-attribute that's derived from the other attributes (cost/scope/schedule).

The problem is that this never happens in reality as long as your project is being planned and executed by humans.

• Requirements and specifications never cover every edge case unless they've been drawn up in immense detail by qualified architects and designers, in which case the project is already half-done; and even then there's still the possibility of error.

• Unexpected costs will pop up leading to budget overruns. A subscription expired. A manufacturer discontinued their support for a product you're using and you have to find a new one. An hourly contractor raised his rate under threat of departure. Your entire team just went on strike, demanding a 10% raise and an extra week of vacation.

• Schedules slip. Unforeseeable problems crop up; that charting component you've been using for 5 straight years isn't compatible with Windows 95, which your client is still using. An obscure bug in 64-bit Windows causes serious UI glitches and you spend nearly a week tracking it down and developing a workaround (this actually happened to me). Your senior developer got hit by a bus and you have to go recruit and train a new one. Your estimated delivery date is always wrong. Always.

  See Hofstadter's Law:

  Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Agile methods are all about juggling around the cost, schedule, and scope. Most of the time, they're specifically about juggling around the scope and sometimes the schedule, which is why you start with nebulous user stories and plan revisions instead of full versions. Different methodologies use different terminology but it's all the same basic premise: Frequent releases and a rebalancing of the schedule and scope with each release.

This makes no sense with a project that is (or claims to be) either fixed scope or fixed schedule.

If one project attribute (cost/scope/schedule) were fixed, I would tell you that it might not be a good fit for agile methodologies.

If two project attributes are fixed, then your project is definitely not a good fit for agile methodologies.

If all three attributes are fixed, then your project is probably going to fail. If it actually ships, then either the original schedule was massively fudged, or the client has managed to delude itself into thinking that you actually delivered what was promised.

If this contract is still on the table, I urge you to reject it. And if you've already accepted it, may God have mercy on your soul.

Answer 3

I love this quotation:

“Scrum is great for either fixed-date variable-scope, or "fixed-scope" (which always grows) variable-date. If you're doing fixed-date fixed-scope, I recommend waterfall or RUP, which will buy you a few months to look for a new job.” ~Michael James

Answer 4

Sure, as long as your quality bar is kept remarkably low. I'm a believer in the old iron triangle of "delivery time / quality / price" where you can pick two, but then the other one floats. It sounds like you've fixed the delivery time and price (and also the features) so really the only thing that can give is the quality.

That said, if you're using a burndown chart and you have the highest priority items being done first it might be acceptable to have a handful of the most important items done in the specified time-frame for the specified monetary amount. At the very least your client will see that you are controlling the process somewhat, with a deliverable at the end of each iteration and they have the ability to say what's most important.

Otherwise I think that committing to a fixed time, feature set and price is foolhardy and will lead to heroic efforts resulting in lower quality and less maintainable code. Agile is not magic fairy dust.

Answer 5

Fixed price / fixed deadline / fixed scope can be done at least as well agile as it can be in waterfall.

In waterfall, time estimations are inaccurate, and details end up being implemented differently than the original specifications. In other words, the deadline/scope can't be known exactly in advance.

In agile, you can do sprint zero to generate a backlog of user stories, and make some estimations. Then agree to meet the value stories for a fixed price, by a fixed deadline. The scope is fixed in terms of the value stories that you intend to fulfill, and no promises are made about user stories.

In other words, you promise to deliver what matters, and avoid making promises about specific design decisions that are unrelated to the revenue/savings/etc. that the project is supposed to deliver.

Answer 6

I agree with Bruce to a certain degree. Though I am not too familiar with waterfall or RUP, and thus cannot comment on that.

What I read recently, and I thought was really well said, was that even in Agile we neglect planning. A thorough planning session once an iteration is great - no it's essential - but so is planning THROUGHOUT the iteration.

I work in the entertainment industry, where things are constantly changing. The team needs some degree of leniency / flexibility which will allow them to "re-plan" stories mid sprint in order to align with new goals or revised goals.

I love the idea of continuous planning, as too often developers will tell the product owner to go away when they're working on stories mid-sprint. This is excellent if your team works on stories which are still valid, and your product owner is just being a nuisance. But in some instances stories become redundant DURING the sprint, and it is imperative for the product owner to spot this, and for the team to re-align with changed goals / stories - isn't that what agile is about?