Can Scrum play a key role in fixed price projects achieving their target?

This question came up on the Scrum Development List yesterday. Here’s my take on it:

> Can Scrum play a key role in fixed price projects achieving their target?

Absolutely! In fact, the more I think about it, the more I think Scrum is the best way to take on a fixed price project.

The process starts in pre-sales so that you set the expectations with the customer and leave yourself some maneuvering room to even out the risks of various pieces of the project. Some things will go quicker, others slower. You need to make sure that even if some things turn against you, the project as a whole stays within bounds.

Ron Jeffries will probably point out at this point that you need to add good engineering to your sound management practices. An he will be right. So you need good engineers working on your project. If they’ve been working together for a while, been working on a similar project, or been working with Scrum before, you improve the odds in your favor. If they were involved in the sales process, that’s even better.

Basically you strive to deliver Running Tested Features every sprint (and this implies a fair amount of automation in your quality assurance). Every Sprint you deliver functionality to the customer. And you give him his most important features first. Add in some sensible buffers (Must Have / Should Have / Nice to Have) on the feature side and/or some air the schedule side for risk management, and you have the basis for delivering what the customer needs when he needs at.

Why is Scrum better than a waterfall? Scrum delivers functionality at least every month. Tested and Done. Think constant positive velocity. Waterfall has long periods of zero velocity (initial planning phases) and zero or even negative velocity (periods of testing in which the team and customer discover that significant pieces of functionality don’t work properly or otherwise do not satisfy customer requirements). Highly variable velocity is a significant risk, because you cannot really predict when the product will be ready.

Having said all that, I’m not sure I’d recommend fix price contracts if you can avoid them. Last week, I published on ASD an analysis of the suitability of various contracting forms  for agile development. I think there are better alternatives for both vendor and customer.