Few months back, I wrote a blog article about ‘Fixed Price Agile contracts’. I could not go back and finish the subsequent parts at that time, and I got many requests for Part II. Post that, I spent quite a few days researching and organizing a webinar on ‘Agile Contracts’ which prompts me to write this new blog article on ‘Agile Contracts’. Fixed price is more or less implied here, as we all know the contracting clauses come into play more strongly in a fixed price scenario as compared to Time & Material. BTW, we had overwhelming response to the webinar from all parts of the world, so thanks everyone ! The webinar slides are going viral on Slideshare…
Here I have attempted to take those concepts and outline Agile contracts end to end. And as usual, we refine as we go 🙂 I have a feeling this write-up is going to be a very long one!
Agile Contracts
Agile Contracts is a ‘hot topic’ these days and it is not a surprise. Agile has evolved from a bunch of interesting concepts to serious mainstream strategic goal. The Agility needs of each organization is different (but that is another topic in itself about which I will write soon).
In early days, Agile used to be the method for product companies and volatile businesses. Now even US and UK government have prescribed guidelines for Agile execution and vendors are asked to prove their agile capabilities in the pre-qualifying round. These new developments bring forth many challenges to service providers, especially the ones which have been catering to very large projects with traditional contracting clauses. The other group that need help are the Contract Administrators, Procurement Managers and client-side Project Managers
I have seen some good posts out there explaining 10 different ways to do agile contracts. But unfortunately, what I found missing was specifics around structuring the clauses, terms and conditions. I could not use these posts and convert my traditional contract into an agile one in a matter of few hours. And this is exactly what I am attempting to do here. Hopefully, the guidelines given here are good enough for you to look at your contracts and change the clauses. In case you need any help with it, you know who to ask 😉
Disclaimer
Now, if you are coming from an innovative product company, internet company, or any such businesses where contracting between supplier and customer is not deemed necessary, or very light and loose contracts are the norm, please do not attack me for this post, as this is meant for formal businesses and especially large projects where very formal contracts are expected between both the parties.
How contracts have been done traditionally
Traditional projects (waterfall) were based on different principles as compared to agile.
Usually when people say fixed price, they mean fixing the price, time, and the scope. To be able to fix the scope, detailed, stable and accurate requirements is a must. In traditional fixed price projects, the language of the contract was the assumptions on which projects are executed:
Upfront requirement gathering
In traditional fixed price, once the requirements are brought in, they are signed-off and any deviation from the baseline is considered as a change request irrespective of the priorities or business value it can bring. The contract will bring forth this aspect in its language by enforcing each and every detail of the project’s requirement and design is thought about up-front.
Late business value
There is no business value “seen” till the very end of the project. Hence from the client’s perspective, the contract guards against delays and incomplete deliverables and introduces penalty clauses whereas from the vendor perspective, the contract guards against pull outs and non payment.
Accurate estimates and timeline commitments
The non-agile methods expects that people would be able to ascertain the exact number of hours/ cost to complete the project milestones and a golden date that the software can be released. The contracts are thus built in a way to hold the vendor to these commitments in terms of payment and legalities.
Why do we go for Agile Contracts?
If you are trying to get into an agile contract because your client is asking, or because the management is asking, or your competitors are doing it, please think twice. These are ‘wrong’ reasons to go for agile contracts. If the below given reasons are why you are doing it, you are in the right track:
- To ensure early business value (ROI)
- Secure the time and the cost
- Lower the delivery risk
These factors need to be built into the contracts and the contract should protect these original intents.
When we compare traditional and agile projects, almost all the below aspects of project management is done differently.
- SDLC
- Roles and Responsibilities
- Scope management
- Schedule management
- Milestones
- Deliverables
- Payment terms
- Change management process
- Project control & status
Almost every one of these above mentioned aspects is different in Agile as compared to traditional, and the contract obviously should take care of these differences.
We are talking about assuring great results and a mutual win-win while we are trying to move from a scenario like this:
To a scenario like this:
The case of the ‘Inverted traingle’ : solve this, and you solve the enigma of agile contracts!
We all know the traditional ‘triple constraints’. Traditionally, we used to ‘freeze’ the scope and estimate effort, cost and schedule. In agile, the pyramid is ‘inverted’. i.e, we may or may not have all the scope defined, yet we have to estimate the time and cost.
How do we tackle this scenario?
Scope in Agile
Definition of Scope in Agile
Scope in Agile is equivalent to delivered ‘business value’ as opposed to WBS in traditional projects. The requirements are depicted as epics, features or stories depending on the level of granularity. Some examples of scope in Agile context:
- Sales forecast report
- Screen to capture employee details
- Register a retail customer
- Make an online payment transaction
Some examples of what is NOT scope in Agile:
- Project status reports
- Risk register
- Earned value report
- Task assignment register
Project management activities are not considered as deliverables though will have to be priced and charged in the contract.
Measuring Scope in Agile
- Story points
- Feature points
- Epic points etc.
The inherent conflict between Agile & fixed price
Clarity and stability of requirements – A deciding factor for building fixed price contracts
The three zones above depict:
Zone 1: Requirements are available and stable, so it is the most easiest of the Agile contracts
Zone 2: Requirements are available partially, and there is a probability of requirements change
Zone 3: Requirements are not at all available, so we have to look at innovative approach to structure the fixed price contracts
As we go forward, we will explore how to structure contracts for all these scenarios.
Scenario 1: The requirements are very clear and stable
In this context, it is quite simple to structure an Agile fixed price contract.
Highlights:
Single contract with a single statement of work (SOW)
Contract Type: fixed price
Execution steps:
In Fixed price contracts, regardless of effort or the time, the cost is fixed. The cost/ effort can increase due to two main reasons:
In the above case, if the project is delayed by two sprints, the supplier absorbs the additional cost (unless it is due to scope change and the relevant conditions are taken care in the contract).
In projects where the requirements are not clear and yet there us a need to build an estimate and commit on a timeline, the following is suggested for circumventing this ‘scope clarity issue’ and minimizing the risk.
Scenario 2: Partial requirements or only high level view available
In this context it is better to divide the project logically into two blocks.
Highlights:
One contract; Two SOWs
Contract Type : Fixed price + fixed price
First SOW (Fixed price)
Second SOW (Fixed price)
In this case, it is advisable to build in a variance of +/- 15% into the estimations.
The most challenging scenario is when there are no requirements at all. Sometimes we are faced with situations where we have an evolutionary approach to the product which is in making. Yet, in this case also, structuring Agile contract is still possible.
Scenario 3: No requirements; only objectives & goals available
In this context also, the project is split into two logical blocks.
Highlights:
One contract; Two SOWs
Contract Type: T&M with cap + fixed price
First SOW (Time & Material with Cap)
Second SOW (Fixed price)
The first contract has a cap built into it so that if the prototype is not found to be feasible, it can be a decision point whether to move ahead into the next phase or not. This is a risk mitigation strategy. In this case, it is advisable to build in a variance of +/- 25% into the estimations as the level of risk is comparatively higher.
Let us look at how this type of a contract creates a win-win for both Customer and the Supplier.
Wins for the Customer
– If the project is deemed to be risky due to lack of requirement clarity, technical clarity, or any other unknowns, having a prototype phase helps to gain more clarity and to evaluate the feasibility of the overall project.
Wins for the Supplier
Agile fixed price contracts – Terms and terminologies
We will see how all this comes together in building a good contract in the coming sections.
Terms
Whichever way contracts are written for Agile teams, there are two essential elements that need 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 is emphasized repeatedly in Agile: time-boxed iterations, retrospectives, test driven development, etc. etc. It is the PDCA cycle in action.
Secondly, the contracts should motivate the customers and their representatives to maintain involvement throughout the duration of the project. Study after study has shown continued customer involvement is a key factor in ensuring the success of IT projects. Whether you are working in Agile or not, the success of the project is determined majorly by the customer involvement.
This whitepaper does not attempt at re-writing the typical building blocks of a Master Service Agreement encompassing Licensing, IP rights, Personal data protection, Confidentiality, Indemnification, Export and Import compliance etc.
The following sections will attempt to rephrase the verbiage , and re structure the terms and clauses used in a typical Statement of Work ( SOW) comprising of the following:
Traditional Contract terms |
Agile Contract terms |
The purpose: why are we doing this project? |
|
|
•This SOW is issued in support of development of X project
|
•This SOW is issued in support of development of X project
•The project goal is to achieve early business value in an incremental and iterative way
|
Contract type, model & standards |
|
What kind of contract agreement between both parties?
Mention the contract type chosen explicitly and the rationale for the same |
|
|
•Fixed price
•Fixed price + incentive
•Time and material
•Others…
|
•Agile fixed price
•Agile hybrid (time & material with cap + fixed price)
•Agile time & material
|
Project execution model and standards: how the project will be executed? Explicit emphasis on Agile as the chosen project execution methodology and the quality standards |
|
|
•Project management processes like PMI, prince2
•Quality standards like ISO
•Any other standards like six sigma
|
•Agile methodology for execution
•Software sizing process for project scoping and change management with defined sizing framework
•Product quality standards specific to the industry
|
Traditional contract terms |
Agile contract terms |
Scope, schedule & cost
|
|
Project scope: how much are we going to deliver?In Agile, you can measure the amount of scope to deliver and the scope changes as ‘points’ |
|
|
•As per the software requirements specification (SRS) document
|
•X number of size units (story points, epic points, XYZ points)
•Explain the sizing method and framework
|
Project cost: how much will it cost?In Agile, you are buying/ selling measurable business value as ‘points’ |
|
|
•The fixed price of $X for the original scope
•Changes cost extra $X as per the additional effort/ hour
E.G.: 1000 person day project; costs $100,000 Note: paying for the effort |
•$X per size unit delivered
•Changes cost $X per additional size unit
E.G.: 500 story points; costs $100,000 Note: paying for the delivered ‘business value’ |
Project schedule; when are the deliverables expected?The milestones are based on product deliverables and not just the process hand-offs |
|
|
•Architecture document by <date>
•High level design by <date>
•Status reports by <dates>
•UAT by <date>
•Final release by <date>
|
•Architecture choices by <date>
•Iteration frequency <weeks>
•Iteration0 start <date>
•Size (points) planned per iteration
•Size (points) planned per release
•Demo <dates>
•Release milestones <dates>
•UAT <dates>
•Final release <date>
|
Traditional |
Agile |
Responsibility |
|
Project managers: who are the primary responsible parties on both sides?The primary responsibility of the project managers remain the same |
|
|
•X is the supplier project manager responsible for day to day management, conduct and performance of supplier employees and deliveries
•Y is the client project manager and interface to the supplier; responsible for the project and accuracy of the SOW
|
•X is the supplier project manager responsible for day to day management, conduct and performance of supplier employees and deliveries
•Y is the client project manager and interface to the supplier; responsible for the project and accuracy of the requirement
|
Additional roles: who is responsible for scope and validation?The product owner role is most important and mandatory |
|
|
•There will be a designated ‘client product owner’ who will liaise with the supplier team to ensure that the requirements are prioritized and verified at defined frequency of <frequency>
|
|
Project governance |
|
Project meetings: the strategic and operational meetingsThe meetings are oriented towards product demo and prioritization rather than mere status |
|
|
•Kick-off meeting
•Steering committee meeting every X weeks
•Weekly operation review meetings
•Closure meeting
|
•Kick-off meeting
•Steering committee meeting every X weeks
•Weekly operation review meetings
•Release planning meeting (with the product owner)
•Iteration demo & feedback every X weeks (with the product owner)
•Closure meeting
|
| Traditional | Agile |
| è Project status reporting: how do you measure the progress and forecast completion?The reporting is based on pre-agreed quantitative measures on product completion & product quality | |
|
•Supplier is required to provide a status report every month using metrics (time spent, effort spent, schedule variance, effort variance), qualitative analysis and forecast using a method like earned value
|
•Supplier is required to provide quantitative statistics during the steering committee:
•Size planned till date
•Size delivered till date
•% Scope change (size points)
•% Product completion
•% Release completion
•Release dates
•Variances to the above
•Technical metrics (code coverage, test coverage etc.)
|
Mutual obligations |
|
Description of services: what are the obligations from the customer?Customer involvement and acceptance during the product build has to be explicit in the contract |
|
|
•Customer will provide the
•Software requirements specification (SRS) document
•Acceptance terms
|
•Customer will provide the
•SRS document (if working with upfront requirements)
•Product vision (at the beginning of the project)
•Every release:
•Requirements priority
•Requirements acceptance criteria
•Requirements feedback & changes
•Review the sizing and re-sizing (scope changes) as needed
|
Traditional |
Agile |
Description of services: what are the obligations from the supplier?Iterative delivery, demo, acceptance and releases are built into the contract |
|
|
•Supplier will provide the software development services
•Acceptance will occur at the end of the project upon:
•Delivery and approval of software, UAT, installation, commencement and completion of trial run, integration of the modules with core system
•Final acceptance as per the acceptance test plan
|
•Supplier will provide the software development services in iterative cycles of X weeks (months)
•Integration will be at agreed regular intervals of X days (hours)
•Completed requirements to be demoed after each iteration to the PO
•Acceptance will occur for each release
•Acceptance criteria against each requirement (agreed at the time of sizing) will be used as the acceptance benchmark
•Final project acceptance as per the combined acceptance criteria of each release and final test plan
|
Defining acceptance: how are the acceptance criteria defined?Acceptance is pre-agreed along with the requirements sizing. Each iteration is demonstrated. Each release gets accepted. |
|
|
•At the end of the project through UAT
•Verification of documents
•As per acceptance test plan
|
•Requirement level:
Definition of ‘done’ (acceptance criteria, i.e., the tests are successfully passed) •Iteration level:
X% of the features are successfully demonstrated •Release level:
Quality (bugs) within agreed range •Project:
Final sign-off |
The next elements that need to be looked upon are :
Deliverables:
What are the deliverables expected from the supplier ?
Change Control:
How to manage the changes?Changes are allowed for free if there is no extra size to be delivered
Payment terms, warranties, cancellation, payment schedule:
When the supplier gets paid? What are the payment terms in agile contracts? How do you define the warranties? How are the payments linked to deliverables?
The blog is quite a bit long and if you need more details on deliverables, payment terms, etc and a simulation of the payment schedule in agile:
just ask me (put your request here) and I will be happy to share more material on agile contracts.
Alternatively, you can download the Agile contracts whitepaper here
You can watch the first part of the Agile contracts webinar on youtube
Will be happy to discuss on this topic, feel free to connect with me on LinkedIn
Long live Agile ! 😉
Ciao….
Author
A seasoned tech leader with 20+ years of experience, Nisha drives global business development and client relations at People10.