Change and Permanence

by Christopher Goldsbury on Nov 27, 2012 |

Agility embraces flexibility and change, but legal contracts are about codifying permanence and avoiding risk of loss or damage to the parties engaged in a business transaction. How do we bridge the gap between these poles, without sacrificing the value that both areas, legal profession and agile software development, bring to the world? That's the point brought forth by Callum Sinclair in his article, How To Make IT Contracts Agile, October of 2012, Computer Weekly.

According to Mr. Sinclair:

Lack of understanding of agile methodologies among legal professionals, and the resulting lack of contract precedent and "legal" case studies, are slowing down the uptake of agility in big business.

Others have made similar points, and gone as far as suggesting one of the major barriers to adoption of agility is the lack of contractual models to handle agile projects.

Many contracts drafted for development of a software product seek to nail down, in detail, the specifics of all deliverables by spelling out the scope of work, the cost ( accepted bid ) of that work, and the time-line upon which it will be developed. This is frequently referred to as a fixed bid contract and is very common in government procurement of IT services, such as that recently undertaken by the British government's Cabinet Office.

With increased interest by government's throughout the world in harnessing the benefits of agility, what are the the main sticking points that contract and commercial lawyers see with respect to agile? Beyond just a lack of understanding or general knowledge of agile software development practices, what specifically would cause concern? Paraphrasing Sinclair:

Lack of specifics. In most agile methodologies the product is not defined up front. Instead the product evolves, organically, embracing changes along the way. This makes it hard to define exactly what is or is not being delivered in a contract.
Agreements to agree. Agilists frequently defer decisions on what is or is not in an iteration, or end product. This lack of up front decision making goes directly against the tenets and principles of contract law and would make it difficult to enforce contracts through lawsuits, arbitration or mediation in the event of a dispute.

To address these concerns, Mr. Sinclair makes these suggestions to business owners and suppliers who believe in the benefits of agile, but need alignment with senior management and lawyers:

Ensure there is a basic understanding of what agile development is and what benefits it can deliver at an early stage in the process. Brief crib sheets or case studies may help to illustrate and secure buy-in. Be upfront about the risks, but focus on characteristics of agile which may help to mitigate those risks. For example, agile's focus on a working deliverable at the end of each iteration can help to alleviate lawyers' concerns about early termination and liability provisions.
Consider the relative merits and risks of agile versus waterfall for the proposed project in light of the scale of the project, the culture of the customer organization, the availability of resource on the customer side and so on. Decide early whether that analysis rules out any specific approach for the project concerned.
As a customer, ensure that business case documentation and requests for proposals (RFPs) are sufficiently flexible to accommodate agile methodologies - assuming point 2 above has not ruled these out. Good procurement practice will generally involve lawyers seeking to attach proposed contract terms to RFP documentation to secure agreement in principle from suppliers, but this can be problematic if those terms assume a waterfall delivery methodology, as many based on existing precedents do. Consider seeking similar comfort by attaching a set of contract principles or dual forms of contract to reflect each approach.
Work with lawyers to consider limited contractual controls to re-introduce further certainty: "Minimum Viable Product" definitions, capped overall project costs, and long-stop delivery dates are all examples. While these arguably start to chip away at the flexibility of agile, hybrid models like this can work as long as the trade-off is properly understood.

Interestingly, Mr. Sinclair's second suggestion indicates that agile may not be the right fit in every case, a point that continues to be an area of debate within the software development community.

Laws and contracts are there to protect our rights and property in the event of disputes, but complex endeavors, like software development may often require a flexible approach to succeed. Does contract law need to evolve with the times or should agilists become more pragmatic in their approach? What other approaches have yielded more common ground for agile software development and contract law?

Related Editorial

Agile workshops and training

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Infographic: Just How Big is the Nerd Economy

Application Performance Management Buyer's Guide

Enterprise-class API Patterns for Cloud & Mobile

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Customer collaboration over contract negotiation by Tarun Sukhani Posted

Customer collaboration over contract negotiation by Tarun Sukhani

What part of customer collaboration over contract negotiation don't people get? The problem is getting lawyers involved in the first place. This is not a choice between "pragmatism" and contract law "evolving" with the times. Contract law is mired in the 15th century and will never change, PERIOD, and being "pragmatic" at the expense of delivering what the customer actually wants or needs is hardly a rational choice, although of course 99% of companies do so, and suck because of it.

Too bad people with severely low IQ's write this junk and get away with it.