Welcome back to the Agile series. This time, I will spend a few words around “Contracts”.
If both supplier and customer want the maximum benefit from Agile, then traditional style Contracts need to be rethought. This is an evolving area and organizations are constantly searching for new models of Contracts. Consequently, here are opportunities for Agilers (it sounds nice) to disrupt the status quo.
This post will look at four models available to suppliers and customers for establishing Contracts for Agile projects.
The fixed price, fixed duration, fixed scope Contract continues to be the standard benchmark for Contracts in the IT industry. A Contract of this type is based on the idea that an initial project can define the scope of the work. Once the project scope is defined, the Contract can be signed and executed as detailed.
While I have worked in many waterfall projects, I still have to be part of a project successfully completed without relaxing at least one of the “fixed” parameters (scope, cost, or schedule). The IT industry has been signing these kinds of Contracts for years. Failure risk is very high – the scope of the project changes, new requirements emerge, existing requirements are overlooked, while still others are misinterpreted. Whatever the reason, once requirements change in a “fixed” Contract everything else must change too.
The reason why these type of Contracts survive is that they can be defended in court. While one side claims the Contract was not fulfilled the other side claims it was – leaving it up to a judge to decide. It is really funny to believe that two parties agree on requirements, duration, quality, and costs from the very beginning. It will never happen never!!!!
The simplest way of using Agile within a delivery Contract is just to hide it. Don’t tell the customer you are working any differently to normal. Estimate and plan the work as you would normally, sign a normal Contract, then use Agile techniques to improve delivery.
Test driven development, continuous integration, refactoring regularly and re-planning will help you to deliver quality software anyway.
Naturally, if customers ask “progress against plan” it’s fundamental to merge everything in a “work progress status”. I know this is not fear at all and, as contractors, we should be trustworthy.
So to make the “hide it” approach work there needs to be a “don’t ask, don’t tell” type policy. If you have a customer who is prepared this policy, and instead measure progress against actual deliveries rather than following the plan, then hiding Agile might work.
Adopting this approach requires a certain degree of confidence. It is simple: if the customer doesn’t like what you deliver there is no fee. However, if they don’t pay for what you produce they don’t get to keep it either.
While such an approach looks scary it does provide the opportunity to increase the fee. Using this approach the clients reduce their risk exposure while the contractor increased theirs. The price for this rebalancing of risk is a higher price.
Such an approach introduces a new risk. Since the client is less exposed they have less motivation to make the project a success. When clients are not involved in the game any failure is entirely the failure of the contractor, clients have nothing to loose.
This risk might be offset if suppliers choose to work only with customers who will maintain their commitment. This assumes that the contractor feels able to turn down work they judge risky and can correctly assess the commitment level of the client.
If we wish to keep customers involved, then we need a mechanism to involve and continuously ask them to be committed to the work. This is where Rolling Contracts have a part to play. Rather than agree to a large piece of “all-or-nothing” work, the customer and supplier put in place a framework agreement for a series of short development mini-projects, call them episodes or iterations if you prefer.
With each delivery, the customer pays the supplier and has a choice: continue to the next iteration or halt here. In some ways, this isn’t so different from the first method described below. The difference is that, while in the traditional model a decision to walk away before the end would result in no delivered benefit, under this model something is delivered.
The client can see something being created, the value is added and a solution coming together they should be enthused to keep working.
This option moves the legal framework away from the supply of a thing and towards the supply of a service. While this option might sound radical, many IT groups and suppliers are already using service Contracts in many areas. For example, IT software maintenance contracts are normally written as service contracts. So they could think projects in this way too.
The “Money For Nothing, Change For Free” contract has been documented in detail by Scrum originator Jeff Sutherland (https://en.wikipedia.org/wiki/Jeff_Sutherland). Rather than thin the contract as a framework for mini-projects, this approach maintains the big contract – which implicitly suggests some large upfront requirements analysis. However, one additional clause is added to the contract.
This change in the Contract exists to facilitate working on the highest priority items first and accommodating new work. Customers agree to meet with suppliers regularly to reprioritize the remaining work. At this time they may add additional work to the backlog with the understanding that in doing so, some other work might drop off the end and not get done at all. This increases the incentive to work with the supplier and maintain customer involvement.
Like a Rolling Contract, the customer pays in regular increments in response to delivering working software, which also keeps customers involved, leads to another implicit recommitment, and makes way for the second change.
The “money for nothing” provision allows the customer, at any stage, to cancel the remaining work and keep what has been created so far. For this privilege, the client pays 20% of the outstanding work.
Thus, the mechanisms and incentives are provided for customers to get involved, get work done quickly and save money. Similarly, suppliers are incentivized to accept change, do good work, and collect free money.
Whichever way Contracts are written for Agile teams, there are two essential elements to be considered. Firstly, the Contracts themselves should embody the iterative nature of Agile working: do a bit, show a bit, do a bit more. This is the theme which occurs again and again in Agile: time-boxed iterations, retrospectives, test-driven development, etc., etc..
Second: Contracts should incentivise customers and their representatives to maintain involvement with the process for the full duration of the project. Studies have shown that continuous customer involvement is a key factor to ensure the success of IT projects, whether you are working Agile or not.
Some clients will continue adopting the traditional contract model. Some suppliers will find good money in taking advantage of these customers, while others will lose money by such a model.
Right now, there are opportunities for those who can make an early shift to new contract models. Yes, there are risks, but there are also rewards. It’s time to be brave.
I hope one day, as customers better understand these new ways of approaching IT Contracts and the wide range of possible options available, everyone stands to benefit.
Keep it in touch.