I was recently asked to be an Expert Agile Witness in a legal battle centering around agile ways of working. I was pretty excited about it – I’d never been an expert witness before and based on the various TV dramas I’ve seen, it looks like the best way to be involved in a legal dispute. So I prepped myself for what I hoped would be an enjoyable time.
The case revolved around the agile contracting approach used for an application development project. The buyer of the solution was the plaintiff and the vendor was the developer of the solution and the defendant.
The plaintiff sued because they did not get a final working solution at the completion of 2 contracted statements of work (SOWs). The first SOW for Phase 1 was for the discovery and proof of concept phase and the phase 2 SOW was for development. Does agile ways of working guarantee a final working solution? The buyer did not get a final working solution and that was the crux of the issue and the lawsuit.
Just before the case was set to go to trial, the plaintiff settled out of court, indicating that they didn’t feel that they had a solid case. I believe it was my expert opinion that made the difference but who knows. In any case, there were some great takeaways from this experience.
Key Takeaways – Agile Contracts:
1. Establish Trust before Contracts
Contracts rarely protect you from problems in business relationship. Sure they can provide some guardrails but if you have to go to court, there is a significant risk that it is going to hurt both of you. That should be avoided if at all possible.
In my opinion, it is all about trust. Can we trust each other to work together on this and work through the inevitable challenges that come up? If not, find another partner.
I also recommend that you get verbal agreements before spending the time to write contracts. If we can agree in our discussions, then putting things down on paper becomes a formality.
This is not a new idea – in agile, we use user stories because we recognize the limitations of the written word. Used properly, user stories make conversations the focus, not documentation.
Another thing we can do is limit our risk by trying small, contained experiments. For example, a short, fixed price discovery phase can be used to help both sides better understand the problem to be solved and how they might solve it. Note that in the case I was involved in, they did exactly that and it did not help.
2. Avoid Agile Jargon Especially MVP
A lot of the conflict in this court case was around the Minimum Viable Product or MVP. I’ve written about the problems with the MVP before. It is widely misused and fraught with confusion and misunderstanding. Avoid it! What does it mean? Does it mean what Eric Ries says it means:
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
— Eric Ries, The Lean Startup
OR, the one by Frank Robinson who is credited with coining the term:
“The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.”
— Frank Robinson from SyncDev, How it Works (retrieved from Web Archive)
As you can see, there is a big gap between these two definitions. The Ries definition could be a paper prototype. The Robinson one is a minimal product. Which is correct? Why argue about it?
Rather than using the term MVP, which was at the heart of the dispute, discuss and then document what is expected as a set of outcomes. And make sure that is aligned to the product backlog.
3. If You Really Mean Fixed Price, Timeline and Scope, Just Say So
Sometimes you will get agreement to use Agile but in reality, the customer is thinking Fixed. Fixed Scope, Fixed Timeline and Fixed Price. The language of the contract needs to match the intent of both the provider and the supplier. Don’t write an agile contract for a fixed project and vice versa.
Fixed contracts have been the traditional approach for contracting software development. Unfortunately, only 1 in 3 fixed projects succeeds so there is a huge risk that an engagement will end up in court.
The challenge is that most organizations still use annual budgets and projects. The buyer for application development needs to have an approved budget. They typically can’t (or won’t) sell the idea that the final cost and scope of their application development project is unknown. They need to project certainty in order to get the funds.
Another challenge that can contribute to this problem is that purchasing departments don’t understand agile. They may hear that the team is going to use sprints and deliver an MVP but their standard purchasing documents are all based on fixed scope and timeline. They don’t have or even understand an agile contract.
So they agree to agile and to delivery by sprints and an agile contract. But they are thinking about fixed price and the contractual documents are written as fixed price, fixed scope and fixed timeline engagement. Bad idea.
4. Don’t Set Quality Up to be the Fall Guy
Fixed projects usually result in poor quality. After all, if you constrain the scope, timeline and budget, you are guaranteeing that the team will choose quality if and when those other constraints cannot be met.
Instead, have a firm definition of done that is agreed across the customer and vendor team. This is pretty typical for an agile project. However, if you are using a fixed project approach rather than agile, you are going to wind up with poor quality.
5. Get Clear with all Parties on the Product Owner
I am a big fan of the Scrum Framework. Used correctly, there are clear roles and responsibilities and clarity about who is responsible for what.
That said, many people throw around Scrum terms and titles without clearly defining them. For example, in the court case, the contract stated that the client would be the Product Owner (PO). Now that is clear for anyone who understands Scrum and applies it correctly.
But what about the average Joe buyer in a company. Product Owner could simply mean I own the product – that I pay for it. If you are not aware of Scrum, you may not realize that the Product Owner:
- Makes decisions about what is in scope and out of scope
- Makes decisions about the priorities which directly affects the sequencing of the development
- Directly steers development through the backlog
- Is accountable for the value that the Scrum Team delivers
In an agile development project for a client company, the PO role belongs on the client side. That means the client makes the decisions about priorities and what is going to be built. It is not simply a figurehead, like project sponsor, that occasionally gets a status update. This is a full time, sleeves-rolled-up and hands-getting-dirty role.
For my court case, the client was described as the Product Owner. Unfortunately, they seemed to act like a project sponsor. But the court case they filed was based on them not getting what they wanted. If the Product Owner was a true product owner, they would have gotten exactly what they prioritized.
6. Recognize and Reward Transparency
I spent some time in the consulting arm of Unisys back in the day and I got involved in a number of client projects. It was pretty common behavior for the delivery team to avoid sharing too much information with the client, particularly when it came to bad news. This is the exact opposite of how you want to behave.
Recognize and reward people for being transparent and honest about progress and that includes bad news. Sometimes the idea that you cannot share that information with a client is exactly opposite what would be desired behavior. This is all about short feedback loops. And though I am not a fan of failing, failing fast is the idea that if you aren’t going to succeed, it is best to know that as soon as possible so that you can minimize the loss or pivot your development.
7. Money for Nothing and Change for Free
Jeff Sutherland penned an article about running agile contracts back in 2008 and used the title Money for Nothing and Change for Free. Money for nothing meant that the client can terminate the contract at the end of any sprint and get their 80% of their unspent money back.
Change for Free means that the “customer shall be able to make changes to the Scope without incurring any additional cost if total Scope of contracted work is not changed. New features may be added for free at Sprint boundaries if items of equal scope are removed from the contract.” Both of these agreements are predicated on the customer’s full participation in the Scrum activities.
In the court case, this is what the vendor tried to put in place. Or rather a variation of this. They said that the scope consisted of 3 specific items that were required, as well as a number of items that were flexible. This second category included items that could be removed and replaced with equivalent effort items. The contract was all about what the client did not get and that included some of those items that could be replaced.
Bottom Line for Agile Contracting
I was a little disappointed that the case settled just a week before going to trial. I didn’t get my chance to take the stand in defense of the agile developer. But I did learn from this and I hope you did as well.
Even though Agile ways of working as we know them have been around for over 20 years, there is still considerable confusion over how they are used. When you write an agile contract, watch out that people aren’t inadvertently using the paradigms of yesterday. The best written contracts won’t protect against that.
Here are some additional resources for those of you contracting for agile services:
- Craig Larman and Bas Vodde created a great article called Agile Contracts Primer. It is based on their excellent book, Practices for Scaling Lean and Agile which is a must read for anyone practices agile ways of working for multiple teams or an enterprise.
- As I mentioned previously, Jeff Sutherland wrote about this back in 2008. Check out Sutherland’s 2008 Article, Money for Nothing and Change for Free.