Using Scrum in fix-length/fix-priced projects?

Question

I'm a Scrum newbie and looking to implement Scrum in my company. Obtaining buy-in is not a problem, it is my company and the developers are more than happy to work like this.

The problem is that 75% of our revenue is derived from fixed length/fixed price projects.

Ken Schwaber in his book, Agile Project Management with Scrum, covers the topic of bidding on fixed length/fixed price projects in an appendix at the end of the book.

After much soul searching, Ken derived that Scrum is only useful in this situation when you can convince the potential client to think differently. The client would have to be okay with a lot of uncertainty (about the final cost and the final delivery date) in return for getting something much sooner that may be usuable and the possibility of not having to implement every feature could save them money.

I'm not convinced that this is the only way to implement Scrum in fix length/fix price projects.

I want to know how others have successfully bid on and profitted from fix length/fix price projects.

Answer 1

I'm not sure about the bidding and profits but the scrum methodology can certainly be applied to a fixed-length/price project. If the requirements are known and solid they can be put in the product backlog and the sprints can be planned according to the requirements and the time limit. You can still leverage the benefits of the daily scrum meetings, burn-down charts, etc to make sure the project stays on track.

Answer 2

Yes. I think you can. See The Waterfall's Not Working.

The "getting outside the fixed-price box" isn't that hard a conversation to have. Customers have seen failures also. They've seen the long delays getting to a requirements document. They've seen the endless change orders. They don't like it either.

But, if you're convinced that the customer's doesn't want to manage things differently, you have to take a hybrid approach.

Making up a price isn't Agile -- it can't be. You must, for purposes of placating intransigent customers, make up a price. Clearly, you'll have some kind of master plan here to justify the price. Mostly, all you want from this master plan is the backlog. Other details are nothing more than hypothetical planning assumptions. [They're always planning assumptions, but some PM's think the initial plan is a divine oracle which must be followed. It's not.]

Then, you execute in small, Agile, incremental steps. You have to engage the users early and often, and you have to let the conversations happen. But! Each change in the backlog has to be examined as a potential change in scope, cost or schedule.

At the end of every sprint, any backlog changes will potentially be project scope and contract changes.

Agile reduces your risks because you're actively working the scope changes earlier and more productively with the customer. Trying to define (and freeze) scope isn't a value-add activity, so just stop doing it. Treat scope as the guess it is, and work the scope changes at each sprint.