Agile has been around for 13 years. That seems like enough time for companies to adapt to agile processes and get the hang of writing agile contracts. Yet when it comes time for a company to enter into a contract about agile work processes and deliverables, we’re still seeing Waterfall language persist.
Don’t believe me? Last week, I 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.
First, we start with the facts. There are three variables to any project: money, time, and scope.
Next, in order to write an agile 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, it is not a contract that aligns 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’s fixed more than one variable.
Who gets to choose which variable to constrain? The person paying for the project (otherwise known as the client).
Many times, the person paying for the project wants to know “How much will this cost?” That’s a fair question, but framing the cost question in a different way will help them constrain the “money” variable in the contract. I love the way Johanna Rothman puts it in a recent blog post, where she advocates asking, “How much do you want to invest before we stop?” She goes on to say that “no business exists without managing costs. In fact, the cost question might be critical to your business. If you proceed without thinking about cost, you might doom your business.”
Cost is important. But framing cost as investment makes the conversation—and the work—about value, not just money.
Sometimes, it’s not about the cost. Instead, there is a 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.
And in other cases, the scope actually is quite defined, and both money 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 both parties can’t agree on which variable to fix, skip ahead to option 4.
When writing fixed-budget 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 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 limited budget, we often have to continuously prioritize the features. 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.
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 something I’d recommend. Fixed budget constrains only money, not scope.
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.
This type of contract is the hardest, because it must clearly outline the necessary features and outcomes of the project that will be delivered. 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 the client understands that both time and cost may have to increase in order to ensure that the agreed-upon features are delivered.
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 take one, 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.
These Stories On Process