Align Contracts with Agile Software Teams

Agile has been around for 20+ years. That seems like enough time for companies to get the hang of incorporating key agile terms in legal contracts. Yet when it comes time for a company to enter into a contract about agile work processes and software deliverables, we’re still seeing Waterfall language persist.

Don’t believe me? I recently received a contract that had this exact phrase: “No changes will be effective unless and until memorialized in a written change order signed by both parties.” This is not an agile-friendly statement, and these terms are not conducive to a true agile process that would benefit both parties.

So there is clearly more work to be done from the contracting side of agile software development. If we want to see agile software development contracts that are truly aligned with the interests of all parties involved, there are a few steps we need to take.

Align contracts with agile software development teams

First, we start with the facts. There are three variables in any project: cost, time, and scope.

Next, in order to write a legal contract that aligns with agile software development, we must determine which of the three variables we want to constrain. For a true Agile software development project, one and only one variable can be fixed. The other two must remain flexible. Otherwise, the contract will not align with agile development. Period. 

Sure, the development team on the ground can work in sprints, pair, practice TDD, and do continuous deployment. But at the end of the day, the contract can’t align with an iterative process if it has fixed more than one of these three variables.

What does “Cost” mean?

It’s completely fair for the company paying for the project to ask “How much will this cost?”  

The key to answering this question correctly is to understand what ‘cost’ means to the person asking the question. 

• Are they considering the project an investment and if so, what is the expected return on this investment? 
• What is the cost of delay? 
• What is the cost of failure?
• What is the cost of rework? 
• How much time will the project take?  

All of these questions are ways to look at ‘cost’. 

Cost is important. Correctly framing cost makes the conversation—and the work—about value, not just money.

Sometimes, it’s not about the cost

Sometimes, there’s a critical deadline approaching, such as the end of the fiscal year, or the holidays. In this case, it might make more sense to fix the “time” variable than the “cost” variable.

And in other cases, the scope is specifically defined, whereas both cost and time are flexible. In these cases, it makes sense to fix the “scope” variable.

Once we can agree on which variable will be constrained, we can move to the next step, which is to craft a contract that makes sense. (If folks can’t agree on which variable to fix, skip ahead to option 4.)

Four options to align your contract with your agile team

Option 1: Cost -  write the contract to have a fixed budget.

It is critical to note that “fixed budget” is different from “fixed price.” “Fixed price” is a term often used to imply that both scope and money are predetermined, which is not Agile. “Fixed budget” constrains only cost, not scope.

When writing fixed budget contracts, I’ve used language like this:

The engagement will begin at or around [date]. The hourly rate will be $[amount]/hr. Based on this hourly rate, and the estimate discussed, the total engagement is estimated to cost approximately $[amount]. The budget for this Engagement will not exceed $[amount] (the “Term”).

In this case, you give an estimate, which is ideally close to the budget, and then commit to not exceeding that budget. When a project has a fixed budget, expect to continuously re-prioritize and revise the scope. This helps maximize the return on investment by ensuring we are continuously building the most important features. 

Helping teams determine the “must-haves” vs. the “nice to haves” can be integral, because a fixed budget requires that we either stop building when we hit that budget, or consciously decide to increase the budget. Keeping an open dialogue here is very important.

Option 2: Time - write the contract to have a fixed length.

When time is the fixed variable, I’ve used language like this:

The engagement will begin on October 1, 2014, and will end on January 1, 2015. The hourly rate will be $[amount]/hr. Based on the hourly rate of $[amount], and the estimate discussed, the total engagement is estimated to cost approximately $[amount].

In this case, you still want to give a cost estimate, and make it clear that the project will end on a certain date.

Option 3: Scope - write the contract to have a fixed scope.

This type of contract is the hardest, because it must clearly outline the necessary features and outcomes of the project that will be delivered. For fixed scope contracts, I’ve used language like this:

The engagement will begin at a mutually agreed upon date on or around [date]. The hourly rate will be $[amount]/hr. Based on the hourly rate of $[amount], and the estimate discussed, the total engagement is estimated to cost approximately $[amount]. 

The agreed upon features for this engagement are: [features].

With a fixed scope project, you want to ensure that everyone understands that both time and cost may have to increase in order to ensure that the agreed-upon features are delivered. 

Fixed scope is a slippery slope - because defining features up front is very challenging. Expect features to become clearer as you get closer to building them. Also expect features to take varying amounts of time,  based on what the software looks like when you start to build the feature. 

Option 4: If all parties involved cannot agree that one and only one variable can be fixed, you have to make a business decision.

In essence, if someone requires fixing both scope and money, they are asking for a fixed bid. I personally avoid fixed-bid projects 95% of the time. Every once in a while there’s a compelling reason to work within such constraints, but most of the time there is not.

Trying to complete an agile project under the constraints of a contract suited to another type of process will make life for the team very difficult. So be sure to begin any agile project by having a conversation with the client about these variables and determine what is critical. This will ensure that you’re all on the same page about workflow and expectations, and that the contract reflects what you are actually doing.

Editor’s Note: This post was originally published in October 2014 and has been revised and updated for freshness, accuracy, and comprehensiveness.