The way we developed software 15 years ago does not fit in the current digital world. This message seems to have already taken hold in the majority of Spanish companies, now it has to be Agile (in capital letters), this is the way to achieve success in the digital market.

Only it is not enough to understand this, the road ahead is complicated and, among other obstacles, traditional contracts do not help. The problem is already known: wanting to play one game with the rules of another one.

Many of the trends and practices called agile (lean, scrum, etc.) emphasize the importance of inspection and adaptation, of experimenting, measuring, observing and learning. Well, let's do the same with contracts, let's see how they can be adapted.

What else is there beyond closed contracts and those of time and materials?

A good starting point is to learn from experience, from one's own and from others'. For this we have compiled the main initiatives existent in terms of agile contracts, some of them, promoted by great figures in the agility and software development world.

Trusted sprints

It consists in offering a certain number of sprints to generate trust and establish a solid base of relationship with the client. In this way, it is intended to eliminate uncertainty and minimize risks so that the client has the necessary confidence not to resort to a closed contract.

There is nothing quite like starting to work together to make better plans based on reality and not on perception.

Not-to-exceed with fixed-fee (NTE / FF)

One of the main impediments that customers pose to open relationship models are budget limits. This measure tries to establish a minimum (fixed-fee) and a maximum (not-to-exceed) to protect both the supplier and the customer.

However, this approach presupposes a stable and predefined scope, which is not adjusted to the principle of adaptability.

Target cost

This model encourages the delivery of functional software in an iterative manner. To be able to apply it, you must agree on a history point, since these will have a cost associated with it. Another approach would be to associate cost per backlog item (if they are of comparable sizes).

The client will pay for the points delivered in each sprint iteratively. The advantages of this model are, on the one hand, that it does not limit the scope and leaves room for adaptation to change and, on the other hand, that the risk is shared between the client and the supplier.

The problem is that it implies consensus in the estimates, which can lead to internal wars if, again, there is no trust and there is fear over an opportunistic attitude of the other.

Bob Martin's idea

One of the signatories of the Agile Manifesto proposes, among others, a contract model for time and materials combining the price per hour and the price per history point.

It is necessary to have an approximate global estimate from an initial backlog. From there you get a total budget based on the price per hour you have established (for example: 5 sprints of 2 weeks, 4 people, € 50 / h = € 80k).

So far everything rings a bell, the idea now is to reduce the rate referring to time and cover the rest of the budget with the rate for history points.

• An average hourly rate is agreed that is much lower than the initial or market rate (for example € 15 / h instead of € 50 / h).
• A rate per history point is agreed to cover the total budget (80000-15 × 1600) / 1000 = € 56 / history point).

This way, on the one hand, the customer's risk of deviation due to extra costs is mitigated: if 1000 history points are finally delivered, but taking, for example, 14 weeks instead of 10, the project would cost € 89,600 (= 15x160x14 + 56 × 1000) ). Compared to a contract for time and materials, which would have cost € 112,000 (= 50x160x14), we see that the extra cost has been reduced from 40% to 12%.

On the other hand, the risk assumed by the supplier against changes in scope is increased and the motivation to finish earlier increases, since if it finally ends 1000 history points in 8 weeks, instead of 10, the project would cost € 70,400 (= 15x160x8) + 56 × 1000), with which its average rate goes up from € 50 / h to € 55 / h (10% more).

IDIQ (Indefinite Delivery, Indefinite Quantity)

Since it is not possible to determine exactly what is going to be delivered or the quantity (speed at which it will be delivered), an estimate is established at a very high level of demand and deadlines.

It really is similar to the NTE / FF method, in which a maximum and a minimum are defined, but with another approach. For example: we want at least 1000 points of functionality and deliveries between 4 weeks and 6 months.

Jonathan House's idea

Practically, his idea is based on adding a bonus for delivery on time and penalties for delays. It has the disadvantage that time estimates are made, most of the time, in a very initial phase where the uncertainty factor is very high.

On the other hand, we return to the problem of management of changes of scope, so that there are no delays and there are no penalties.

Venture-capital financing model

It mimics the behavior of a start-up. The sponsor gets an amount of money to reach some objectives and the supplier must deliver results to get more funding.

After each work period (between financing) the terms of the contract can be revised and the result of each period is something agreed upon between both parties.

It adapts well to the development with agile frameworks, since it is based on the delivery of software running iteratively and incrementally, allowing inspection and adaptation.

Jeff Sutherland's Clauses

One of Scrum's founders, Jeff Sutherland, proposes adding two clauses to closed contracts. These clauses are only applicable under certain conditions, mainly that all participants are fulfilling their responsibilities within the framework used and are involved.

Money for nothing:

The client can terminate the contract at the end of any sprint. The standard measure for the client to do this is when it is perceived that the cost of continuing to develop is greater than the value that will be contributed.

In this case, the customer will pay 20% of the remaining value agreed in the contract. The supplier, for his part, undertakes to deliver 80% of the scope of the project as high quality on the agreed delivery date. High quality is defined by the DoD (Definition of Done).

Change for free:

The customer can change the scope without incurring an additional cost. The new stories or items will replace others that were contemplated in the scope and that were comparable in terms of effort.

These clauses can lead to conflicts and internal wars about what is quality, how much is 80% or what / who considers that two items are comparable in effort, so beware of these as they divert our efforts to deliver value.

The most interesting and innovative aspect of Jeff's proposal is to include, in some way in the collaboration model, the importance that we are working well and fulfilling each one with our functions.

And this may be due, in part, to the fact that they fully trust that if these conditions are met, the involvement of both parties will favor an atmosphere of collaboration, trust and transparency, avoiding reaching this type of conflict.

Norwegian PS 2000 Agile Standard contract

There are countries where the challenge of formulating new models of relationship between customers and software suppliers is being taken very seriously.

In Norway, they have already dealt with the problem of the lack of adaptation of traditional contracts to new methods of developing digital products.

The Norwegian University of Science and Technology (NTNU) together with the leading industries in the sector and public administration have jointly developed an agile contract standard.

It is based on the iterative development model, close cooperation between the client and the supplier and procedures for resolving conflicts with an expert mediator.

It consists of 3 parts:

• About the client and the supplier.
• General provisions: rights and obligations of each party on the delivery of software.
• Specific agile annexes (version 3.1)

"Universal rules do not exist", Dave Thomas

It is indisputable that with trust and collaboration it is much easier (and less necessary) to define the relationship model with a client.

Jeff Patton, from whom we learned everything about the user story maps, even proposes to leave the contract closed but work a lot with the client every day in order to guarantee satisfaction:

"When we arrived at the due date, features were left unfinished. Strangely, no one wanted to talk much about those features. The customer was happy with the product and considered our contractual obligation as met. We complied with the schedule and let slip some of its scope." Jeff Patton,"Unfixing the fixed price contract" in Agile Development Conference 2003.

Let us explore, therefore, measures that promote these values ​​and not that dynamite them. For example, moving from rigid contracts towards more collaborative frameworks.

If we make sure that all the necessary functions are going to be covered and we guarantee the involvement of all the parties, we are not going to need to focus on "whose fault it will be" and what consequences there will be if something does not go well.

We must also guarantee absolute transparency. We cannot demand trust from our clients, if we are not transparent with our work afterwards. Luckily, there are many mechanisms to promote transparency, visual tools and metrics are some of our favorites.

The secret of the alliance

I’m sorry to say that we will not reveal the magic formula that solves all the problems that traditional contracts bring us. Have we not learned the lesson yet?

In the digital world, change is constant and the key to success is our ability to adapt. Each situation, each product, each client, and each business is different.