We Really Need to Talk About Agile Contracts

DZone 's Guide to

We Really Need to Talk About Agile Contracts

When it comes to writing Agile contracts, I think most of us who have been working in software consulting companies will agree that there is still reluctance.

· Agile Zone ·
Free Resource

Sign on the dotted line

If we really want to be Agile, we need to make sure our contracts are, too.

We all are aware that Agile software development has been in existence for about 18 years now, so it's clearly been enough time for organizations to adopt Agile processes for the complete development lifecycle.

But when it comes to writing contracts, I think most of us who have been working in software consulting companies will agree that there is still reluctance, and most of the time we either go back to waterfall language of writing or succumb to a mix of both the traditional and agile way.

You may also like:  An Overview of Agile Contracts

Most of our contracts are being framed on the grounds of fear and trying to protect each other’s interests, and at times, we just listen to the customer. But for any organization who wants to practice agility, we need to ensure that our contracts are based on trust, collaboration, and transparency.

When trust is being built, both the customer and supplier respect each other’s views, have transparent communication, and explicitly start following the agile value of “Customer Collaboration over Contract Negotiation.”

Below are the pointers I would follow for agile contract management:

1. We all are aware that any project has three variables: scope, time, and cost. As Agile software development focusses on value-based delivery, only one variable can be fixed. So, during contract discussions, the supplier should check with the customer which of the variables is fixed. For example, for a refactoring code project, the supplier might not know initially how many lines of code needs to be refactored. So, the supplier can do some groundwork to estimate the time and cost and as per the budget of the customer, the cost can be fixed. The timeline for completion can be estimated based on the story points and the progress of the first 1 or 2 sprints.Traditional vs Agile project management2. High-level acceptance and scope can be defined. The goal of an agile project is to “always have working shippable software.” The supplier can hold discussions with the customer about the acceptance criteria and the scope so that they can use that to start work for the first sprint and collaboratively the product can evolve incrementally in the forthcoming sprints.

3. It might not be possible for a development project to follow a fixed price model. There might be changes in the scope that will affect the original price. In order to combat such a risk, it is important to understand the budget of the customer. Once this is known, the supplier should start with the high priority items first, and the low priority items could be negotiated for removal when the scope changes.

4. Educating non-software teams: Sales, Legal, and other teams involved with the contract should be educated on how Agile is different and why the traditional way of contract writing will not work for agile projects. Most of the time, the legal team is concerned with the clauses and if their client is protected. It should be emphasized to them above all that it’s more important to build trust and collaboration for the success of the project.

The benefits of agile contracts should also be highlighted as these contracts provide more flexibility, the product development can be broken into shorter iterations with frequent releases, and it provides mutual benefits to both the parties.

5. Mitigating risks: Sometimes delivery of outcomes as desired for Agile projects could be unpredictable, especially for projects that deal with empiricism or during new product development. It's possible that the customer might not get the desired solution. In order to mitigate risks during these situations, the contract should include clauses related to:

    • Termination for each iteration when it does not match acceptance criteria
    • Preferred communication channels with an appropriate escalation should be included
    • Clawback mechanism for payment when an iteration is incomplete or has no business value 
    • Early Cancellation fee in case the customer feels that he is done with the project before the desired value is delivered
    • Other factors like handling disputes and resolution, who should own the Intellectual Property rights, and warranty for the finished product should also be discussed and included. 

6. My Story with agile contracts: In my start-up, we have worked on agile contracts with software vendors to develop a mobile app. In this contract, we fixed the budget and provided high-level scope and acceptance criteria. We agreed on a contractual basis that the vendor will start working on the high priority items, which included all the basic features of the app for the initial four sprints, each in a three-week timebox. The team liaising with us was able to break down the high-level scope to user stories and estimate the story points. By the end of the second sprint, we could see the evolving product backlog and showed good progress.   


In summary, according to me, agile contracts should arise from relationships and should be flexible documents that are more transparent and should contribute to the success of the project rather than a document that restricts collaboration and coerces trust.

This kind of understanding should be established with all the parties (e.g legal teams, sales teams, procurement teams, etc.) involved in the contracting process.

Further reading

Lean Tools: Contracts

Scrum and Fixed Price Contracts

Contracts for Agile

agile adaptation ,project management ,behavior change ,agile contracts ,consulting ,trust ,collaboration ,transparency

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}