Why Agile Contracts?
Last few decades saw large multiyear waterfall contracts between companies with their vendors.
Waterfall contracts are based on philosophy of Supply of Goods involving:
- Initial specifications,
- Change control,
- Sequence of development with gated approach,
- Acceptance through testing at the end by comparing actual vs planned,
- initial specifications,
- Listing out legal provisions in the contract as risk mitigation.
These contracts leads to increased delivery risks, suboptimal design, late business value delivery, cost overruns / schedule slippages leaving both clients and partners in lose-lose situations.
- To meet business objectives of early & frequent business value delivery, faster time to market and better productivity and finding better alternatives for waterfall way of work, companies increasingly adopting distributed enterprise wide global agile.
- Simultaneously companies started looking out to renegotiate waterfall contracts for agile ones to sync up legal contract and delivery, working with their own businesses, legal, IT, finance units to devise appropriate agile contracts in collaboration with vendor partners like Infosys.
Agile contracts are different and challenging as it requires change in mindset among all stakeholders.
Agile contracts consider work under consideration as a knowledge creation services, are more productive as they are based on small chunk of work / scope and rapid feedback, can be executed through incremental / iterative delivery.
Inverting Iron triangle of Time, scope and cost, agile propose to adoptively manage scope, within fixed timeline / budget, reducing greatly any cost overruns.
- Timeline will be driven by client business intention to make product /application features available to end users. (no schedule risk)
- Budget will be driven by client portfolio allocation (based on certain cost /benefit analysis of various project feasibilities), high level estimates are published within prescribed timeline, collaboratively by client and delivery teams, thus sharing risks to a large extent.
- Scope will be managed through prioritization and break up into manageable work chunks and agile contract is put in place around it.
- A large multiyear MSA can be formulated as an umbrella contract of multi phased variable progressive incremental type to address different needs and provide flexibility around constraints like scope, price, schedule and resources as well as exit route for both parties at iteration levels.
- To start with, initial few sprints / release can be fixed scope contract with minimum change to current one. Contract will provide opportunities for frequent feedback and early realization of business value gets customer trust early in program lifecycle.
- Then adaptively, client and vendor can agree upon FP, TM, Capped TM, unit of time, unit of work, pain and gain or target cost price or combinations of any of these as per program lifecycle demand under umbrella MSA.
- Further, agile suggests clients to adopt release based funding aligning with agile delivery cycles instead of project based annual/ quarterly IT funding. This will further reduce risk, utilize funds allocated optimally and showcase maximum ROI.
- More and more customer trust, collaboration, transparency, promotion of "real time" visibility and control of the releases / programs enables agile contracts successful by achieving desired outcomes.
What are the different pricing models followed in the agile development projects across Infosys?
Infosys is partnering with clients delivering Agile Fixed Price (FP), Time & Material (TM) and Capped Time & Material (CTM) contracts and collaborating with them for devising innovative ones.
Find below Illustrative summary of projects executed using Infy Agile Global Methodology with split by contract type.
What are the challenges while serving FP /TM / CTM agile contracts?
- Agile fixed price contracts poses more challenged for contract negation as well as program execution as effective collaboration is required from clients and vendors to come up with agreeable rules and policies about scope changes during contract negotiation itself keeping "customer collaboration as against contract negotiation".
- For TM /CTM, contract model is more suitable for agile way of work if above mentioned roadblocks are avoided successfully.
How to handle FP scope change control in agile way
Assume Product backlog is segregated as follows.
Scope change can be handled as per following scenarios.
What are few more flavors of agile contracts that can be formulated?
In summary, contracts themselves will not protect clients and vendors for every possible fear and risk envisaged and provide win-win for all parties involved but should be devised as a starting point to drive long term strategic partnering, building trust and collaboration for future growth opportunities.
AGILE CONTRACTS PRIMER by Tom Arbogast, Craig Larman, and Bas Vodde
Software Development: Why the Traditional Contract Model Is Not Fit for Purpose by Susan Atkinson & Gabrielle Benefield