Why no fixed contracts in Agile

April 1, 2008 by Artem Marchenko

While it is possible to utilize fixed price, fixed scope contracts with the agile methods, fixed contracts are still discouraged in preference of time & materials or Pay per Use. The reasons is that in most if not all cases software development is not a mass production, but a new product development. It is rarely possible to just clone the existing system for a new client. At best, when implementing tunings for a new client, we can try copying the existing approach or best practices. Therefore in order to build something that is not known to the last bit in advance we have to unfix at least one angle of the quality triangle.

Uncertainties

Agile software development methods are based on the assumption that any amount of upfront planning cannot predict the surprises on the way. There are always some unpredictable in advance technology limits, requirements can rarely be described on paper in such a way that both customer and developer can understand them in a same way. Even if we happen know the technology perfectly and the client is able to express his wishes extremely clearly, there is always a possibility for the rapid and unpredicted market changes. Think iPod or iPhone and how they changed the requirements for any phone or MP3 player software on the market. Agile methods acknowledge the market and project uncertainties and try to adapt by building software in small and completely done increments, so that the business could change the project direction up to the point of efficiently killing the projects at pretty much any moment. Naturally this approach is not very compatible with the idea of fixing everything upfront.

It is still possible to realize the benefits of agility with the fixed price/scope contracts. It is still possible to have quite an extensive planning phase, though agile methods recommend devoting it to prototyping more, than to thoroughly documented analysis. Nevertheless, for agile teams it is more effective to work with a not fixed or at least phase-based contracts. Naturally it requires some level of trust between the client and the implementor. However, some trust is anyway needed when working in an area, where it difficult to specify in advance, what is really needed. Fixed price/scope contracts might be able to protect a client from paying too much, but they are unlikely to help him get a system he really needs.

Links

• Agile Contracts - Alistair Cockburn summarizes ideas people have for contracts on agile projects
• Fixed-Price Contracts in an Agile Organization - Darren Norton constructs a virtual discussion from several readers and authors questions and opinions. Links to more materials included
• Time is Money - Agile Fixed Price - Valtech's CTO on that even on a fixed cost projects agile methods offer the most risk-averse method of delivering business-centric software
• Fixed Price Contracts - Agile Kiwi advocating the use of agile processes on the fixed price contracts

Permalink