Agile Contracting needs a new evaluation standard 

Ever since the Agile transformation as part of the digital transformation is in full swing, the focus has shifted to contracts with external suppliers.

As with the waterfall implementation methodology, traditional fixed-price work contracts and time-and-material service contracts (T&M) are increasingly coming under pressure and are going out of style.

The reasons for this are obvious. Fixed-price work contracts leave the risk exclusively on the supplier side, while T&M service contracts do exactly the opposite. They shift the entire risk onto the client’s side.

Since software is becoming more and more complex, time-to-market requirements are becoming tougher, and good specifications are simply no longer possible, projects involve too great a risk for both sides so that contracts based on fixed prices or T&M can’t still be concluded reliably and satisfactorily for everyone.

Even if both parties enter the race with great intentions and mutual promises and trust, the disappointment that soon follows is usually accompanied by even greater disillusionment, which often causes business relationships to suffer greatly.

In Germany, the special AÜG situation was added in 2017, which puts a significant strain on the whole situation or requires an even faster solution, as the T&M variant is practically not available for long-term projects.

Basically, almost all companies are affected by this problem. Some just don’t know yet. But the number of Agile projects is likely to reach 80 percent soon, with an upward trend.

If a software that is to be implemented is not detailed and well described, there are always problems. Doing without a complete and detailed specification is certainly the biggest compromise that can be made in software development or that must be made today.

Agile development has been going on for some time now and all parties involved have had bad experiences with their fixed price or T&M contracts.

The time is now to tackle this problem in spite of all the objective difficulties.

We are already seeing the first approaches

Cut T&M contracts, indicative fixed prices, and contracts based on Story Points are some of these approaches. All of them are not without problems. But they all aim to spread the risk fairly evenly between the two parties.

What they all lack somehow, however, and what makes the matter somewhat unsatisfactory, is that they don’t have an objective standard of assessment.

Story points, for example, are not well suited because they are relative and individual. In addition, the question of how technical backlog items (enabler Stories, spikes, tasks) or bug fixings are rated, etc., is also important. Nevertheless, they can at least be expressed in numbers and are part of the Agile methodology.

There used to be a measure that was objective and absolute, the Function Points. They were first developed by IBM in the 1970s. They express what we want: an independent measure of the functional size of a software without reference to specific functionality (features).

In short, I could order 5 kilograms (Function Points) of software from a supplier and only start to consider the concrete features in the course of development.

This is a somewhat abbreviated representation, but in principle it works like that. And that has been the case since the 1970s, which is exactly where their problem lies. If they haven’t become popular in the past 50 years, they probably won’t ever be.

One of the reasons for this is probably that the survey – even if it is not particularly complicated – appears too complex for most people.

We need a measure and/or a procedure that does not contradict the Agile methodology, i.e. it must be as simple, transparent and almost unconditionally applicable as possible.

For this, however, we will have to be prepared to accept a few compromises. We can hardly expect a one hundred percent solution which may not even be necessary.

We need a solution that is acceptable to both sides because of the characteristics mentioned above, because it reflects the interests of both parties.

What we would like to see is something like “Agile Function Points” and a procedure that is able to collect them in a sufficiently precise, reasonably objective, but above all simple way.

Agile Function Points in Use

Such a procedure could have the formula described below. Let’s first have another look at the Story Points.

Story Points

With all of their disadvantages, they have the added benefit of already being part of the Agile methodology. Even though they are often misunderstood and misused, a certain amount of practice in their handling can be assumed.

Story points represent the complexity of a Story in relation to its effort. Strictly speaking, they are neither complexity nor effort, but something in between – which explains why many people misunderstand them.

Their purpose is not to make an estimate of a commitment, but rather to show a trend of improving (velocity).

So they (team) are individual and relative and use the Fibonacci sequence, which was invented to describe growth populations mathematically.  In any case, they are relatively easy to estimate.

SAFe is now slightly bothered by team individuality and therefore suggests so-called “normalized Story Points” in scaled environments. This is an interesting approach that would certainly be helpful for our purpose, as it would bring a little more objectivity into all this.

Functionpoints

Function points are almost the opposite. They objectively and absolutely determine the functional size of a software. Originally they were invented by IBM to support make-or-buy-decisions. However, they have nothing to do with effort and are largely unknown in the Agile world. Presumably, they were too far ahead of their time, because in today’s Agile development world they would help to solve many problems.

In any case, Function Points, as the name implies, focus on the functionality of a software – strictly speaking, on the functional size of a feature. This comes very close to the Agile approach, which introduces an effective and therefore feature-oriented development, true to the motto of the Agile manifesto: business value first.

If we use both in a certain way, then the path to “Agile Function Points” may not be that far. We naturally focus more on the underlying idea and do not simply mix the two worlds. We want to extract the advantages, not accept the disadvantages.

We only extract the advantages of the concepts as far as possible. And we concentrate on the actual goal: to find a fair compromise between client and contractor in the design of an Agile contract in a simple, transparent and Agile way. Simplicity is a decisive factor here. Complicated procedures never prevail.

We see Story Points as a measure of effort – very abstract and simplified, but not completely wrong. This is not very precise, not very correct, but acceptable in principle.

In the same way, Function Points stand for the benefit. According to the motto: a great deal of functionality, a great deal of benefit. Also not quite correct and in the awareness that feature creep poses a risk here.

Nevertheless, both factors describe effort and benefit to a certain extent. Now we still need a simple way to bring both into one size, to create Agile Function Points.

Agile Function Points

We group Stories into three groups. Later, we will estimate Story Points for these groups to describe their functional character; and we will give each group a multiplier value.

Enabler Story & Spikes: these are Product Backlog Items (PBI) that handle technical debts or are enablers or actual necessary technical refactorings. These should not occur that often in Scrum, but they cannot be avoided in practice. Because we don’t love them, they get a factor of 0.5. The decreasing effect of this factor also has a psychological component.

User Story: These are PBIs that change or extend existing functionality. We give such Stories a factor of 1.0.

Highly functional Story: These are the Stories that clients prefer. They are user Stories that implement new functionality, especially core functionality. They receive a factor of 1.5.

Despite all the grey areas that may exist between the different groups, I will limit myself to only three groups here. Remember, the process must be extremely simple, and that’s absolutely worth the compromise.

Now, if we multiply the estimated Story Points by the functional factor, we are giving it a functional weighting.

In this way, we ensure that both the client and the contractor have an equally high interest in adding core functionality to the product as quickly as possible, without completely ignoring technical architectures.

SAFe uses so-called value points, which are expressed in Fibonacci numbers and are also determined relative to other backlog items, especially for features and epics in preparation for PI planning. The goal is to support the WSJF (weighted shortest job first) prioritization methodology. It remains to be seen if this method will be given a chance by the market and if it will gain popularity. The decisive factors will be how easy it is to handle, how easy it is for the actors (business owners, stakeholders, etc.) to understand and, of course, whether it is suitable for contracts.

Agile Contracting

Now the time has come to describe the procedure with all the ingredients of how an Agile contract is created. Here we bring together many of the approaches mentioned above.

This is how you set up an Agile Contract:

1. Short T&M phase A project starts with a short T&M phase, in which the first Stories are estimated and implemented.
    
   This will set the first benchmarks for Story Points and the service provider will see how much effort is required to implement Stories of this complexity.
   
   Read more about how to calculate the Scrum velocity.
2. Assign Agile Function Points to Stories In the next step, the Stories are assigned “Agile Function Points” and a price is determined that represents both effort and functionality (or “punishes” the absence of these).
3. Indicate fixed price or agree on a contingent of ‘Agile Function Points’ From this, either an indicative fixed price can be extrapolated or both parties agree on a contingent of “Agile Function Points”, since these now have a price.
    
   It is now in the supplier’s interest to increase the team’ speed and to choose an architecture that is robust and flexible enough to have as little architecture refactoring as possible, and which will allow adding functionality with little effort in the future. The more feature-rich the Stories, the higher the compensation for the service provider.
    
   Fortunately, the client has the same interest. This is the great potential of this process.

The Story Points also act as a good corrective here, as the number of Story Points does not increase if the technical architecture is messed up and the nominal expenditure for new implementations continues to rise.

The relative effort – and this is what Story Points stand for – does not increase, because Story Points represent the complexity of a Story in relation to the effort compared to a reference Story.

Of course, it is also clear that things such as “Definition of Done” and “Definition of Ready” in Agile contracts have to be more than just unread contract attachments or pretty Confluence pages.

This approach may or may not clarify all questions. The concept of Agile Function Points will certainly require further development. We are still at the beginning of a journey into full agility. But time is of the essence and today we need an approach that we can work with and that we can expect from our contractual partners.