Agile software development – agile contract?

Agile software development has been a popular presentation topic in software industry seminars in recent years. Agile software development refers to a model in which the project is not started by establishing a detailed and exact description of the outcome, but rather focuses on delivering software that adequately meets customer requirements through interactive collaboration between the customer and the supplier.

If the agile method has been selected for implementing the project, this should also be reflected in the contract between the supplier and the customer. Trying to implement an agile software project using traditional ‘waterfall’ contracts is a doomed idea.

The reason why I rarely run into a good agile contract can be found in the traditional perceived importance of contracts among lawyers. A ‘good’ lawyer’s primary objective is to safeguard his/her client’s interests in the best possible way and in all possible situations. As the old saying goes, “the best contract is one in which neither party is satisfied”. This is not a win-win mentality.

In settlement negotiations, a lawyer will traditionally seek to ensure that his/her client receives the exact agreed outcome, within the agreed time and at an agreed price. If this does not happen, a lawyer will ensure that the supplier pays damages to the customer. Due to these reasons, a disproportionate amount of time is spent on negotiations, rather than on figuring out how the customer receives the most appropriate product or service for their requirements and for the estimated cost, and on ensuring that the customer is able to affect the end result as the project progresses and understands the impact of changes on the timetable and cost.

In an agile project, it is not possible to determine any of the traditional ‘cornerstones’ (e.g., outcome, cost, schedule) in the way lawyers would like to. At the beginning of the project, there is no clearly defined product or feature list, costs can only be given as targets or estimates, and the timetable will depend on the progress of the project as agreed by both the supplier and the customer. Truth be told, these cornerstones are not clear even in traditional software projects, the parties just believe that this is the case. Instead, in an agile project, the parties accept a degree of uncertainty about the timetable, costs and outcome, and focus more on project management and on achieving a functional result.

An agile project contract should support the implementation of the project and the interaction between the parties, rather than focus on how to guarantee maximum protection of the client’s interests and minimise risks. In a traditional software project, the customer’s risk is increased by the fact that the final result can only be evaluated once the whole project has been delivered. It may only then be realised that the end result is not at all what the goal was, the project overran the deadline, and the costs doubled. In contrast, in an agile software project, the project can be stopped after each iteration. As each iteration normally lasts only a few weeks, the risk of customer losses or project delay is very small and contract negotiations do not have to focus on negotiating liability issues, at least not to the extent as in traditional projects.

So why don’t fixed-price and time-and-materials contract models work in agile software development? The problem with fixed-price projects is that if the price is determined in advance, the supplier will also want to determine the subject of contract. In an agile project, the subject of the contract cannot be determined in advance, because it evolves during the project. The problem with contracts that are based purely on time spent to perform the work is that only the customer has the right to control progress of the project, without being obligated to interactively collaborate with and provide feedback to the supplier as the project progresses. One of the main principles of agile software delivery is the close collaboration between the supplier and the customer during the project.

A good agile contract can be a combination of fixed-price and time-and-materials contracts in that the basic ideas of agile development can also be recorded into the contract. The project can be started using the time-and-materials model, and after reaching a certain stage, it can be changed to a fixed-price or target-price model. Thus, the risks of both parties are reduced: the supplier will be able to better assess the true cost and the customer their own requirements as well as costs. A real win-win situation.