As mentioned by Alexander Maisch in his article about the Nokia test, some Scrum-interested colleagues meet every 2 weeks for an open discussion. We call it “the scrum clinic”.
One frequent topic of discussion is how to use scrum in fixed-price projects.
Before giving specific advice, we’d like to express an opinion about fixed-price projects in general.
Fixed-price projects have become more and more popular during the last few years, especially in software development. In some areas, nowadays, they’re even prevalent. Why is that?
In our opinion, it has to do mostly with risk. When using fixed-price contracts, customers want the contractor to accept the project risks. So, a request for a fixed-price contract is always to some degree associated with the implied statement “we believe the project will fail anyway, so we should protect ourselves up front”. In contrast, an ideal software project should be based on a contract with hourly rates. This is a strong signal of trust in the contractor’s abilities, and so contributes to a climate of mutual trust, which is extremely valuable for making the project a success.
Unfortunately, reality stands in the way of such optimistic musings. Eventually, every organisation, whether or not it uses Scrum, has to deal with fixed-price projects. There are, however, a number of precautions one can take to cope with this situation.
With fixed-price projects, customers usually expect an “over-the-fence” type of approach (i.e. you throw some specification over the figurative fence and hope the expected product will be thrown back some time later, perhaps even on schedule).
Agile methods work very differently. They rely on constant collaboration between customer and contractor throughout the project lifecycle. To help bring these opposite approaches together, fixed-price contracts can be modified to provide a bit more agility.
Ken Schwaber (one of the “fathers” of Scrum) offers the following suggestions in his Scrum-FAQ:
- For any part of the requirements that the team hasn’t started working on yet, the customer is free to change them with anything of equal value.
- For any part of the requirements that the team hasn’t started working on yet, the customer is free to reprioritise them
- For any part of the work that has been delivered as increments already, the customer is free to ask the teams to implement them in addition to any call for implementations and they will be charged time and material to do so.
- Since the team has given the customer, as part of the proposal, the list of requirements of the project in a prioritised list by value, the customer can often see the system they want emerging and may feel satisfied before the entire set of requirements are developed. In this case they can cancel the contract at this point in time and take delivery of the system that is adequate to their needs and is only charged some penalty (such as 25% of unbilled revenues) to take care of any overhead that the team has absorbed by entering into the contract.
At first glance, these modifications seem insignificant. But in fact, they dramatically improve the customer’s situation.
Take, for example, the first one: By allowing the customer to replace a requirement with another one of the same value, even a brand-new one; you eliminate the current practice of having subsequent change requests. It also contributes in fighting today’s features overkill: Subsequent changes to a fixed-price project traditionally cost a lot of money. So customers’ requirements try to cover all eventualities, no matter how unlikely. As a result, many of today’s products have excessive functionality, most of it hardly ever used or outdated at the time of release.
But requirements are often still vague at project start, and are subject to (frequent) change. So SCRUM greatly improves the chances of developing what customer needs, even if the actual result may be something completely different from what the customer initially expected.
This is further supported by the customer’s possibility to cancel the project early. If the current result is good enough (or if the budget is cut), he can stop the project ahead of time and still get a useful result, without satisfying all initial requirements.
The third proposed modification allows the customer to roll the IT system out step-by-step (as opposed to a big-bang approach). This significantly reduces risk (consider all past failed projects) and also offers new and interesting perspectives. Introducing a new system step-by-step, economises on training, since users can gradually familiarise themselves with the system.
So much for theory. What’s the real-world situation? Very bad! Why?
Wait for the answer in the next article!
Loading ...