How to Apply Contracts Effectively to Agile Projects

One of the four basic values of the Agile Manifesto is: Customer collaboration over contract negotiation. This could indicate that contracts are no longer of great importance in agile projects. Is this actually true? In order to have legal certainty and a guideline for development, contracts are also indispensable in agile projects—it’s just that they often differ in structure and handling from those in “normal” projects. This article gives you an overview of the characteristics of agile contracts and explains the different types of contracts, their purpose and their application.

Agile Contracts Need More Flexibility

In this article, you learned about the four core values of the agile manifesto. One of them is: Customer collaboration over contract negotiation. This might suggest that contracts no longer have much value in agile projects. Is this actually true?

Many interpret agile development simplified like this: The customer defines a budget and then the contractor develops as many functionalities until the budget is used up. We adapt the delivery of software components to the changing customer wishes and environment and are sure that the customer receives what he imagined or needs at the end—perhaps even with some documentation. But it’s not that easy with agile projects either!

We develop until the budget is used up—really?

In traditional software development (e.g. according to the waterfall model), the requirements are largely known at the start of the project, which makes it easier to calculate costs and deadlines. With agile projects, on the other hand, the requirements at the beginning of the project are often only partially known and they can change at any time during project execution. But even with agile projects, the customer wants to know what his project costs and what he gets for his money. This of course makes the drafting of contracts a lot more demanding.

Contracts for agile projects should therefore offer more flexibility and also take into account the circumstances of still unknown and changing requirements.

Contracts that are suitable for traditional projects do not automatically make sense for agile projects. In the following sections, I will give you a brief insight into the contract design for agile software development. First, I will show you what purpose contracts fulfill and which types of contracts you can use and how they are tailored to the type of development.

The Purpose of Contracts

Contracts define legally valid agreements between the customer and the contractor and are intended to record and make verifiable what the parties have agreed with each other. They are intended to create legal certainty for the contracting parties with regard to their mutual rights and obligations. This also implicitly or explicitly regulates who bears which risks. If one of the parties deviates from these agreements, the other party can sue for compliance with the agreement, refuse payments or insist on damages.

In agile projects, customers pursue the following objectives with contracts:

• Setting a roadmap
• Minimize risks
• have legal certainty

Contracts in business and private life are there to get along and this is also the case in project business and agile projects. Contracts don’t have to be books, but without contracts you don’t have legal certainty and so uncertainties and dissatisfaction can arise.

Contracts are there to get along.

The Requirements Are Only Partly Known at Project Start

Before a traditional project starts, the customer analyzes his needs and creates the product requirements specification with the requirements for the software to be developed on this basis. This also often serves to find the cheapest or most suitable supplier in tenders.

On the basis of the product requirements specification, the contractor creates the functional specification which describes how he will implement the requirements. After the requirement specification has been released by the customer, the contractor begins with the implementation. The result is accepted by the customer if it fulfills the requirements from the specification. With agile projects, this looks somewhat different.

Agile Development addresses complex problems that by definition cannot be fully analyzed and specified in advance. The participants often only recognize in the course of the project how certain parts/functions of the software are to be designed in order to achieve the hoped-for business benefit. It is also possible that the needs of the customer or the business environment change in such a way that new requirements are required, requirements have to be changed or no longer apply—and this is exactly what agile development is used for.

Contracts should actually clearly define something that has been agreed upon and that has to be adhered to later and thus provide security. For agile projects, however, a contract must make it possible to develop software functions that are only partially known when the contract is signed, are still unknown or change during project execution. This makes contract design much more demanding.

Agile contracts need more flexibility.

The Agile Contract View

For purely economic reasons one should not invest much effort in the detailed description of functions, which one needs later differently or not at all. If functions are described in the contract, they should be roughly granular or only exemplary.

When drawing up a contract, you should consider the following three basic agile ideas:

• Incomplete functional description: At the beginning of the project, we do not yet know completely what the software must look like in order to provide the hoped-for benefit.
• Common understanding: We create a common understanding through discussions and not through documents.
• Collaborative problem solving: We respond to problems with greater proximity and close cooperation.

The less functionality is defined in the contract, the easier it is to adapt to changing and new requirements, but also the greater the cost and deadline risks and the risks of legal disputes.

The agile approach influences contract design, where you need to consider various criteria. For example, the type of contract itself is important. In the next section, you will get to know the fixed price contract, time & material contract and benefit-oriented contract types.

You must also mention the agile development method to be used in the contract (e.g. Scrum). A reference to the Scrum Guide as the official Scrum definition is sufficient.

Fixed Price or Time & Material Contract

Fixed price or time & material contracts are common in software development. Fixed price means: The customer pays a fixed price for a clearly defined project scope. Time & Material means: The customer regularly pays for the work performed according to a previously agreed daily rate.

With a fixed-price contract, you can change the previously defined scope of functions only with great effort. With Time & Material you will usually roughly sketch the scope of functions for agile projects in advance, but you will not necessarily fix it contractually. This gives the customer maximum flexibility and allows him to learn during the project how the software has to be designed, but he has most of the risks on his side.

A contract (for specific) work does not necessarily require a fixed price contract. Payment can also be made via Time & Material. Whether it is a contract for work, or a service contract does not primarily depend on the payment, but on the mutual rights and obligations that are laid down in the contract. Benefit-oriented contracts are another type of contract.

Time & material and fixed price are cost-oriented contracts. They only deal with costs. Benefit-oriented contracts bind the payment to the generated benefit, are more flexible, and actually fit better to the agile way of thinking than cost-oriented contracts.

More Trust Means Less Contract

How complete or extensive a contract must be depends to a large extent on the relationship of trust between the customer and the contractor. Have you ever worked with this contractor?  Do you have the confidence that the respective contractor is prepared to find a cooperative solution to problems?

Fixed Price Contracts for Agile Projects

With fixed-price contracts, the customer normally tries to obtain the most extensive and high-quality scope of supply possible for the least possible amount of money. The contractor, on the other hand, tries to fulfill his contractual obligations with as little effort as possible. This means that the interests are opposed, which can lead to conflicts.

Therefore, one could think that Time & Material contracts fit better to agile development. This is true, but Time & Material contracts are not without problems either. If, for example, the developers provided by the contractor do not behave as desired by the customer. The customer expects from an agile development team e.g.:

• that it is involved in the software design so that the product creates the hoped-for benefit,
• that it removes impediments itself and
• that it improves collaboration and processes through retrospectives and thus gradually becomes more effective.

Change for free

The “Change for free” concept is mainly used for fixed-price contracts in order to allow changes to flow in during contract execution. This concept defines the following rules:

1. Changes in the priority of features are “free” if the total contract value does not change.
2. New features can be added “free” to sprints before sprint start if features with low priority and the same effort are removed.

Benefit-Oriented Contracts

From an agile point of view, benefit-oriented contracts are interesting, since in agile development the customer and contractor work together on a product with the greatest possible business value, at the lowest possible cost. Benefit-oriented contracts are not yet so common in software development, but could gain more importance with agile development, because these types of contracts attach the benefit to the payment and therefore provide a greater incentive to optimize the benefit. For example, the following variants belong to the benefit-oriented contracts:

• Provisions & premiums
• Money for Nothing
• Profit sharing
• Pay per use

Provisions & Premiums

Provisions & premium contracts contain cost-oriented as well as benefit-oriented portions. This type of contract is inspired by Cost-Plus or Cost-plus-incentive fee (CPIF) contracts.

The customer pays a low daily rate according to expenditure, which covers the costs of the contractor but does not yield a profit. The contractor thus receives the provisions he needs to survive. If an agreed goal is achieved, the contractor receives a premium.

With a provisions & premium contract, the contractor wants to achieve the goal as quickly as possible with as little effort as possible. Then his profit is at its highest. But the customer is also interested in reaching the goal quickly so that he pays little for provisions and thus reduces his overall costs.

Provisions & premium contracts ensure that the interests of the customer and the contractor are aligned. This type of contract can be an intermediate step to move from cost-oriented to benefit-oriented contracts.

Determining the benefit is a challenge for all benefit-oriented contracts. The customer and the contractor must have a clear understanding of the benefits to be provided. The contractor must also already have good knowledge of the customer’s specialist area.

Money for Nothing

The “Money for Nothing” strategy is applied to fixed-price contracts. This agile contract allows the premature termination of the contract if, for example, the value of the features falls under a ROI criterion (Return-On-Investment). The contract allows the customer to save 80% of his remaining order value by paying the contractor 20% of the remaining order value in return (or as a premium), which can increase the margin of an agile contractor from e.g. 15-20% to 50-80%.

Profit Sharing Contracts

In profit sharing contracts, the contractor participates in the benefits generated by the software but does not receive any payment for its expenditure during development. This of course makes the contractor very interested in how he can best generate this benefit. The faster and the better the benefit is achieved, the greater is his turnover. For the client, on the other hand, the project risk decreases. In a profit-sharing project, the ROI (Return on Investment) can hardly become negative for the customer. Even with this type of contract, no detailed feature list or exact cost estimate is necessary for the contract. The risks here are largely on the side of the contractor.

“Pay per use” contracts are a special form of profit-sharing contracts. They do not pay for the direct benefit, but for the frequency with which certain functions are used. This type of contract is suitable for Software as a Service (SaaS), for example.

A Contract for Every Sprint or Release?

If the scope of a fixed price is very small, risks are also reduced. Agreeing a fixed price for each sprint (or release for short sprints) is less risky than, for example, a fixed price over 12 months. From my point of view, this strategy has many advantages and means little additional effort in contract administration.

At the fixed price per sprint, the project is carried out as a sequence of many small fixed price projects. The result of the Sprint planning is a separate fixed price contract. The acceptance then takes place in the sprint review.

This could look something like this:

• A contract to conduct a larger requirements workshop (also to get to know the contractor better). This can lead to a go/no-go with this contractor.
• A framework agreement that regulates the basic aspects of the collaboration in advance and an additional contract for the first two sprints.
• Additional contracts for additional sprints or short releases.

With this procedure, the customer knows what he will get for his money after each sprint. At the same time, he can react flexibly to new or changed requirements in every sprint. If the customer measures the velocity of the developers at each sprint, he also knows the approximate costs of each sprint and can make a forecast of the total project costs.

With this strategy, it also makes sense to conclude a fixed-price contract with a contractor for a pre-project phase with a requirements workshop. This can also be done with several potential contractors to evaluate one contractor.

Who Creates the Contract?

In larger companies, experts from the purchasing department often create project contracts. In my experience, however, these people are often overwhelmed with project contracts and especially with contracts for agile projects. Therefore, it makes sense for the product owner, who is preferably provided by the customer, to be familiar with agile contracts and be able to support the purchasing department accordingly.

Conclusion

Contracts are also important for agile projects. The drafting of the contract depends on the software to be created, the preparatory work already done and the scope already defined, but also on how the benefits of the software are to be incorporated into the drafting of the contract. Agile contracts need more or less freedom to adapt to changing conditions. This creates new possibilities. However, the risks that arise from this freedom in collaboration must be taken into account by the contracting parties.

Here You Can Find Even More Knowledge