This is a summary post on the topic of #NoEstimates. Let's start with my professional observation. All are welcome to provide counter examples.
Estimates have little value to those spending the money.
Estimates are of critical value to those providing the money.
Since those spending the money usually appear to not recognize the need for estimating for those providing the money, the discussion has no basis on which to exchange ideas. Without the acknowledgement that in business there are is collection of principles that are immutable, those spending the money have little understanding of where the money to do their work comes from†.
Here are the business principles that inform how the business works when funding the development of value:
- The future is uncertain, but this uncertainty can be modeled. It is not unknowable.
- Managerial Accounting provides managers with accounting information in order to better inform themselves before they decide matters within their organizations, which aids their management and performance of control functions.
- Economic Risk Management identifies, analyzes and accepts or mitigates the uncertainties encountered in the managerial decision-making processes
On the project management side, there are also immutable principles required for project success
- There is some notion of what Done looks like, in units of measure meaningful to the decision makers. Effectiveness and Performance are two standard measures in domains where systems thinking prevails
- There is a work Plan to reach Done. This Plan can be simple or it can be complex. But the order of the work and the dependencies between the work elements are the basis of all planning processes.
- There is a plan for the needed resources to reach Done. This includes staff, facilities, and funding. This means knowing something about how much and when for these resources.
- There is the recognition of the risk involved in reached Done, and a response to those risks
- There is some means of measuring physical progress to the Plan to reach Done, so corrective actions can be taken to increase the probability of success. Tangible outcomes from the Planned work is the preferred way to measure progress
The discussion - of sorts - around No Estimates has reached a low point in shared understanding. But first let me set the stage
If the Business and Project Success principles are not accepted as the basis of discussion for any improvements, then there is no basis of discussion. Stop reading there's nothing here for you. If these principles are acknowledged, then please continue
In a recent post from one of the Original authors of the #NoEstimates hashtag it was said...
Quit estimates cold turkey. Get some kind of first-stab working software into the customer’s hands as quickly as possible, and proceed from there. What does this actually look like? When a manager asks for an estimate up front, developers can ask right back, “Which feature is most important?”— then deliver a working prototype of that feature in two weeks. Deliver enough working code fast enough, with enough room for feedback and refinement, and the demand for estimates might well evaporate. Let’s stop trying to predict the future. Let’s get something done and build on that — we can steer towards better.
This is one of those over generalizations that when questioned get strong pushback to the questioner. Let's deconstruct this paragraph a bit in the context of software development.
- Quit estimates cold turkey - perhaps those paying for the work need to be consulted to determine if they have any vested interest in knowing about cost and schedule of the value they're paying for.
- Some kind of first stab software working - sounds nice. But how much does that cost? And when can that be delivered. Can any feature in the requested list - the needed capabilities and their supporting technical and operational requirements - be done in 2 weeks? Can you show that can happen, so is that just a platitude repeated enough that is has become a meme - without any actual evidence of being true?
- Deliver enough working code fast enough, with enough room for feedback and refinement, and the demand for estimates might well evaporate - there are two cascaded IF conditions here. IF we deliver working code fast enough, IF we leave room for feedback, THEN estimate MIGHT evaporate.
This last one is one of those IF PIGS COULD FLY type statements.
So Here's the Issue
If it is conjectured that we can make decisions in the presence of uncertainty - and all project work operated in the presence of uncertainty by its very definition - otherwise it'd be production - then how can we make a choice between alternatives if we can't estimate the outcomes of those choices?
This is the basis of MicroEconomics and Managerial Finance. When the OP'ers of #NoEstimates make these types of statements they're doing so on the their volition. It's likely their strongly held belief that decisions can be made without estimating the outcomes of those decisions.
So when questioned about what principles these conjectures are based on returns shunning for asking, accusations of trolling, being rude, having no respect for the person making these unfounded, unsubstantiated, untested, domain free statements, it seems almost laughable. At times it appears to be willful ignorance of the basic tenants of business decision making. I don't pretend to know what's in the minds of many #NE supporters. Having talked to some advocates who are skeptical, it turns out when questioning further they are unwilling to disavow the notion that there is merit in exploring further.
This is a familiar course for climate change deniers. All the evidence is not in, so let's challenge everything and see what we can discover. This notion of challenging and exploring in the absence of established principles is not that useful actually. In a domain like managerial finance, Microeconomics of software development decision making, in the realm of decision-making in general, the principles and practices are well established.
What's now know is actually that those principles and practicers are not know to those making the conjecture that we should challenge everything. Much like the climate deniers - Well I'm not a scientist but I heard on the internet there is some dissent in the measurements ... So I'm not familiar with probability and statistics and haven't taken a microeconomics class or read any Managerial Finance books, But almost sure that those self-proclaimed thought leaders for #NoEstimates have something worth looking into.
Harsh, you bet it's harsh. Any idea presented in an open forum will be challenged when that idea willfully violates the principles on which business operates. Better be prepared to be challenged and better be prepared to bring evidence your conjecture has merit. This happens all the time in science, mathematics, and engineering. Carl Sagan's BS Detector is one place to start. Or John Baez's Crack Pot Index are useful in the science and math world.
No Estimates has now reached that level, with some outrageous claims.
- Not doing estimates improves project performance by 10X
- Estimates are actually evil
- Estimating destroys innovation
- Steve McConnell proves in his book estimates can't be done.
- Todd Littles Figure 2 shows how bad we are at estimating - without of course reading the rest of the presentation showing how to correct these errors.
Making Credible Decisions in the Presence of Uncertainty
Decision making is the basis of business management. Here's an accessible text for learning to make decisions in the presence of uncertainty, Decision Analysis for the Professional. When there is any suggestion that decision can be made without estimate ask if the personal making that conjecture has an evidence this is possible. Ask if they're read this book. Ask if theirdecision-making process has:
- A decision-making framework
- A decision-making process
- A methodology for making decisions
- How this decision-making process works in the presence complex organizations
- A probability and statistics model for making decisions.
Here's some more background on making decisions in the presence of uncertainty.
- Business Portfolio Management: valuation, Risk Assessment, and EVA Strategies, Michael Allen
- Real Options: Managing Strategic Investments in an Uncertain Work, Martha Amran, Harvard Business School
-
Modern Decision Making: A Guide to Modeling with Decision Support Systems, Samuel Bodily.
- Making Hard Decisions: An Introduction to Decision Analysis, Robert Clemen.
-
Decision Making Under Uncertainty: Models and Choices, Charles Holloway.
This is a sample of the many resources available for making decisions in the presence of uncertainty. There is also a large collection of estimating software development projects. The one we use in our work is
- Estimating Software Intensive Systems: Project, Products, and Processes, Richard Stutzke.
This an other resources are the basis of understanding how to make decision.
When it is conjectured we can decide with estimating, ask have you any evidence what so ever this is possible beyond your personal opinion and anecdotal experience? No? Then please stop trying to convince me your unsubstantiated idea has any merit in actual business practice.
And this is why I've decided to stop writing about the nonsense of #NoEstimates. There is no basis for the discussion anchored in principles, practices, or processes of business based in managerial finance and Microeconomics of decision making.
It's a House Built On Sand
† I learned this in the first week of my first job after graduate school. When our boss explained where the money came from. He said take out your paycheck (this was the days when paychecks were delivered in envelopes by the manager every other Friday) and look in the upper right corner. It says Bank of America Sulpedeva Blvd, Redondo Beach. That's NOT where the money comes from. It comes from the United States Air Force. Now young ones need to get back to work and keep that USAF Col happy with working software on the day we promised him this Radar system be ready for deployment. The day that deployment plan came, we weren't ready. So his message to us was I know we're not ready to ship, but you folks will really like Dayton Ohio, so start packing we're shipping. I sat in a NC-135 (Boeing 707) for the next 3 months coding in Fortran 77 on a PDP-11/20 embedded in a rack of other systems, freezing my ass off with the door open.
