Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses.

Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.

So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.

Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.

#agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7

— Samuel Fricker (@samuelfricker) March 15, 2016

Must-Have Agile Contracts

Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation:

1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models:
a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up. 
b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends.

2. Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful.

3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level
MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative.

4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are:
a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.

Conclusion

Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it.
Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”. In addition to agile, we also provide PMP certification prep.