08/31/2015
in Methods
Agile Contracts
Table of Contents
Agile approaches and methodologies are being used more and more, because the benefits of using them can be huge, e.g. improved quality of products. But often an issue arises that makes adopting agile in companies difficult: the contract with the customer. Clients often prefer fixed prices and demand a fixed set of requirements which is totally in contrast with the principles of agile approaches. This prevents that the development team can take advantage of the full potential. Lately, the awareness for this issue rose and efforts for creating contracts that support agile working are undertaken. (see State of Agile Report 2015)
General
Each project has to deal with the “project triangle” that consists of budget, time and quality. Those general conditions are specified in the underlying contract of the project. Therefore a project is successful when the budget is met, the timetable is met and the quality is as agreed.
In traditional contracts the client and the supplier agree on the requirements (including the quality), a schedule and a budget. If changes to one of the aspects come up the contract needs to be changed or adjusted.
Agile approaches are based on the principle that the result of a project is unknown in the beginning. Over time and by evaluating intermediate results the final product takes shape. Therefore it is impossible to agree on a traditional contract which is based on fully known requirements. In truly agile projects not all 3 tips of the triangle may be fixed. For example you could agree on a fixed duration, a fixed price and a flexible scope.
If your client insists on a traditional contract but you want to use agile methods you can do so, of course. The downside of this situation is that you can’t use the full potential of your agile approach, because the customer is not as involved as true agile working requires. Another thing is that you can’t unleash the full potential because you are developing against a fixed budget, in a fixed time frame with a fixed set of requirements and the customer is not as involved as he would be in a real agile project. Therefore it is necessary to use contracts that are fitted for agile projects.
Agile Contracts
A few weeks ago there was a conference on agile contracts here in Germany where executives and consulting companies participated as well as freelance professionals and representatives from legal departments. Also there is an initiative on agile contracts that aims on collecting references to agile contracting to support organizations to change their contracting models, reduce risk and get more benefits out of adopting agile development.
Contract Concepts
Generally there are a few different concepts for agile contracts. See the table below for 3 examples.
| No Cure, No Pay | |
|---|---|
| Principle | If the client doesn't like what he was delivered, there is no fee and he don't get to keep the product.In this concept the supplier has an increased risk and the client has a smaller risk. Therefore the price is higher. |
| Pro |
|
| Con |
|
| Rolling Contracts | |
|---|---|
| Principle | Client and supplier put in place a framework for a series of short development mini-projects. The framework doesn't contain specific features and functions, but probably an overall goal. With each delivery the client pays the supplier and has the choice to continue or to stop. Also the client gets a "ToDo" list.In this concept functions and features are not part of the contract. |
| Pro |
|
| Con |
|
| Money for Nothing, Change for Fee | |
|---|---|
| Principle | This concept maintains a big contract, just like traditional contracts. A difference is that the contract clearly states that the supplier works on the highest priorities first. The client can add new requirements which will be implemented depending on their priority.The client is allowed to cancel the remaining work at any time and keep what has been created so far. For this privilege he has to pay 20% of the outstanding work. Example: 12 month contract for 12m €. Client cancels after 6 months. Client has to pay 6m € for the delivered product and 1.2m € for the outstanding work. |
| Pro |
|
| Con |
|
Contract Essentials
Of course you can combine parts of the three concepts or you can add them to other types of contracts. Whatever kind of contract you choose for an agile project, it should consider these 2 essential elements:
- The contract should embody the iterative nature of agile working: do a bit, show a bit, do a bit more.
- It should also contain incentives for the client to stay motivated to get involved in the project.
If these requirements are met in a contract it is a good foundation for a successful project, because many studies have shown that especially customer involvement is a key factor in ensuring the success in a project. Working increments of a product and contractual incentives are a good combination.
Conclusion
Even if companies and their representatives have heard about agile approaches and know their principles they often want to benefit from using them, but they also want to stick to traditional contracts. They want to know exactly what they will get in the end or something better, even though they don’t really know what they want. This sets many suppliers in a difficult situation, because they also want to work agile. But this does’t go together with a traditional contract. If you manage to incorporate the essentials into a contract, even if only partly, it is a good basis for a successful agile project.
