The #NoEstimates paradigm has now reached a new high. There is a suggestion that to do #NoEstimates, find customers that don't want estimates.
What a wonderful idea. I know let's find customers that will let us spend their money without having to tell them how much it will cost in the end?
That by the way, is pretty much how some DOD and DOE programs we work do it. But that doesn't make it right. That's doesn't even make sense, unless you don't really care how much money you're going to spend.
Now if "time box scheduling" is used, then I can see - maybe a little - that #NoEstimates might be interesting. Because I know how much it is going to cost and how long it is going to take. I just don't know what I going to get. The Agile paradigm solves that by "estimating" the Velocity of the development team, given some calibration process. What is our capacity for work? How many story points can we produce per iteration? This is an approximate number, with confidence level. 50% confidence is guessing. Can't go wrong with a 50/50 guess. Either we're higher than the guess or lower.
But spending other peoples money usually requires something greater than a 50/50 guess. How about a 75% estimate? That's be good enough to start. Then get calibrated as you go. But making an estimate pretty much is the price of entry any where I work for getting the customer to part with their money. Others may be able to find customers who will part with their money, in the absence of knowing how much they will have to part with in the end.
So if you can find a customer that will not ask how much and when go for it. I don't work in any of those domains. And when you hear people talk about #NoEstimates, ask them what domain they work in that the customer doesn't have a budget in mind, and a desire to know when you'll be done. And when they say the software domain, ask if they ever heard of Capers Jones and book Software Assessment Benchmarks, and Best Practices, which lists:
- IT systems - ERP
- Outsourced systems - "bespoke" but hosted
- Systems software - embedded
- Commercial software - SW based products
- Military software - all things that fly, swim, drive, and go "boom"
- End user software - products used by strangers
As one taxonomy. No? Have them come up with their own taxonomy and then ask if they have any direct experience outside that domain?
My Favorite Nonsense
A customer who needs to “know how much it will cost” before they will decide to hire you to do the project might not be the sort who is willing to let requirements emerge.
Emergent requirements are part of the DOD 5000.02 development lifecycle. The Program Events, Systems Requirements Review, Preliminary Design Review confirm that the desired requirements match the needed capabilities of the system. Requirements ALWAYS emerge, there is no other way. The Needed Capabilities may be reduced or increased. But requirements elicitation and management is a dynamic, iterative, and incremental process baked into the DOD process. Anyone believing otherwise needs to abandon their naive notions of how complex system are built.
