Herding Cats:

The Fallacy of Beneficial Ignorance

The basis of #Noestimates is that decisions can be made in the presence of uncertainty without having to estimate the impact of those decisions

Here's a research paper that hopefully will put an end to the nonsensical idea of #NoEstimates.

All project work is uncertain. And has been stated here endless times, uncertainty comes in two forms - Reducible (Epistemic) and Irreducible (Aleatory).

Add to that the biases found on all projects - confirmation and optimism are two we encounter all the time. The conjecture - and it is pure conjecture- that decisions can be made when spending other people's money in the presence of uncertainty without estimating the consequences of those decisions is not only conjecture, it's factually false - a Fallacy.

Here's the paper at SSRN. You'll need to create a free account. This version is the pre-publication version, but it's the same paper I downloaded from my account. Read the paper, discover how to reject the notion of #NoEstimates, not only by its ignorance of managerial finance, probabilistic decision making, business governance violations, but foundational mathematics.

So time to learn why estimates are needed to make decisions in the presence of uncertanty, how to make those estimates, and start behaving as adults in the presence of the risk created by this uncertainty as Tim Lister tells us Risk Management is how Adults Manage Projects.

Posted at 06:01 PM in #NoEstimates | Permalink | Comments (1)

Estimating on Agile Projects

Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains.

Posted at 08:38 PM in #NoEstimates, Estimating | Permalink | Comments (0)

How to Make a Decision in the Presence of Uncertainty

Uncertainty is all around us. In the project world, uncertanty comes in two forms:

Aleatory Uncertainty - the naturally occurring variances due to the underlying statistical processes of the project. These can be schedule variances, cost variances, and technical variances - all driven by a stochastic process with a known or unknown statistical distribution. If you don't know what the distribution is, the Triangle Distribution is a good place to start. For example: The statistical processes of testing our code ranges from 2 to 4 days for a full cyber security scan. Planning on a specific duration has to consider this range and provide the needed margin. Aleatory uncertainty is irreducible. Only margin can protect the project from this uncertainty.
Epistemic Uncertainty - the probability that something will happen in the future. The something we're interested in is usually unfavorable. For example: The probability that the server capacity we have selected will not meet the demands of the user when we go live. Epistemic uncertainty, being probabilistic, can be addressed with redundancy, extra capacity, experiments, surge capacity and other direction actions to buy down the risk that results from this uncertanty before the risk turns into an issue.

When we hear you can make decisions without estimates, this is physically not possible if you accept the fundamental principle that uncertanty is present on all projects. If there is no uncertanty - no aleatory or epistemic uncertainties - then there will be no probabilistic or statistical processes driving the project's outcomes. If that is the case, then decision have no probabilistic or statistical impact and whatever decision you make with the information you have is Deterministic.

So if you want to learn how and why estimating is needed to make decisions in the presence of uncertainty start here:

Making Hard Decisions: An Introduction to Decision Analysis, Robert Clemen
Making Multi-Objective Decisions, Mansooreh Mollaghasemi and Julia Pet-Edwards
Decision Analysis for the Professional, Pete McNamee and John Celona

And then when you hear about a conjecture that decisions can be made without estimating you'll know better, and consider anyone making that conjecture as uninformed about how probabilistic and stochastic processes in the project world actually work - especially when spending other people's money.

Posted at 04:28 PM in #NoEstimates | Permalink | Comments (0)

Book of the Month - IT Project Estimation: A Practical Guide to the Costing of Software

Estimating is part of all decision making in the presence of uncertainty. Accuracy and precision are two primary attributes of all estimates.

We all know estimates are hard. But there are lots of hard things in the development of enterprise software. We wouldn't be whining about how hard it is to construct a good First Normal Form database schema, or bullet proof our cyber security front end from attack by the Chinese would we.

So why is estimating a topic that seems to be the whipping boy for software developers these days?

My first inclination is that estimating is not taught very well in the software arts. In engineering schools it is. Estimating is part of all engineering disciplines. One undergraduate and one graduate degree is in physics. Estimating is at the very heart of that discipline. A second graduate degree is in Systems Management - which is a combination of Systems Engineering and Managerial Finance - how to manage the technical processes of engineering programs with the principles of managerial finance, contract law, and probabilistic decision making.

This book comes with a spreadsheet for making the needed estimates to increase the probability of project success. It opens with an important quote that should be a poster on the wall of any shop spending other people's money

For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it? Lest haply, after he hath laid the foundation, and is not able to finish it, all the behold it begin to mock him, saying, This man began to build, and was not able to finish - Luke 14:28-30

Posted at 09:42 PM in #NoEstimates, Books, Estimating | Permalink | Comments (0)

Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics

The on-going discussions that Decisions can be made in the absence of estimates reminds me of this concept.

The conjecture that we can manage in the presence of uncertanty without estimating the impacts of our decisions, willfully ignores uncertainties in the present and future that will impact our outcomes, the external governance frameworks of managerial finance, probability and statistics of the processes under management, and regular governance processes and the decision rights of those governance frameworks.

Those decision rights by the way belong to those paying, rarely to those spending. So the decision to estimate or not estimate rarely belongs to the developers spending the business's money.

When the claim that #Noestimates critics say we're simply not being Opened Minded those advocates want us to accept that everything can be challenged, without any basis for that conjecture. If that were the case, those proforring #Noestimates fit right into those believing the pseudoscience of spending other people's money in the presence of uncertanty.

Thanks to Peter Kretzman for the link to the video.

Posted at 02:25 PM in #NoEstimates | Permalink | Comments (0)

Quote of the Day

Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.
— Bruce Lee

Any new innovative or revolutionary suggestion in the software development world, needs to be anchored on the established principles of how to manage the spend of other people's money. If it's your own money, spend as you please - no one cares.

But if you're spending other people's money to produce value in exchange for that money, those providing the money likely have a fiduciary obligation to know something to some level of confidence how much it will cost, when it will be done, and what they'll get for that that cost and time.

To suggest otherwise without a foundation of principles by which this new and innovative idea can be tested is selling snake oil to the uninformed. That approach has worked since the dawn of time - I have the solution to your unnamed ailment, just try this magic elixir and all will be better.

Posted at 10:32 AM in #NoEstimates, Quotes | Permalink | Comments (2)

Learning Through Research

A primary learning process is research. This process is part of all science, engineering, management processes. Here's a starting point for learning how to estimate in the presence of uncertainty on agile projects.

This is the start of a literature search. Anyone making suggestions about making decisions in the presence uncertainty on agile project can start here for establishing the basis of any arguments of how and why that suggestion (conjecture possibly) is based on some set of principles. Not just anecdotal opinion.

Evm+agile estimating from Glen Alleman

Posted at 09:30 AM in #NoEstimates, Agile, Estimating | Permalink | Comments (0)

How to Estimate Any Software Problem

The conjecture of #NoEstimates starts with the first Tweet

This conjectures - (there are) ... ways to make decisions with No Estimates ... is not founded on any principle of business management, microeconomics of decision making, or principles of probability and statistics. It's a fallacy.

Let's start with a simple approach to exploring for anything?

What are we looking for? It says we're looking for An Alternate Way to make decisions - in the presence of uncertanty. Uncertainty of course is present in all software development work both reducible and irreducible uncertainty.
How will we recognize it when we encounter it? Any expectations for what we'll find? Any expectations of how to measure if what we found is what we're actually looking for?
Once we find it, how can we test that what we found is actually of use to anyone other than us? The use of anecdotes is to collect a sample of One from an Unknown population and consider it representative of as evidence of our hypothesis.

The Hypothesis might well be (if there was one) is ... can we make a decision in the presence of Uncertainty without making an estimate of the impact or outcome of that decision?

Let's put aside for the moment the missing principles of managerial finance, probabilistic decision making, microeconomics of decision making, Real Options, Bayesian decision networks, and other decision making processes used in modern business when spending other people's money. And ask a simple question...

What would be the evidence that we could make decisions in the presence of uncertanty without estimating the impacts and outcomes of those decisions?

The Myths of No Estimates and the busting of them is one purpose of this blog post. Here are some books and papers that can provide you with all the tools needed to learn to estimate in the presence of uncertainty. As well these books and papers can show you the snake oil salesman's fallacy that estimates are hard, are a waste, and aren't needed to make decisions in the presence of uncertainty.

Reading Materials

Before listening to any conjecture that estimates aren't needed to make decisions in the presence of Uncertainty for software development, please read these books. Ask the person making those conjectures if they have read the books. Ask to see the marked up, sticky noted, tabbed copy of the book and the notes they made from the content. If not, walk away. They are not informed by the principles of spending other people's money.

	Before we start, let's look with the notion of estimation. A Guess is uninformed by experience, skill, or data. An estimate is. This is a simple book that will show how to estimate most everything. Start here. Read the entire book,. Learn how to think as an estimator. Take that experience and start making estimates for software projects. Then and only then ask yourself why do people claim estimates are wrong, why is estimating hard. And you'll know the answer - they have no experience, they have no skill, they have no knowledge of how estimates can be made. Then you'll know. It's not that estimates that are smell of dysfunction, it's the unskilled, inexperienced, untrained, uninformed, unknowledge people making those unsubstantiated claims.
	The next learning opportunity is to realize how much nonsense is floating around about not estimating. Here's the start for that understanding. Managing a business profitably is always hard work. There are intense pressures, incomplete information about what’s happening in the marketplace and an army of consultants, advisors and others who come along with new ideas every day. Under these conditions, it isn’t surprising managers sometimes fall victim to hype about “miracle” cures for management challenges or simply adopt the “best practices” of other successful companies. The result is sometimes poor-quality decisions are made which end up wasting time and money which are badly needed elsewhere. This book was handed out by Jeff Sutherland at the State of Agile conference as an indication of how agile has come to represent sloppy thinking on behalf of many of its advocates.
	Here's a start of actually estimating in a credible manner, using tools available to anyone. Start here to learn how simple it is to estimate things. Things you have never seen before. Things you have never done before Using Enrico Fermi’s theory of approximation. The Fermi estimate, or order estimation is an estimation problem, teaches dimensional analysis, approximation, using a back-of-the-envelope calculation. The estimation technique, named after physicist Enrico Fermi, makes good approximate calculations with little or no actual data. Fermi problems typically involve making justified guesses about quantities and their variance or lower and upper bounds. There is no excuse for not learning how to apply this approach to software development.
	With the basic concept that estimates are straightforward, this book shows the economics of managing iterative development. Here estimates are part of planning and measuring progress. The book speaks to assessing the technical viability of the system and the overall cost to achieve that technical viability. These are core business processes for the success of any investment. And of course based on making decisions in the presence of uncertainty.
	Now that we've established with the above sources there are conjectures without basis, nonsense statements like estimates are the smell of dysfunction without ever stating what the dysfunction is or what could possibly be causing the dysfunction, here's the place to start for serious estimating for software intensive systems. A de minimis software project rarely benefits from estimates. Willfully bad management rarely benefits from learning how to estimate. If you customer has no real value at risk, of has no real concern about showing up on time to start accruing the business value in exchange for the cost to produce that value, then estimates are unlikely to be needed.
	This is a seminal book on estimating. It provides the background and the practices needed to estimate Agile projects. Mike shows why traditional processes fail and why agile approaches work. It's standard Feature Story breakdown but with the reasoning behind the processes.
	This is the other seminal book on estimating. Between these two books, you'll find need to know to make credible estimates for the development of software using Agile. The book claiming to show hwo to improve your project performance by 10X is so riddled full of holes, it's worthless. Don't waste your money on it. For the same price as that book, you can own both Mike's and Steve's books with field proven examples rather than fictitious anecdotes of bad management practices.
	All project work is probabilistic. Some probabilities are event based, some are statistically based. Cost is always a driving consideration for how products are built, delivered, and sustained. A critical success factor for all software project work is cost and the associated schedule. Showing up on or near the needed time at or near the planned cost is simple business. Anyone saying cost is not important is not accountable for the business success of the development. Ignore them, they have no seat at the business management table. If we come out late with the product we lose revenue needed to meet the business plan. If we spend more than planned, we erode profit and fail to meet the business plan. Both these variables - cost and schedule - along the the needed technical performance to meet the expected acceptance of the product are probabilistic. Estimates are needed to inform the decision makers of the Probability of Success of the product.
	Setting the date before the project is planned is the oldest root cause of project failure. Not having some sense of the scope of work, the effort needed to produce that scope, and the capacity for the development to produce the needed features for that scope is in the same class of failure modes. Ignoring the need to have estimates of effort, time, and cost is not only bad project development it is bad business management. Any suggestion that decisions can be made in the presence of project uncertanty without estimates willfully ignores these principles.
	Large Scale Scrum (Less) is a framework for scaling Scrum to the enterprise. In the Less method, estimates are part of the Product Backlog Refinement. This process: Split big items, Does a light weight analysis for basic understanding, Estimates the items, Identifies strongly related items to reveal shared work, common work, or coordinated work.
	Agile at Scale is not the same as small agile teams. Governance drives processes in Agile at Scale. Governance can be ignored or even flaunted for small self contained teams. Organizing for responsiveness to external business drivers at scale means additional cost must be absorbed to govern in the presence of these externalities. Agile at Scale also means dealing with architecture - technical architecture,process architecture, business architecture. Managing in the presence of all these uncertainties mandates we estimate the impact of these decisions. At scale without estimating the work processes turn into chaos.
	This is one of the books that started it all. In Highsmith's books he calls out explicitly the need for estimating and some of the steps to do it. Any enterprise agile development operating inside a corporate governance process requires knowing something about the outcomes of the work effort. The cost, the expected delivery date, and the expected business value produce for the cost. The time cost of money is a foundation of business decision making. O those paying you have no need to know the time cost of money, how much it will cost, what the possible business value will be and when you might be done, then estimating is not needed.
	Anyone suggesting you can't estimate must read this book to learn that conjecture is false - patently false - and learn how to actually make estimates of anything. What I've found is when there are statements like all estimates are wrong, we can't estimate, estimates are misused is that those making those conjectures aren't actually informed how good estimates are made. So instead of learning about estimates, they fall into the fallacy of #Noestimates.
	This is another book that if the #Noestimates advocates had read on day one of their exploring they would have found the destination and stopped spouting all the nonsense about the smell of dysfunction. Troy combines all of my favorite topics - mathematics of project management, monte carlo simulation - the actual monte carlo simulation, not the bogus sampling of past performance advocated by some No estimator's, and a logical, clear, and concise approach to making estimates in the presence of uncertanty to inform the decision makers when spending their money.
	There are many fallacies in the software development world. Many of these fallacies go unchecked, unaddressed, unchallenged. Here's where to start learning about the fallacies and their facts. This is a similar issue with #Noestimates. This starts with the missing principle by which a decision can be made in the presence of uncertanty without estimating. Attempts to question these missing principles, results in further fallacies being put forward, along with labeling anyone probing further for the missing principle as aggressive, rude.
	This is the basis of software estimating. It's been updated for agile. Read it first, then read the agile updates. Learn how to use numbers, models, evidence, tools to estimate in the presence of uncertanty. This is how non-trivial projects are managed. Anyone suggesting this is olde school hasn't done their homework to earn the position to be critical of the contents.
	Spending other people's money involves governance of those decisions. Governance by its definition is about decision rights Who gets to the decide what is needed, when it is needed, how much it could cost (affordability). These decision rights are almost alwasy assigned to those paying for the outcomes. The #NoEstimates advocates would have those decision rights transferred to those who spend, by suggesting estimates are a waste. Without stating who they are waste to. It is very unlikely they are a waste to those provided the funds that enable the #NoEstimates advocates to produce the software needed by those providing the funds. It's illogical to invert this relationship between those paying and those spending.
	Now we're into the heavy lifting of estimating. Yes estimating is forecasting. Forecasting is an integral part of the decision making activities of management. The organization establishes goals and objectives to produce outcomes from its decisions. The need to forecast (estimate future outcomes) is based on management's need to decrease its dependence on chance and become more predictive in dealing with the uncertainty it encounters. We're now down to the core processes of making decisions in the presence of uncertainty. This is how business operates. Anyone conjecturing that decisions can be made in the presence of uncertanty without estimating - forecasting is estimating outcomes in the future - needs to stop and learn more. Learn how business actually works. Not just assume that some who make an unsubstantiated statement about estimates are the smell of dysfunction has any credibility when spending other people's money. It's time to call BS on the notion of #NoEstmates.

Along with these books here's a collection of papers and articles showing how to estimate on agile development projects and how to avoid the Snake Oil Sales Pitch of #NoEstimates

Evm+agile estimating from Glen Alleman

So stop listening to the fallacy that estimates aren't needed to make decisions. And start learning to estimate and be a proper steward of your customers money.

Quote of the Day

Predictions are always difficult - especially about the future ― Niels Bohr
― Neandertal's Guide to Cost Estimating, Naval Aviation Systems

This is a quote often used by those conjecturing that estimating is a waste. The quote is true of course. Making predictions about the future is difficult. But that has nothing to do with the need for predictions and the estimates that support them. When making decisions in the presence of uncertainty about some outcome in the future - this is the basis of Microeconomics of decision making.

Posted at 07:03 AM in #NoEstimates, Estimating, Quotes | Permalink | Comments (0)

Quote of the Day

Guess: a conjecture based on little or no evidence
Estimate: a guess made by an expert
― Neandertal's Guide to Cost Estimating, Naval Aviation Systems

All project work is based on probabilities driven by statistical processes. All decisions made on projects for time, cost, and technical performance involve making decision in the presence of uncertanty. To attempt to make those decisions in the absence of estimating the impact of the decisions is foolhardy at best and doomed to failure at worst.

Posted at 08:51 AM in #NoEstimates, Estimating | Permalink | Comments (0)

Five Immutable Principles of Project Success

All successful projects adhere to these five immutable principles during the lifecycle of the design, development, deployment, and operation. These principles are independent of any project or program domain or context in that domain. They are also independent of any project management method or product development method, including agile.

They ask five questions that must have credible answers that establish the foundation for success. Without credible answers to these 5 questions, the project has little hope of success.

This paper is the basis of the book, Performance-Based Project Management. and a review from Max Wideman

So if you hear some unsubstantiated conjecture like ... decisions can be made without estimating ask how any or all of the 5 immutable principles can be met?