Contracting for agile – best practices

There is an increasing trend in the IT/software development industry for organizations to engage their IT vendors by leveraging agile delivery methodology. The underlining principle behind agile delivery is to create a flexible delivery environment where parties effectively collaborate to achieve the client’s product vision and then prioritize outputs in forms of sprints and pods in order to get the best results. The two organizations work as a single team, which represents a different approach from the typical customer-vendor environment.

While 25–30% of IT delivery is currently based on agile methodology, this is set to increase further. Most IT companies are gearing up for agile and there is a strong focus on developing contracting methodology for agile delivery.

Misconceptions around agile

Agile is often misunderstood as a method where the customer can change the scope, or even reject, the deliverables whenever they want without any liability to the vendor. However, the biggest issue is whether or not the customer organization is prepared enough for agile delivery. In the majority of cases, my experience says “no.”

The concept of agile delivery is often misunderstood. For the IT vendor, if the customer asks for an agile delivery model, they prefer to agree on a pricing model calibrated on capacity or rate card billing. On the other side, the customer organization is often not clear on how to frame the agile relationship while carrying out a contract, and default back to the traditional waterfall approach – which can lead to dispute and project overrun.

The waterfall contract vs. contracting for agile

A waterfall model contract is an agreement where the scope, timelines, milestones, and payment schedules are often defined to remove any ambiguity. Both parties are clear and understand what will be developed and delivered – and it is clearly documented and defined. This contract is ideal where the scope is clearly defined at the time of signing the contract and the contract lifecycle flows smoothly – just like a waterfall. Risk is low under this type of relationship due to the strict documentation.

With agile delivery methodology, the customer owns the product and works closely with the vendor. At the time of signing the contract, the parties agree to work together to achieve the desired results. The delivery teams are often divided into smaller teams based on “user stories” with each “sprint” lasting 4–6 weeks. Customer and supplier team maturity on the agile approach must be evaluated before committing to this model. It requires customers with higher risk-taking ability that can work and guide the vendor teams closely.

By way of an example, imagine you would like to make a pizza. The waterfall method would be to contract define the ingredients and steps such as the cheese, vegetables, meat, prepare the sauce, and decide on the time in oven etc. In an agile model, all decisions on how to make the pizza, what ingredients will be used, and whether it will be cooked in an oven or microwave, would be taken as and when the required stage arrives in order to make the best pizza possible.

In short, a waterfall model creates a project mindset with clear task management, whereas an agile delivery model has a product mindset that is open to creativity and release management. A waterfall contract is “task rich,” while the agile approach is more “feature rich.”

The future is agile

My advice for anyone looking to engage an IT vendor under agile methodology would be:

• Make sure you fully understand agile delivery and be ready to “own” the product. If you can’t own the product, don’t go for agile approach
• Prepare to “unlearn” the waterfall method for contract relationship
• Adopt rapid decision-making to change the methodology, redefine, and modify user stories wherever required
• Ensure you engage your teams on the agile project that are agile “mature” and can deliver your objectives
• Ensure your acceptance criteria (“DONE!” in agile) is achievable in the minimum number of sprints
• Don’t mix the waterfall and agile approaches in the same contract document
• Don’t create agile statement of work under a waterfall master service agreement or framework agreement, as this creates confusion and disputes
• Consider the risk-taking appetite expected by the client, which may significantly change the dynamics to indemnity or take liability.

While agile methodology is the future of IT delivery and the majority of projects are delivered on a “time and material” basis, they lack methodology, and there is a need to develop industry-wide contract documentation – after assessing all the associated risks and their mitigation – with specific training on how to contract and deliver under the agile delivery approach.

It would also be interesting to see how the courts would interpret these contracts – but that’s a discussion for another day!

Capgemini helps Fortune 100 companies drive meaningful intelligence out of their thousands of contract documents. To learn how Capgemini can provide the correct contract management platform for your organization, please contact: mani.agarwal@capgemini.com

Click here  to learn more about how Capgemini’s Contract Compliance & Optimization (CCO) solution provides a broader and deeper solution to your compliance, cost reduction and spend protection goals, from an often-overlooked area – the written contract.

Mani Agarwal advises clients on commercial and contract management transformation initiatives. He helps organizations to transform their contract lifecycle and contracts portfolio by implementing the right machine learning/AI tools. He also uses his expertise in optimizing the performance of contracts to ensure maximum value through all contractual opportunities and avoid any revenue leakage. Mani is a qualified lawyer and an elected member of the prestigious IACCM Council for IT and Outsourcing Networks.