Does it make sense to estimate software?
Imagine hiring a crew to build you a software product. You have a good idea, you have the funding, now you need to build it and put it in…
Imagine hiring a crew to build you a software product. You have a good idea, you have the funding, now you need to build it and put it in front of the customers. Exciting times!
But there is a problem
Wait, what kind of problem? Here’s the thing: the crew of software creators we’re negotiating with refuses to engage on the project for a fixed price.
We don’t like that. Why? Because moving into the project with an open-ended situation where the crew is billing us per hour leaves us vulnerable to unpredictable eventualities. Where is our guarantee that the crew will not view this project as a cash cow, something they can keep milking while taking their sweet time to build the digital product? That arrangement could quickly bleed us dry!
Well, they of course claim high degree of professionalism, stellar references, top-notch integrity, yadda yadda yadda. Still, from our side, that’s just nice words, nice sentiments. They are selling the sizzle — we want to see the beef.
Time is running out, and as we’re trying to negotiate different deals with some other software crews, we quickly come to the realization that the competition is stiff, and we are at a risk of missing the boat in this venture.
Let’s negotiate
OK then, let’s try and drive a hard bargain. We return to the negotiating table with the original crew and ask hard questions: how will we know that you won’t be fleecing us?
Their answer catches us by surprise: we offer to build your digital product in a piecemeal fashion.
“What do you mean by piecemeal fashion” we ask.
“First we deliver the bare bones minimal product that is fully functional. You can put that product in front of the customers, get them engaged, while we continue to embellish and enhance the product”, explains the account manager.
“Hmmm, that sounds a bit iffy to us” we push back.
“Why?” inquires the account manager.
“Well, we don’t see much difference between that approach and the originally proposed approach, where you’d be just billing us by the hour while you keep going. We don’t see how will that work. How long will you keep going like that? How many times will you be doing that ‘piecemeal delivery’? We need some detailed, itemized estimates before we would consider your proposal.”
“I don’t understand — why would you need estimates?” continues the account manager.
“We need estimates in order to protect ourselves from runaway costs of the project. If you had agreed to quote us the fixed price on the delivery, detailed estimates wouldn’t be of such high importance to us, because we would feel protected from the runaway costs.”
“But you do realize that if we were to agree on the fixed price, we would then feel highly motivated to compromise on the quality of the product?” account manager asks point blank.
That question catches us by surprise. We were not expecting that a vendor would openly admit that type of malpractice. But hey, at least they’re being candid and transparent!
“OK then”, we throw our hands up in the air, “walk us through how do you envision this partnership working?”
“Here is the deal” continues the account manager. “We propose a mutual agreement whereby my crew works on delivering desired functionality every X number of days. Say at the first few iterations, we will deliver brand new functionality (of your choice) once a week. Then, as the momentum picks up, we will switch to delivering brand new functionality (of your choice) every business day.”
“Wait, how do you mean, every business day?” we are getting a bit confused now.
“Simply put, at the end of each business day my crew will do its absolute best to ship brand new functionality to your customers while making sure that nothing that is already working gets impaired in production”, explains the account manager.
“OK, we get it, that’s nice, but again, this smells to us like a potential runaway cost curve. You just keep adding brand new functionality every day, we keep paying you. When do you know you’re done?” we’re still feeling very uneasy about this plan.
“We have no idea when we’re done. It is up to you to tell us!” replies the account manager.
“Ah, okay, it’s starting to make a bit more sense now”, we’re starting to see the light at the end of the tunnel.
“So, let me lay it out for you: we come to an agreement that my crew will continuously deliver brand new functionality on a daily basis. That means that each business day you will be able to see some functionality in your product that was not there on the previous day. And I emphasize — that functionality is something that you, not us, choose.
We will therefrom bill you for our work on a daily basis. At any point in time, if you feel that we have delivered enough, or if you feel that, for whatever reason, you don’t want to pursue this venture anymore, all it takes is a quick call and we will disengage the crew. That capability will be stipulated in the contract we are proposing to mutually sign today.
What you, the client, get in case my crew was asked to disengage is a fully functional digital product, deployed in production. Your customers can continue to use that product for as long as it makes business sense to you. Yes, that digital product may not be equipped with all the bells and whistles that you wish it had, but at least it’s doing something useful. And that useful functionality is something you chose for your customers.
You see, you are free to discontinue and disengage at any point in time. We are proposing to make small deliberate steps in this project, with each step being fully interruptible by you, the client. Once you decide to pull the ‘Andon cord’ (i.e., to discontinue the project with us), we will immediately stop billing you and will make sure we leave the thus far built digital product in a fully functional shape.
Later, you may decide to revive the project, or you may decide to fully decommission it. It’s totally your call, and has nothing to do with us.”
“Oh, I see!” we exclaim. “You know, we like that. Minimal, almost no risk, and if we continue financing this project on a day-to-day basis, we can be more relaxed and will witness how is the progress unfolding, without becoming anxious, nervous, or even panicky! And who knows — maybe as we keep going like that, we will hit our mark sooner than expected?”
The happy ending is that we decide to go with that crew, and we shake hands to acknowledge our mutual agreement. Let the product building commence!
Wait! What about the estimates?
Notice how there was no mention of any estimates in our final agreement? Why is that?
Well, if the crew that’s building and shipping our digital product is releasing new functionality every business day, and billing us only for that small amount of work they’ve done, what would be the point in slowing them down and insisting they drop whatever they’re doing and come up with some estimates? There’s no point in doing that. We’re already receiving value on a daily basis, it is clear to us what we’re paying for, and we hold the reins in our hands — we can pull the plug on this process at will, knowing full well that we’ve got our full money’s worth.
It is clear that if the process of building and shipping software gets broken into small steps, any need for estimates disappears. It is only when working on large chunks, and the work spills over into days, weeks, months, without customers seeing any of the proposed functionality, that people get nervous and start asking for estimates.
So, the moral of the story: think big, work small, forge good partnership with your clients, and you won’t have to waste your grey cells on the process of meaningless estimation.
Note: Many thanks to Woody Zuill (https://twitter.com/WoodyZuill) for reviewing this article and for suggesting useful corrections. Woody is the original creator of the no-estimates movement, and I owe him a great deal of inspiration for writing this article.