28.1 Traditional contracts
In simple terms a typical contract (sometimes referred to as a ‘traditional’ contract) would involve the customer engaging the supplier to deliver a specific solution or output that is defined by a set of specific requirements. These requirements would usually be several in number and may be quite detailed. Along with this there would usually be a deadline and a price.
Projects are difficult and face uncertainty; therefore the detailed requirements are likely to change over the course of the project, as well as the understanding of how long the work will take.
The principal issue with the traditional structure of a contract is that the requirements and the understanding of the work involved will inevitably change over time, and someone will need to pay for that change, or at least factor this into the contract in the form of a contingency (e.g. the supplier adds 20 per cent to the price).
In an agile context this structure is counter-productive because agile is ‘change friendly’ and works on the basis that modifications will inevitably happen; it is not necessarily a negative situation if changes ultimately result in something that is more closely aligned with the customer’s real needs and potentially delivers more value than originally intended.
In an agile context the customer and the supplier need to work together to optimize the solution in order to achieve the best possible outcome in terms of value to the customer. Focusing the contract on the solution is less likely to produce this effect.