Agile Contracts – An Introduction
If you are working in technology, you are likely witnessing the ever-increasing penetration of the Agile development methodology into technology development and IT services procurement. Agile contracts are here to stay.
Agile development is used in projects from website development agreements to large-scale multi-year consulting projects. Agile contracts, in a variety of forms, have proliferated.
Both customers and service providers may push for Agile, in many cases as a result of the problems they have encountered using older methodologies such as the “waterfall” approach. Agile development offers many advantages and may be an appropriate development methodology for all or part of a given technology development project.
Agile principles stress early and continuous delivery of technology, embracing changing requirements, mixed business and technology teams working closely together and meeting frequently with the trust and support of their organizations, simplicity and ample time for reflection.
To those used to standard development methodologies, these principles – and their use in practice – are often surprising and take time getting used to. So when the parties choose to use Agile, what Agile contracts do they use? Like Agile, the answer is often not a simple one for a number of reasons.
Agile is Flexible and Usage Varies; The Same Applies to Agile Agreements
Part of the benefit of Agile is its inherent flexibility, but this flexibility often results in Agile taking many different forms in practice. Some parties choose to use Agile for only specific parts of their technology projects, and frequently parties have their own preferred ways of implementing Agile principles which may or may not align with what some would consider to be traditional Agile methods.
What is important is that whatever the parties use, it works on the ground and the Agile contract matches what the parties intend to actually do. This may sound obvious and a concept that should permeate all technology contracting, but there is often a significant disconnect between project teams and their contract drafters (whether in-house or outside counsel).
Once there is buy-in on the general parameters of an Agile project, significant translation may be needed to make sure the Agile contracts match up to what the parties intend.
If this does not occur, often the starting point (often proposed by the customer) is a lengthy, cumbersome contract that not only fails to reflect an Agile methodology, but also presents the exact “waterfall” or other approach the business teams seek to avoid.
Then, invariably, precious weeks are lost between legal and business teams trying to get everyone up to speed on what they should and should not include in their Agile contracts for the projects at hand.
Obviously, this is not an ideal starting point given that one of Agile’s key goals is to get workable technology moving as soon as possible, and also because a key Agile tenet is valuing customer collaboration over contract negotiation.
But What About our Standard MSA and SOWs? Agile Contracts are Different
Standard master services agreements (MSAs) and Statements of Work (SOWs) can be great tools for both service providers and customers – when deployed in the right context. The reality is, however, that standard MSAs and SOWs will not work for Agile development projects.
Many of the issues addressed in standard MSAs and SOWs also have to be evaluated in the Agile environment to see how they will apply and what modifications will be needed to address Agile’s nuances.
For example, all technology development agreements will have to address the parties’ agreements as to intellectual property, indemnification, risk allocation and economic issues.
However, these and other issues, such as performance-related representations, warranties and covenants, may require adjustments in the Agile environment.
Some of these issues are internally driven within the Agile methodology itself and are handled quite differently than the documentation-heavy and formalistic acceptance testing provisions that are often seen in standard MSAs and SOWs.
In Agile, getting usable technology to the customer early and in a continuous and systematic fashion is critical. As a result, it is not unusual for the product of an Agile development project to be significantly different from what was originally contemplated by the parties at the outset.
To Agile evangelists, these are not radical concepts. To lawyers and procurement teams, on the other hand, this can cause a significant degree of contractual consternation and departmental heartburn.
This is why it is important, at the outset, to make sure that the business and legal/procurement teams are aligned on the Agile methodology. There will undoubtedly be significant variation in deployment, but if the teams are able to agree in principle to Agile principles, contracting becomes much easier.
Terminology and Implementation in Agile Agreements
Agile development has its own terminology which can vary widely in usage and sometimes meaning, especially as Agile itself continues to evolve. The important thing is that the business teams understand and agree to what the terms they use mean for purposes of development and contracting.
So when you hear terms like backlogs, burndowns, user stories, velocity, iterations, scrum masters, sprints and user stories, do not be alarmed. It may take some time to get used to the terms, but when you see how they are used in practice they become more manageable.
In some Agile contracts, only a framework for Agile development is provided, with the parties agreeing to work within the framework and the established Agile methodology of one of the parties.
While Agile focuses more on working technology than comprehensive documentation, Agile projects do have their own, often detailed, set of project documents that are updated through the Agile methodology as the project moves forward.
In some projects, these are used for benchmarking or to provide tie-ins with the overall contractual framework. Their impact on the legal terms and conditions, however, should be reviewed and addressed as part of the contractual negotiation.
For technology teams (whether customer or service provider), choosing Agile for a development project is often a no-brainer. In many organizations, these teams will have to do some lifting to help their legal and procurement teams work with Agile concepts so that the parties can minimize negotiation and start collaborating as soon as possible.
Over time, organizations that achieve positive results may even optimize their contracting functions to seek contract agility for areas beyond technology development.
Copyright 2017, Geoffrey G. Gussis. All Rights Reserved.
Shared by Geoffrey G. Gussis, Esq., a business lawyer and technology lawyer licensed in New Jersey and New York. Learn more about me, the legal services I provide, and articles I have written. Contact: firstname.lastname@example.org or (732) 898-0549 or (646) 389-2946 for a free consultation.
The materials available at or through this website are for informational purposes only and do not constitute legal advice. You should contact a licensed attorney in your jurisdiction to obtain advice with respect to any particular issue or problem. Use of and access to this website, or any of the information or links contained within the website, does not create an attorney-client relationship.