Mission Control

Long story

The “Fixed Price in Agile Projects” tale is long enough. There are multiple views, which all dance around unbinding Price/Time-Scope-Quality triangle as agile projects are much less predictable in conventional sense (“conventional” meaning delivery of the predefined scope within predefined period time, whereas agile approach sets another convention – deliver what is really needed).

Martin Fowler has the simple answer – don’t fix the scope, but you may fix the price, time and quality. It is because of the fixed scope mirage and scope limbering which happen all the time.

Greg Young is discussing the issue at different angle: legal commitments cannot just end up being “we will do our best” statement in most corporate cultures. And even such legal conclusion is confrontational and opens both customer and delivery company up for legal fun, should issues arise. Therefore, the advice is not to go agile on fixed price (and for sure have clear “completion” criteria in place on paper).

And even though some still reasonably advocate that agile is about being efficient, and, therefore, it still makes lots of sense to be agile on fixed price contracts – there seems to be no silver bullet on Fixed Price vs Agile.

I for one have put my thumb up on all the reasons provided. Yet still live forces to come up with the solution on how to tackle this challenge.

Short

Well, we have tried one approach in a number of projects and it seems to be working great for both client and delivery company. And does not at all unbinds Price-Scope-Quality triangle. It keeps it. Yet it is agile (more accurately – Scrum).

My answer is – shorter commitment periods:

• We still would have fixed price per sprint. As sprint is fixed time-boxed anyway, it is comfortable for delivery company. Maximum sprint length is 1 month…
• We would have the Must Haves, Could Haves, Nice to Haves within the sprint backlog. We legally would agree to Must Haves delivery. As Scrum team commits anyway – it is natural for them. Yet it makes customer more comfortable to commit financially. If Must Haves are not finished within sprint, it is still the responsibility of the delivery company – but as the time commitments are shortened, the risk is not as huge at all. And the further we go with development, the better we work together with the client
• We would still have regular demos to set up the expectations and to discuss our common approach on vague requirements definition when it starts to come together.

This approach makes us achieve one of our major objectives – collaborate together with the client, not just work for them. Well, it means – better products are built and stronger relations are created.