#NoEstimates Part 2  - Contract Negotiation and the Old Banger

This is the second in a series of blogs about why I believe we should not be estimating software projects. The first post talked about estimating at the team level, whereas here I talk about the contractual level and how to arrive at more Agile, iterative working arrangements.

AGILE TEAM, SAME OLD CONTRACT

Traditional software contracts, particularly with external parties, are based on:

• Establishment of scope
• Estimated time to deliver that scope
• A price derived from that time + associated costs + profit margin

Many, if not most, of today’s software contracts are based on similar premises, even in supposedly “Agile” projects. In order to mitigate the risk of their deliverable running late and bumping up the cost, many customers demand fixed price contracts. Others demand that the supplier contractually fixes the delivery date to ensure meeting some obligation around the date and shy away from time-and-material engagements. Suppliers often like the fixed time approach as well because it creates predictability around cost. Fixed price contracts provide certainty around the project’s ROI, assuming it can be delivered at a low enough cost, and customers like to know how much they are spending.

There is nothing inherently wrong with any of these approaches or the reasons behind doing them. The problem lies in how we arrive at delivery dates and prices. In order for a contractual engagement between a supplier and customer to be worthwhile to the supplier it must deliver a positive return on investment. Usually this means that the money received from the customer for the supply of the product or service must exceed the money spent by the supplier providing it. So how do we balance that equation? Customers want certainty they will get what they want in the agreed timeframe and/or for the agreed price, while suppliers want to make sure they make a profit on the engagement. Seems simple enough. But what is missing from these scenarios? Even if both parties accept the well-understood iron triangle of time/cost, scope and quality, and that at least one of the three must be variable, is this enough on which to base a low risk and mutually valuable contract? I believe the answer is no, and not just because scope needs to be movable.

QUALITY IS VARIABLE, NOT FIXED

What?! Sounds controversial but I believe it to be true. In addition to the need for scope being variable, Agile folk also tend to talk about quality being fixed and uncompromising, meaning that time and cost can also be variable to deliver the best possible outcomes. Aside from the fact that leaving the cost and/or completion time of a project open is generally deemed an unacceptable way to conduct business, and likely why many businesses shy away from “Agile” contracts or working arrangements, I actually think it is un-Agile to fix quality. By this I’m not talking about code quality (the debate about what are bugs and acceptable levels of bugs in minimum viable and evolving products is for another blog post, another day). I mean quality in terms of what the customer defines as quality, and for me they are the only ones qualified to do so. IMO quality is an ever-changing variable in a project, just like scope. The difference is that the customer defines quality, either explicitly or implicitly, consciously or unconsciously. Scope, however, is defined by the supplier. Personally I think of quality in the context of products and services as:

“A subjective meeting of a need or requirement to the satisfaction or delight of the customer.”

If it is fair to say that what might delight a particular customer one day might not do so in 6 months time, and that what delights that customer right now may horrify another customer right now, I believe it is also fair to posit that quality ought not be fixed. I believe quality is what we should try and achieve, and it is what the customers want, but cannot fix what it means to achieve it. We will fail if we concentrate on time/cost and/or scope without making sure we are adjusting our delivery behaviour to suit the customer’s perception of quality. When we talk about projects being either “on track” or “off track” we always base it on our own interpretation of whether we are meeting the customer requirements. I believe the only way we can know if we are on or off track is by asking the customer. They are the ones who know what they want. And this will most likely change. And this is fine! Great, in fact! That’s why we’re being Agile, and why they signed an Agile contract, right?

DON’T DELIVER THE REQUIREMENTS, DELIVER WHAT THE CUSTOMER WANTS

Delivering all the scope the customer wants may not actually delight them. It may even annoy them. Or cost them big time. They’ve hired you because you’re an awesome web design company with a great track record. They love your previous creative, innovative designs. And now you have done exactly what your customer has told you to do and it looks crap because your customer does not have a flair for web design. They are the customer, you are the supplier. You are the expert in what you do. You should be telling the customer the scope that will meet their requirement, not the other way round. And they should be telling you whether you are meeting their requirements or not. I believe you can never be “on track” in a truly Agile project, at least in a Gantt chart or velocity-based-Agile-release-plan sense, because the entire fabric of what you are building can change at any moment. If the contractual arrangement is done right then change is absolutely fine, to be expected and welcomed.

AGILE CONTRACTS — THE REALITY

So what really is an Agile contract?

Fixed price contracts are fine. Fixed time contracts are fine. But here are the caveats:

• Do not fix time based on an estimate of cost because that inherently means you are agreeing to up-front scope detail that will likely bite you on the arse later and restrict the customer’s ability to request changes (and yours to welcome them) for their competitive advantage
• If the customer does not fully understand and embrace the inherent unpredictable, creative and innovative nature of quality software solutions then work with them at your peril
• If you don’t want to turn away work so you try and agree scope with the customer because “they insist”, and then base dates and times on estimates, do not pretend this is an Agile contract and make sure all parties understand the implications of this
• Know your costs by having a fixed team and determine a “final” delivery date, or allow the customer to determine it
• If the delivery date is acceptable to both supplier and customer then you now have a certain delivery date, no guesswork required; if the customer wants delivery sooner, reduce the price AND the expectation of quality
• When you purchase something more cheaply outside of software, e.g. a cheap old banger of a car, you can assume you will likely receive a lower level of quality — why is software any different?
• Negotiate a flexible, iterative, drip-funded contract that allows the customer to retreat early (either because they’re already happy with their product or because they’re not happy with the progress; if it’s the latter learn from their feedback, improve and move on)
• The aim is to delight the customer and make a profit so do not simply do what they ask you to do; they are buying your expertise and guidance for meeting their need, so don’t take this responsibility lightly and think you’re serving the customer simply by “delivering customer requirements”
• Deliver early and often (duh!); iterate, don’t just increment, and make this part of the working agreement
• If possible give the customer a sense of the kind of outcome they can expect for varying price and/or delivery times (based on previous work done by your company) and given them options to “upgrade” or “downgrade”

REMEMBER WE’RE SUPPOSED TO “WELCOME” CHANGE?

Yes, don’t try and fix scope. But be prepared to move around on quality also. Allow the customer to accept an earlier version of your product because it does the job and they’re delighted they don’t need to spend any more cash on achieving their desired outcome. Or to love their product so much that they now want to spend more enhancing it. This is variable quality, in my book. Variable scope refers to the cost-side of building software; the amount of work we need to do to reach a specified outcome. Variable quality refers to the value the customer feels they are getting. It’s subjective, dependent on the customer and their particular circumstances. Delivering high value outcomes to the customer may cost more than lower value outcomes or they may not, depending on what the customer feels about the iterative outcomes. That “old banger” that you bought for $1000 may actually provide very high value and quality to you personally. Or it may be housing a classic engine that you didn’t previously know about, giving it emergent value. To someone else it’s a worthless piece of junk.

In the same way software solutions, products and services are entirely subjective in their quality. Some people think Microsoft Word is awesome and feature-packed and they base their entire business operations around it. Some think it is terrible, buggy and doesn’t do anything they want it to do. Let’s not pretend that delivering “quality” software is a predictable outcome any more than fixed scope is.

Variable quality pertains to the wonderful opportunities we ought to have with Agile software development for correcting the course and building the right thing; truly welcoming and embracing change for the customer’s (and our) benefit. This is what Agile contracts should be about IMO. Remove the uncertainty of time and cost by making them certain, and celebrate with your customers or suppliers the uncertainty around exactly what will be built. Why not consider basing your contracts on a mantra more along the lines of:

“We guarantee we will work with our customers’ time and budget constraints to iteratively build and evolve a delightful outcome to an agreed level of expectation?”

And for everyone’s sake, we should not be estimating in order to do it.