outcomes

AGILE CONTRACT MANAGEMENT [#Agile #AgileContract #AgileContractManagement]

1. ONLY ONE VARIABLE AMONG SCOPE, TIME, AND COST CAN BE FIXED
2. HIGH-LEVEL ACCEPTANCE AND SCOPE CAN BE DEFINED
3. UNDERSTANDING THE BUDGET OF THE CUSTOMER
4. EDUCATING NON-SOFTWARE TEAMS
5. MITIGATING RISKS

Most of our contracts are being framed on the grounds of fear and trying to protect the interests of each other, 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 the views of each other, have transparent communication, and explicitly start following the agile value of “Customer Collaboration over Contract Negotiation.”

1. ONLY ONE VARIABLE AMONG SCOPE, TIME, AND COST CAN BE FIXED

We are aware that any project has 3 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 service provider / vendor / supplier should check with the customer which of the variables is fixed.

For example, for a refactoring code project, the service provider might not know initially how many lines of code need to be refactored. So, the service provider 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.

2. HIGH-LEVEL ACCEPTANCE AND SCOPE CAN BE DEFINED

The goal of an Agile project is to “always have working shippable software.”

The service provider 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. Understanding the budget of the customer:

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 service provider 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 is more important to build trust and collaboration for the success of the project.

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 is 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 cancelation fee in case the customer feels that they are 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

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.

ADAPTED FROM
We Really Need to Talk About Agile Contracts:
DZone