Following the interview with Vasco Duarte about his recently launched #NoEstimates book, InfoQ spoke to him on how the #NoEstimates technique may apply to a contracting environment, facing tipical needs of sizing a project, establishment of agreements, signature of contract and building of trust.

InfoQ: How can we apply #NoEstimates as contract software developers?

Duarte: #NoEstimates is a set of ideas that can be applied to any software development endeavor with the goal of re-focusing that software development on value delivered, as opposed to following a pre-determined plan defined by tasks + estimates.

The basic idea of using User Stories instead of the traditional Work-Breakdown-Structure is already one step in the direction of #NoEstimates. As Bill Hanlon at Microsoft found out (see video with that story here) you can easily predict the release date of a project by just counting the number of Stories (assuming you respect the INVEST approach to defining stories).

The experiment results that Bill Hanlon shared with me tells us one thing: we can know the release date of a project without estimating the whole project in advance. So, coming back to the question, if what you want to know is when a project will be delivered, the answer to the question is easy: measure the rate of User Story delivery for your team, and project that over time to find out the likely range for when the known stories will be delivered.

In Software Development contracting (off-shoring, near-shoring or outsourcing) this is made easier by the initial focus on defining the necessary stories for the project (by using Story Mapping, for example).

InfoQ: As a contract software developer, should I be considering on applying a technique like this in my next project / contract?

Duarte: Normally this question is related to the fear of not being able to give the customer some critical information to their decision making process. Typically contract software requires that the provider know how much they can invest into the project (usually number of teams multiplied by time) and how much the customer needs to pay to receive a specific set of functionality.

So far, this seems logical. However, the real questions about the value being delivered are not being asked at the time when these questions need to be answered. Let’s take a concrete example that is familiar to many.

The customer will ask for a bid for a project (a certain scope is defined), then the provider goes through the process of estimating that project (now we have scope + time defined). The contract is finalized and signed, and we start developing. Let’s review what just happened:

• The customer defined a set of functionality (scope) before they really knew what they needed (they knew what they wanted, but knowing what you need requires feedback based on running software that will only be available later).
•  The provider defined an investment that they consider is enough for the customer to get what they asked for (the scope) in a timeframe that is acceptable (the schedule), and for a price they are willing to pay (the cost).
•  The provider has made a certain number of assumptions in order to deliver the bid or offer to the client: a certain team or at least team-size was considered in the estimates, a certain level of skill was assumed on the part of the team (to deliver / develop the software) and on the part of the customer (to be able to communicate, and reply to questions from the team).
• Importantly, in most cases the assumptions regarding time-availability, skills, and team-size made by the parties are not defined in the contract and therefore not discussed.

At this point the software delivery process is “set in motion”, and invariably at some point some “surprises” will emerge. Maybe some of the original developers are not available (they quit, or were assigned to another project), the customer is in a hurry to achieve some end-of-quarter targets and is not available to answer questions, etc. You get the picture: surprises happen.

What do we now do? Do we go and re-do the plan? Change the price of the original offer?

I have a different suggestion that I explain in more detail in my book about #NoEstimates. Instead of trying to define all the parameters up-front, let’s define only what is known and/or critical. Surely there must be a cap on the price of the project, so let’s define a budget. And quite often there is a person or people at the client side that are tasked with “approving” whatever is delivered by the contractor, finally there is a general idea of what the software should deliver. Based on this, another approach to delivering software would be:

• Define the investment-box for the project (the budget);
• Define the time/people allocation box for the project (another form of budget);
• Define a deadline and a cadence to deliver/demonstrate value (a constraint that guides the team to validate and deliver value regularly).
• Setup a regular, cyclic process by which you update the User Story backlog, project the delivery rate (how many User Stories done per week?) to assess the final delivery date for all the defined User Stories, and regularly review the delivery date against the budget.

This process, which looks very similar to Scrum (but without the estimates) is enough to provide continuous transparency to the development process, and at the same time ensure that the client gets what they need (not just what they wanted), and the team is able to manage the project to fit the initially agreed budget.

I explain this approach in more detail in the #NoEstimates book, and in a video interview for the book that I recorded with Sven Ditz, the CEO of Sitegeist in Germany. I also have an interview with Diego Cenzano CEO of Biko2 and 7 more interview with #NoEstimates practitioners to explain how the ideas in #NoEstimates are being used all over the world, for many types of software projects.

InfoQ: Many times, the first thing a contractor need to start working is a contract that is, an agreement. With #NoEstimates, what should be the baseline for the agreement?

Duarte: The agreement is necessary for any kind of contract. With estimates or #NoEstimates alike. Agreement is just another way to say that both parties believe they have more to gain than to lose from working together. Estimates have little to do with this, in fact if estimates were the single most critical factor in a contract we’d have much less contracts, and the reason is simple: estimation is reliably a bad tool to assess the actual cost of a software project. And the bigger the project, the worse estimation is for setting an acceptable upper-bound cost for the project.

• “Of the large systems that are completed, about 66% experience schedule delays & cost overrun”, “Project Management Tools and Software Failures and Successes” by Capers Jones, Crosstalk, the Journal of Defense Software Engineering
• In 2011, the average delay for projects surveyed in the CHAOS report was 63%. This number is in line with a private survey I did in 2003 in a software development company: of the 17 projects surveyed the average delay was 62% and the largest project delay was 200%.
• Scott Ambler runs a popular survey about project success in the software industry. His data from 2013 shows that 53% of traditional projects were failed (no solution delivered) or challenged (project did meet success criteria).
• Accenture famously got out of a 1 Billion British Pound penalty for a botched NHS project. Estimation was not the only thing to blame in that particular story, but the lack of incremental delivery that caused this failure is supported, and even encouraged by the belief in the tool we call estimation.

These are just a few of the many examples that each of us know personally. Estimation is an ineffective tool to set upper limits on costs for software projects.

So the base agreement in a provider-client relationship should be clear rules on regular, and verifiable delivery of value. If I am a client I want to define how long I can go without seeing concrete value delivery; and on the other hand, if I am a vendor, I want to know how quickly I can get feedback from the client to ensure that we are delivering the right functionality.

When the client is satisfied with the delivery, and does not require more work to be delivered, there should be an easy way to end the contract. Conversely, if the feedback form the client is not coming, and the risk of delivering something that is rejected later is very high, the vendor should have mechanisms to stop the contract until that feedback is obtained.

Building software is not like building a house, you cannot specify it all up-front (not even house builders do that), and it is flexible therefore it should be developed based on a mutually beneficial relationship between client and vendor.

InfoQ: Based on your experience, what kind of contracts are typically found? Are some of them incompatible to this approach?

Duarte: This is a very important question, so important that we asked Evan Leybourn to write a mini-ebook with the #NoEstimates book explaining the types of contracts and how they are important in building and managing trust between client and vendor. Without going into all of the details that Evan covers in that mini-ebook, it is important to recognize that some contracts support the use of mutually beneficial approaches (like #NoEstimates), while other contracts exist to shift risk (and blame) from one party to the other.

As an example, we can refer the fixed-cost, fixed-scope, fixed-time contracts as one example of a contract that is used in low-trust situations but that instead of building trust it further amplifies the mis-trust in the relationship. The vendor will be rewarded for (ab)using the change request provision in the contract (everything that was not defined in the contract is billed extra), and the client will be reward for arguing that every new idea was already in some way included in the original scope. The resulting dynamic is probably familiar to many, and the exact opposite of the 3th Agile value: Customer collaboration over contract negotiation.

On the opposite side of the spectrum we have organizations working without contracts (in the NoEstimates book I interview a CEO that does just that), delivering value every 2 weeks and continuing, or stopping the relationship based on the value that both organizations drive from the work they do together.

To be clear, these are extreme cases, but they illustrate a model that does not support the use of #NoEstimates (fixed time, cost, scope contracts) and the opposite which we could call #NoContracts that supports the use of #NoEstimates and is based on a constant focus on value delivery.

As Sven Ditz recommends in his interview for the NoEstimates book, you should not try to go #NoContracts with every customer. Some customers will be more likely to accept the idea of working without a contract (which also protects them legally), than others. We must find those that are willing to experiment and work with them when implementing novel ideas such as #NoEstimates or #NoContracts.

InfoQ: #NoEstimates means trust between at least two entities. What are your advices to start building trust?

Duarte: Great question. As we discussed when talking about contracts, trust is something we build over time and with several tools, contracts being one. However, there’s something very powerful to build trust available to all software teams out there: deliver early and often, something of value for the stakeholders. This Agile principle is one of the key tools we have to build trust. The other trust building tool is transparency, and that is what I focus on when I describe #NoEstimates. Some time ago I was talking to a Program Manager (manages several projects in a program) and we were trying to come to a conclusion if the teams (multiple projects) would be able to deliver the program on time. The Program Manager in question believed that the different project teams would deliver on time, and he had a good reason to believe that: he had asked the teams. The teams, in turn, had spent time estimating their projects and came to the conclusion (everyone of them) that they would be able to deliver on time.

“Great!” he thought, every team will be able to deliver on time. Turns out he was relying on estimates of each separate team, he never looked at the rate of delivery of the overall program (we were delivering on a single source base for mobile devices with many applications inside). I did, I used #NoEstimates to evaluate the throughput of that complete system, i.e. all the teams, together, delivering to one deliverable system. My view was different, I knew (not estimated) that the rate of delivery or throughput of all the projects together was not nearly enough to deliver the program on time. I had data and made the case to the Program Manager. He listened, politely, but probably thought I was crazy. After all, in Program (and Project!) Management school we are told that the project plan + the estimates are “the truth”. If each team, separately, had estimated their delivery to be on time, then surely the program would be on time. One year later (18 months into a 6 month program), the program got cancelled, and the company eventually went belly up (for many more reasons than that single program). It was a case where I felt sad that I was right. But in reality I was not right, I was merely the messenger. The system was right. The throughput of the system was telling that Program Manager that he, and the company would fail, but the Program Manager had never been taught to look at, let alone believe, system metrics. He had, like many of us, been taught to believe only human-devised estimates of future events, despite the very poor track record of estimates in our industry (see above).

So, to build trust: focus on measuring the system. Estimates only delay feedback (you find out you are late, too late), while using system metrics like throughput, cycle time give you the transparency you need to make decisions early in the project lifecycle, and with the added bonus that you don’t even need to sit down for long, drawn out estimation sessions.

To paraphrase Churchill: ultimately, not matter how beautiful the technique we use (estimation), we must occasionally look at the results. And estimation has a very poor track record indeed.

InfoQ: Vasco, I am pretty sure you have heard about Minimum Viable Product. Do you have a definition for the Minimum Viable Contract?

Duarte: Great question. Before we come to the definition let’s look at the characteristics we would like to have in a contract:

• From the Client poing of view, a minimal contract should:
  • Reduce the legal expenses, yet;
  • Provide legal protection against unscrupulous Vendors;
  • Establish clear rules for evaluating the success of the deliverables;
  • Allow the Client to receive compensation if the deliverables are not up to par;
  • Allow the Client to change Vendor in case the relationship is not sustainable anymore.
• From the Vendor point of view:
  • Eliminate the middle-man between Vendor and Client (e.g. lawyers) so as to create a transparent relationship;
  • Provide legal protection against unscrupulous Clients;
  • Establish clear rules for the evaluation of the deliverables;
  • Shorten the feedback cycle between delivery and approval to reduce the risk of having very much deliverables waiting for approval (and payment);
  • Allow the Vendor to receive fair compensation for their contribution (time, materials, and IP);
  • All the Vendor to fire the client in case the relationship is not sustainable.

Most of these requirements could be met with a simple agreement between Vendor and Client:

• The Vendor will work for periods of 2 weeks (or less) on an agreed overall goal, Feature or User Story collection and demonstrate in a live-like environment what they have been able to complete at the end of the 2 weeks.
• The investment for the 2 weeks of the iteration is defined by both parties up-front. For example: 3 developers/testers, 1 Product Owner, 1 Scrum Master.
• At the end of the 2 weeks the Client has the right to refuse what was delivered and not pay for it.
• Equally the Vendor has the right to stop working on the project at any iteration boundary (every 2 weeks in this example).

The rules above are very similar to what many teams are already using when they implement Scrum as their approach to software development. Estimates are not required for this approach, only early and regular delivery of value that satisfies the Client’s business needs.

Another advantage of the rules above is that the risk is so low (the investment for those 2 weeks), that both Vendor and Client can waive the need for a contract and simply work based on those rules. This approach is very similar to what Sven Ditz explains in his video interview for the NoEstimates book.