Beyond #NoEstimates – Why the traditional software contract must die

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

doctoryorkeIT’S TIME FOR A SEQUEL TO #NOESTIMATES

The #NoEstimates debate/movement is in its 3rd year. Many of the principles upon which it is founded were being used by practitioners many years earlier. The Agile Manifesto, along with its statement “Customer collaboration over contract negotiation”, is approaching 13 years old.

I feel it’s time to start addressing the “barriers to entry” of #NoEstimates. I (and others) have banged on enough about the whys and wherefores of not estimating. Let us now start discussing ways of solving the problems that force us to estimate, or at least give us the perception that we must.

I’d love it if the Agile community would join me!

THE DIFFICULT 2nd ALBUM

In order to be able to work this way, there are fundamental impediments that we must remove.

And one of those is the traditional software contract. It may be the most important of the impediments, particularly when we are talking about doing work for external customers.

The way such contracts are negotiated and executed remains largely driven by up-front thinking such as plans, schedules and estimates, and tainted by paranoid contingencies for failure to deliver things to the letter.

Both #NoEstimates and Agile promote continuous value delivery, i.e. to always be building the next most valuable thing for the customer, and delivering this in rapid vertical slices. With such a desirable working agreement in place, the need for a fixed price contract built around an up-front estimate of everything to be delivered is negated.

But in order to be able to work in such a world we need to build trusting, flexible and collaborative working relationships with customers. Some have made attempts to create more “Agile” contracts, but legal constraints coupled with a resistance to changing long-established practices often render these as not hugely different in essence from traditional contracts.

That is, most of the attempts I’ve seen at Agile contracts remain constrained by the legacy of analysis, design, development and testing phases, a focus on delivering agreed scope (output) rather than solving a problem (outcome), and a desire to try and eliminate uncertainty rather than embrace it.

SO, WHAT NOW?

I believe we need something more radical, and I would like to explore this with any interested folk. To my mind, the whole premise behind the traditional software development contract – nailing down the detail of what will be delivered, when and for what price, and covering both parties legally should things go wrong – needs to be addressed.

For customers to gain the benefits of Agile, and for suppliers to be able to deliver with Agile, working agreements and relationships that truly embrace an iterative, incremental and emergent approach to building software need to become the norm.

Working agreements that start from a position of trust rather than distrust. Working agreements that embrace “Here’s what we will build together” over “Here’s what you must deliver or we’ll sue you”. Working agreements that allow parties to use empirical process control to manage risk and uncertainty rather than up-front predictive models that make significant change impossible.

BEYOND CONTRACTS, TOWARD AGILE WORKING AGREEMENTS

How would I structure working agreements with customers that are compatible with Agile and #NoEstimates principles?

I think we need to move toward a model that embraces the following:

  • All work is custom work
  • Setting expectation level of quality for the customer’s budget or desired timeframe using an approach akin to a designer’s portfolio
  • Focus on “build the right thing” rather than “build the thing we think is right”
  • Replacing fixed price with incremental pricing (including “cut the cord at any time”)
  • Replacing fixed scope with required outcomes (which we are happy to change)
  • Reducing risk by using true iterative development cycles (Build – Measure – Learn) and empirical process control to evaluate progress toward outcomes
  • Only thing nailed down up-front is an agreement that the supplier will continually deliver the most valuable small increment of product to the customer
  • Don’t just welcome change – embrace changing requirements, via a change of mind or emergent learning, for the customer’s competitive advantage

DON’T BE CONSTRAINED BY THE CONTRACT

I have been a part of teams delivering hugely successful outcomes in an iterative fashion, despite the apparent constraint of a traditional contract.
How?
By building a trusting, collaborative relationship with the customer and continuously delivering, adapting and delighting.
In such a situation, the contract becomes irrelevant, because the actual day-to-day working arrangement and relationship has trumped its significance.

WHAT NEXT?

I’d like to explore this topic by starting with the following assertions:

  • Traditional software contracts render attempts to deliver in an Agile way moot
  • Empiricism and iteration are extremely beneficial to delivering successful projects, but are absent in both traditional and (previous attempts at) “Agile” contracts
  • Agile working agreements must allow parties to benefit from the risk management and other advantages that empiricism and iteration provide over scope/price-driven contracts
  • Existing/previous ideas for Agile contracts don’t quite fit the bill

Who would like to join the discussion?

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

12 thoughts on “Beyond #NoEstimates – Why the traditional software contract must die

  1. The big barrier to this is that lawyers are paid to reduce risk, particularly where it is not accompanied by the power to influence outcomes.

    Thus: I can control whether I deliver the thing you asked for. I can’t control whether you asked for the right thing, or use it in the right way. I will therefore accept the risk of non-delivery of outputs, but not outcomes, unless I also have influence there, or can make you doing The Right Thing a contractual obligation, tied to my obligation for outcome.

    From the customer’s PoV, their risk is of higher cost. I’ve worked in companies that really did want to share in the risk, but to do so would also want to share in the reward. And the customers really didn’t want to risk paying significantly more for an outstanding business outcome, even though (as a %age of outcome) it would still be a hugely positive business case.

    My worry is that to do this, we may need to change our legal system’s understanding of contract law and liabilities.

    1. Many thanks for your comments Martin.

      I agree with you. I fear that the legal barrier is the key one, and the chances of that changing any time soon (or ever) are slim.

      A more viable model to move toward might be a Build The Right Thing charter, coupled with a collaborative working arrangement. I know from experience that this can be done. The working relationship based on dedication from both sides to The Right Thing renders the actual contract as something that sits very much in the background, and thus is not significant in practical terms.

      1. If you can persuade your customer that this isn’t just a charter for everlasting uncontrolled billing, to the level that they’re able to control their own procurement and legal people, then yes, this sounds good.

        Actually, it’s not dissimilar to a standard T&M framework agreement with guaranteed minimum revenue, but it does place a lot more risk on the customer side.

  2. Perhaps rather than looking at contracts being an impediment to agile delivery, we should not concern ourselves with them. One of the biggest impediments to convincing clients that an agile approach will benefit them is previous experience with software projects.

    If we look at other industries, professionals are regulated e.g. Accountants are chartered, Lawyers have to pass certain examinations to be allowed to practice. Anyone who can open up a text editor can call themselves a programmer. If there was a chartered society that programmers had to belong to in order to practice and sell to clients, then we’d have a lot less worry about agile vs waterfall with clients. Until the day comes where trust can be relied upon with software development firms, then clients will always favour waterfall type projects for the ability to be able to nail the vendor to the wall for failing to deliver.

    1. Professionals in the legal and accountancy fields are regulated because their professions are generally governed by a legal framework, normally put in place at a national level. E.g. to be an accountant, you have to know and demonstrate knowledge of your country’s tax laws (among others). To be a lawyer, well, you clearly have to demonstrate knowledge of your country’s laws.
      Software development is not a governable profession. There are no software laws, or national-level software frameworks (except if you’re delivering software for a government agency, in which case, you’re fully expected to over-charge, and be years late!)
      OK, a bit off-topic, but I wanted to at least respond to your comment about trusting developers.

  3. Neil, I am curious to know what issues you see in a T&M contract ? Usually there is no fixed scope there but a mention of high level business objectives, a vendor working model and quality of service with clauses to take care of disagreements. What I have observed is that you can iterate on your contracts as you build trust by delivering to your customer.

  4. I really think that this is the future. For Agile and BDD practices to be truly effective business stakeholders need to have wholeheartedly embraced flexible scope & made the paradigm shift from IT as a cost to IT as an investment.

    If we facilitate these discussions well with our business stakeholders and help them focus on outcomes and learning opportunities rather than features we can achieve this.

    We help bridge the gap between IT & business teams and really add value by enabling ‘agility’ rather than ‘doing agile’ We then achieve a relationship more like a strategic partnership rather than a client/ supplier relationship

  5. Hey Neil, you’ve piqued my interest. I’m keen to see where you go with this. One observation from my perspective is that perhaps you’ll need to do a bit more of a forensic analysis of “why” contracts exist before looking at new ways of working.

    Instances where I’ve seen the contract become important in the past have been when things have gone awry – i.e. the expectations of the client are not being met by the vendor. The contract becomes a tool of last resort to try and bludgeon an outcome and relationships had inevitably already soured beyond repair. I’ve never seen a project that has recovered by virtue of using contracts but I’ve seen a few companies taken to the wall by entering into bad contracts.

    For mine, you’ve got a set of problems that could be fixed by taking a different view of contracts and project behaviour, e.g.

    1. Companies that sign vendors up to fixed price contracts without having a full understanding of what they want
    2. Projects where challenging objectives and dates are published to either the market (publicly listed companies) or to the broader stakeholder group (government organisations) and then enforced in contracts

    But you’ve got a set of problems that you still need to protect against:

    1. Vendors that promise capability that they simply don’t have
    2. Vendors that enter into agreements with the intention of maximising profits rather than delivering outcomes
    3. Clients that enter into agreements with the intention of forcing their vendor to the wall
    4. Vendors that sign “loss-leader” contracts that they know they’ll lose money on in order to pick up the downstream PS&M profits

    I love the idea of trust based charters and engagements but they’re the kind of thing that work in a perfect world where vendors exist solely for the benefit of their clients. Most vendors have a primary goal of remaining viable and profitable that under certain conditions might get in the way of a more purist ideology.

    1. Andrew does seem to describe what constitutes most of the real world, clients looking for products and services but with ‘caveat emptor’ always on their mind. Building the relationship between Business and IT needed for #noestimate is tough enough within an organization, so the odds are stacked against it between buyer and seller. Not impossible, but not too likely either.

      And ‘buying’ is the key misunderstanding in these relationships, because the client is not buying something they can see and try. A completely different case is purchase of package software, COTS, where indeed the client can see the product, run a trial, ask previous buyers about their experience, etc.. Not every COTS purchase and install goes perfectly, but odds of success are much higher.

      When the contract is about creating new software, the client cannot do the same things as with COTS. The vendor can sell based on past successes but, like mutual funds, past success is no guarantee of future success when you are creating something you have not created before.

      My thoughts lead beyond building a temporary relationship to creating a more permanent link, like the client making a capital investment in the vendor so as to reap more of the benefits, especially as almost all good finished software is a candidate for the COTS market. That’s the advantage of ‘soft’ware: build it once, sell it over and over again.

      I think I have wandered off topic a bit; I usually get involved in projects after the ‘sale’ has been made, but I do know how tough making sales can be. In the specifics mentioned elsewhere in this post and comments, time and materials work with client able to ‘cut the cord’ anytime would make it hard to make a vendor successful; as a sales guy, I take months to close the sale, and client cuts the cord after the first iteration? brutal…

  6. For projects which don’t use a contract, e.g., software vendors developing their own products, I think there is an implicit contract/schedule/estimate. I suspect even in those cases, empricism (?) gets a lower priority than the estimate.

    It may be worthwhile to keep reinforcing the #noestimate ideas for teams who don’t use a contract.

    I also think getting people to change contracts may take more time and effort.

  7. Neil – with you 100%.

    This has been something that for the first decade or so of agile practices (eg. 1993-2003) have largely been left off the table. While folks like Jeff Sutherland and Mitch Lacey have suggested how to bake-in accommodations for working with agile (see my post on Three Contract Models for Scrum[1]) these are at best stop-gap measures. In these “partnering” contract models, we’re not really any closer to driving out a collaborative agreement that lives up to the ideals in the manifesto – in fact, we have the opposite: A document that legitimises self-interest.

    There are better alternatives.

    One place we can ironically look to for inspiration is the construction industry, who long-ago realized that low-trust, punitive agreements that took months if not years to craft were a waste of time and money, and in the end, not reliable for fostering a non-adversarial relationship.

    The model they gravitated toward, over twenty years ago, is known as ‘relationship contracting’, or more commonly, ‘alliancing’. In a nutshell, when parties enter an alliance contract, they must first meet pre-conditions (much as you outline above). This gets them in behind the velvet rope and into what my Aussie friend Paul Culmsee calls a “holding environment”, in his book The Heretic’s Guide to Best Practices.[2] (what follows is a bit of a precis/summary from the book):

    Alliances differ significantly from their partnering counterparts in how participants are selected – price/cost isn’t discussed until MUCH later in the process, giving weight to minimum bar criteria – thus preventing distortions that money can introduce. The criteria to begin an alliance are typically stringent, eg.

    * Financial capacity
    * Technical and management expertise
    * Capacity to carry out the project
    * Track record in incorporating innovation
    * Track record on similar projects

    Perhaps most importantly, another KEY requirement is whether the participant has a corporate culture compatible with the alliance approach and a team with the commensurate commitment and skills to engage in this environment.

    And this is just a start – see his book for more details. It’s a ripping good, irreverent read on the follies of projects and how we can right the ship. I think you’re quite close in alignment with what he advocates.

    Chris.

    [1] http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects
    [2] http://www.amazon.com/Heretics-Guide-Best-Practices-Organisations-ebook/dp/B00D5S7C5K/ref=sr_1_fkmr1_2?ie=UTF8&qid=1396028242&sr=8-2-fkmr1&keywords=heretic%27s+guide+to+best+practices

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *