Deconstructing a #NoEstimates Argument

Here's a recent presentation on using #Noestimates. Let's deconstruct these ideas in light of several principles and practices of making decisions in the presence of uncertainty.

Planning with #NoEstimates from Gil Zilberfeld

Let's start with the title

Planning with #NoEstimates. If we take the term #NoEstimates as saying its name, like the originator of #NoEstimates, says.

That is we can make decisions (in the presence of uncertainty) without estimating. Let me say it again

The NoEstimates conjecture is we can make decisions in the presence of uncertainty without estimating the impacts or outcomes of those decisions

There are some in the #NoEstimates community that says that's not what it means, but to date, that original tweet has not been denied, retracted, or even clarified in any actionable manner. So let's assume it still stands.

So Let's start. There are no page numbers, so I'll start on page 3 and rename that Page 1

1. To estimate or #NoEstimates, that is the question
   • That question is not asked by those spending money but should be asked by those paying
   • The answer is simple - what's the value at risk for making a decision in the presence of uncertainty without assessing the impact of that decision?
2. The founders
3. Why do we need estimates?
   • Ask those paying if they need to know how much this will cost when it will be done, and what they will get to some level of confidence with a needed precision and accuracy of that estimate.
   • If they say I don't need to know, then don't estimate, it's a waste, just start coding.
4. Ask an expert
   • Better yet, read books and papers on estimating 
   • Not necessarily in the general domain, but how about in the Agile domain
   • Here's a starting point for estimating in the presence of uncertainty on Agile project
   • This is an ongoing bibliography so check back periodically.
   • This bibliography and the other sections are part of a larger effort to provide guidance for deploying agile to Software Intensive System of Systems in the US Federal Government domain. A domain where the annual (2016) IT budget if $82B. Yes, that's Billion with a B.
5. Why do we need to estimate?
   • Ask those paying you if they have a need to know something about the future cost, schedule, and technical performance to make business decisions?
6. Estimates all things
   • Not all things, but things needed to make decisions in the presence of uncertainty
   • Better decisions Yes, decisions are better informed when you estimate the outcome of that decision
   • Go / No Go / Not Now? - yep that's a go reason to estimate
   • Alternatives? - that too
   • Be in Control? - No credible management person in control in the sense of no variances. Variances are needed to manage in the presence of uncertainty. We need to know the range of those variances. Their precision and accuracy of the measurement of the variances. This is the basis of Closed Loop Control. Without estimating the future in some form, it's Open Loop control.
   • #Noestimates is an Open Loop Control system.
   • It driving in the dark with the lights off.
   • By the Way
     • Slicing is estimating
     • Empirical data from the past to make decisions in the future (assuming there is reasonable variance in that data) is estimating. One of the founders of #NoEstimates provides a chart as an example of empirical data that has ±85% variance. Not a credible basis of making the decision when using other people's money
7. Why don't we like giving estimates? Can't say, maybe
   • We don't know how. We were never trained. We never read how. We were asleep in the high school probability and statistics class.
   • We've worked anywhere there a sufficient Value at Risk for those paying and they never needed to know. That place only did de minimis projects
8. Estimates are treated as commitments? 
   • That's bad management
   • Find a better place to work
   • The Manager is Dilbert's Manager
   • He was sleeping in the High School Prob&Stats class
   • DDSTOP
9. Treated as commitments, inflated, a waste of time
   
   • Estimates CAN be treated as commitments. Done all the time
     • There's an 80% confidence we can launch this thing on or before the first 2 weeks in November 2005. That's a commitment made at contract award. As the program proceeds that commitment refined with better data, experience, working products, etc.
   • Estimates can be inflated
     • Yep, they sure can
     • That's why we need to see the numbers on how you got that estimate
     • This is the Basis of Estimate that is submitted with the estimate
     • NEVER accept an estimate without the Basis of Estimate attached
   • Waste of Time? For who
     • For those providing the money? Not likely
     • For those spending the money? Maybe, but that's another topic.
10. Estimates are part of all business decisions
11. Imaginary numbers"
    • Imaginary numbers? Did you pay attention in the Probability and Statistics class?
    • Do you have a Probability and Stats book for SW Development
12. We're not good at estimating
    • For Gawd's sake learn how
    • Would you say we're not good at designing stored procedures for SQL Server 2016? No, you'd go learn how.
    • Estimating is part of business decision making. If you're good at it, or not even trying to get better, you're not going to get a seat at the table when the decisions are being made about your future work.
13. Prediction is very difficult, especially about the future
    • If you're working on subatomic quantum theory in the 1930's that's probably a good quote.
    • We're writing software in the 21st century, stop using out of context quotes, for things that are straight forward - hard but straightforward.
    • There are endless resources about estimating software projects, read, learn, improve, stop using quotes that have ZERO to do without a domain.
14. The Cone Uncertainty
    • Yes, there is a Cone of Uncertainty - act accordingly
    • Those ranges are NOTIONAL. Your project may be much, much different. Get your own numbers. Upper 4X and Lower 0.25X are stating you know little about what you're trying to build. That may be true, but go get better information.
15. Hofstadter's Law
    • Hofstadter was not a project manager
    • His law is about a self-referential statement about the difficulty of estimating complex tasks and the recursive nature of the law is a reflection of the widely experienced difficulty of estimating complex tasks despite all best efforts, including knowing that the task is complex. 
    • But a core aspect of Agile is the reduction of complexity into simplicity. So those quoting this Law are willfully ignoring the principles of Agile.
    • You can't have it both ways.
    • By quoting Hofstadter, you're admitting you're not being Agile - that's called hypocrisy
16. Estimation Game
    • Its Game
    • Nothing to do with writing SW for Money
    • A red herring and strawman showing how disconnected the notions here are from the Principles and Practices of credible Software Estimating
    • It's a disservice to those trained and experienced in estimate complex problems in Software Intensive System of Systems
    • Stop whining, and learn how to estimate

Related articles

How We Make Decisions is as Important as What We Decide.

Estimating Processes in Support of Economic Analysis

Should I Be Estimating My Work?