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’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?