What is the Difference of Agile Contracts and Traditional Contracts

Are agile projects best supported by agile contracts? How does agile contracts deviate from traditional contracts? And does it make a difference what you use?

Keep reading and get enlightened on differences and implications of applying agile contracts for agile projects. And here you can get a short introduction to what agile projects are.

Why do we need agile contracts

In the complex world we operate in, projects are often solved by highly skilled suppliers – which is desirable in terms of competencies and cost efficiency. In larger organisations, this often implies a need for a procurement administration and comparisons of potential suppliers, where (as a minimum) expected cost and delivery date are the easily quantifiable parameters compared. Concurrently we see that modification of solution at no extra charge, the option to abandon the project when 60-80% of the value has been realised and only pay for actual cost spending, only rarely are part of the comparison, although this may heavily impact the actual cost.

But this is possible with agile contracts.

Does it matter if we use agile contracts or traditional contracts

The execution of the work is fundamentally different depending on whether it is based on an agile contract or traditionally (also known as the waterfall method). When executing traditionally, the work assignment and conditions are fully described ahead of start, based on the project managers iron triangle; scope, price and quality.

In an agile project you work towards a goal, and the means to reach the goal is agreed on an ongoing basis. In reality this means, that the level og quality is agreed ahead and continuously verified, while scope is added to match the customers needs. The cost is accrued cost (time and material), typically within a predefined range. As an example, a customer may demand a number of development teams consisting of a fixed group of people, whereby the monthly and yearly rates are known.

Traditional contracts

In a traditional contract the basis of the contract is WHAT is to be delivered, WHEN it is to be delivered, and total COST for the project. All of this is very convenient as a requisitioner, but perhaps attention should be focused on the incentive handed over to the supplier to identify any inaccuracies or missing elements – not to mention larger missing parts. Every time a supplier identify an inaccurate description, the reward is that it may be charged. Or if you as requisitioner grow more knowledge in the process, and perhaps even revise your opinion, this will be charged extra and most likely combined with a delay.

The advantage is that cost, delivery date and scope are known at project start.

The downside is that cost, delivery date and scope typically deviate significantly from the expected, plus the additional extra resources spent on adjustments and change requests.

What does agile contracts cover

If your project is covered by agile contracts, you get continuous delivery of the most important features following a fixed cadence, eg release every 2 or 4 weeks. Thereby the customer will get a value add throughout the project, and not only at the end. The duration of agile contracts will often be flexible, eg minimum of XX months with an option to extend. The service the customer buys, is a number of development teams with known line-up, so that the quality level may be assessed ahead and compared to other potential suppliers. The customer continuously receives and accepts product increments from the supplier and may therefore continuously capitalise the investment.

Of course, there is a strong element of trust in the contract, but this is only added on top of the trust element from letting an external supplier to deliver a business critical system.

Since scope is determined on an ongoing basis, you as a customer always have a finger on the pulse on what the supplier work on. Further, the customer continuously has to accept the delivered, wherefore no surprises will line up.

The customer may at any point in time change the priorities or goal, irrespective of whether the change was caused by a strategic change, changed market or anything else.

The basis for the contract is WHO is doing the job, WHEN product increments are released (fixed cadence), and COST in terms of hourly rates and materials (classic T&M).

 

The clear advantage is that the solution is delivered on an ongoing basis, so the customer may start using it and get benefits from it earlier. The customer may at any time and at no extra cost change direction. The contract may be terminated by the customers desire and this will typically happen when the marginal value of another waiting project is higher than for this project. The project may start faster as all requirements do not need to be known, accepted and prioritised, first.

Progress reporting is with agile contracts about what actually has been delivered (working product increments), rather than assessments of what work is still to be done.

The downside is in the taking on of the first agile contract, where a different type of initialisation is to be done, further, the customer must on an ongoing basis prioritise and present requirements and follow the development, which for some is very different.

How can the trust to the agile supplier be created

In addition to the classic tools of references and economic key figures there are other elements in the assessment of an agile supplier.

• The ability to work as an agile team – both internally at the supplier, but at least as important, the collaboration with the customer
• Development speed eg. the Lead Time, the time elapsed from requirement emerges to the solution element is in production
• Number of errors in the production system, in relation to the amount of solutions delivered

If you know the supplier from earlier, it is a big advantage, as you already know the norm of quality the deliver.

If we consider a new potential supplier, an option is to validate them in the specific setup. As an example, the supplier may be invited to an agile trial where they have to both; deliver a solution to a specific assignment, from their own development system to your production system; and the supplier will at the same time be evaluated on their ability to collaborate internally and collaborate with you. In practise, you ask for a 1-2 day-trail in an agile setup and 4-5 day-trail in a scaled agile setup. This investment of resources takes the place of a comprehensive tender documents with hundreds of specific requirements for the solution.

What are the advantages with agile contracts

When the work is delivered via agile contracts you get advantages like

• Direct involvement as customer. The customer prioritises on an ongoing basis what is most important
• Continuous value adds from continuous deployment
• The most important part is delivered first, whereby the project risk on the overall success criteria is fast minimised
• Value adding collaboration, where all parties are working towards the best possible solution for you as the customer, without hidden agendas on possible extra costs to bill
• Absence of change requests, both in terms of your administration and the cost itself
• The option to terminate a contract when the project is sufficiently solved, even if remarkable earlier than expected
• If you choose to test the new suppliers and require a fixed team, you have a deeper knowledge of the delivering team ahead of the project

Who are agile contracts relevant for

Agile contracts are relevant for anyone putting non-standard contracts out to tender or directly to a supplier. Both private companies and public institutions benefit, and the common denominator is that they seek to maximise the quality for money, earlier delivery hence faster time to market, lower the project risk while preserving the option to navigate in a fast-changing market.

We see examples from private organisations and public institutions who put agile contracts out for tender, and the area is growing. In the public domain, in the wake of huge capsized projects, we have seen a clear demand for radical change of the projects governance.

 

So good luck getting started with agile contracts

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting