Dominique Stender Good software is only the beginning…

Scrum and fixed price contracts

I'd like to draw your attention to a discussion that was in the Scrum Development group on Yahoo titled Scrum and fixed price contracts.

Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.

The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.

Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.

Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?

I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.

But let's muse a bit on that thought. What good is a disappointed door opener client?

What I often see happening in fixed price contracts is that the agency over promises (too many features for too little money/time). With that being the base line the developer team is forced to deliver more functionality per day than they can deliver in good quality. Due to time restrictions, development becomes sloppy. Bugs creep in, further delaying the progress. In the end the developers are exhausted, the project manager has a hard time convincing the client that 'everything is still going really well' and the client senses that something is off. In the end he is presented a system that is riddled with bugs and sub-standard usability, and with reduced or missing features.

What happens next is usually a free-of-charge bug fixing period. In the meanwhile new requirements come in, which again tend to be priced below what the actual effort is. To make the client happy, after the initial disappointment. This vicious cycle repeats.

So in the end, don't we have a project in debt and an unhappy client? Did the agency really impress that client? Will he play the door opener role that management had hoped for?

So what might be the solution to that? What role might Scrum play?

Well I think the solution is trust. If the client is convinced that you're not stealing from him he probable is willing to agree to a more flexible approach.

So deliver early, deliver often. The sooner the client sees what you are doing, the earlier he will trust you.

Make sure that the client understands the MoSCoW method and that his feature list has a lot of 'should' and 'could' items. Deliver the most important features - those with the highest business value for him - first.

That way, even if progress gets delayed, the most important features will be done, and in perfect quality.

Ensure that the client spends a significant amount of time checking the interim states on the staging environment. You will need his feedback early. As Pete Deemer explains it, bugs are like tigers: At first they're little cute babies but if left unattended they become man eaters hiding in a thick jungle, waiting for the kill. So better to take care of them early on, and don't let them enter the thick undergrowth of your project where they will hide and grow.

I believe to some extend this picture applies for features in general: Only the client knows what he really wants. So the sooner you show him a working part of what you think he wants, the faster he can correct you, while the gap is still small and easy to bridge.

Bottom line

Being honest with the client is not the easiest approach. He might be irritated when two people from the same company (Sales, Project Manager/ScrumMaster/...) tell him two different things.

Management in your own company may not approve this seemingly radical paradigm change. Make sure you introduce it gradually.

Not all clients may be willing to work in an agile way.

So there is no silver bullet. There is no single solution that works every single time.

But I'm convinced that with open communication (think: full disclosure) and early delivery, Scrum can do a lot in damage control. Fixed price contract or not.

Related Posts:

• Pen & paper Scrum – 10 days edition
• Scrum with pen & paper
• Ken Schwaber’s “Confusion about Scrum”
• Attempting Scrum in a SDLC environment, pt. 2
• Responsibility vs. Freedom of Decision