Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
There's another rash of Twitter posters supporting the conjecture that decisions can be made about how to spend other people's money without estimating the impact and outcome of that decision. This is a core premise of #NoEstimates from the Original Poster
Here's a starting point to learn that simply not true¬†
There are 100's more books, papers, conference proceedings on the topic of¬†decision¬†making in the presence of uncertanty.
It comes down to a simple concept
All project work is uncertain. Reducible uncertainties (epistemic) and irreducible uncertainties (aleatory). When money is being provided to development software, those providing the money a reasonable expectation to know something about when you will be providing the value in exchange for that money, how much money will be required to provide that value, and what capabilities will be provided in exchange for that money. The field of study where these questions and answers live is¬†microeconomics of decision making. Software development decision making is a well studied subset of that field.
When it is conjecture decisions can be made in the presence of uncertanty without estimates - like the Original Poster did, and there is no supporting theory, principle, practices, or evidence of how that can be done -¬†run away - it's a bogus claim.¬†Related articles Making Decisions In The Presence of Uncertainty Essential Reading List for Managing Other People's Money Herding Cats: Decision Making in the Presence of Uncertainty Herding Cats: Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics Making Conjectures Without Testable Outcomes
I've¬†started reading Vasco's book #NoEstimates and will write a detailed¬†deconstruction. I got the Kindle version, so I have a $10 investment at risk. Let's start with some graphs that have been around and their misinformation that forms the basis of the book.
The Chaos Report graph,is the¬†1st one. This graph is from old 2004 numbers. That's 12 year old numbers. Many times the books uses 12, 16, even 25 year old reports as the basis of the suggestion that Not Estimating fixes the problems in the reports. The Chaos reports have been thoroughly debunked as¬†self selected samples using¬†uncalibrated¬†surveys for the units of measure for¬†project¬†failure.¬†Here's a few comments on the Standish reporting process. But first remember, Standish does not say what the units of measure are for Success, Challenged, or Failure. Without the units of measure, the actual statistics of the projects and the statistical ranges of those projects for each of the three¬†categories, the units as essentially bogus. Good fodder for selling consulting services or for use by those with an idea to sell, but worthless for decision making about the root cause of Failure, Challenged, or even Success. Any undergraduate¬†design of¬†experiments class would have all that information in the public.¬†
So the 1st thing to read when you encounter data like this is Project Success:¬†A Multidimensional Strategic¬†Concept,¬†Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz. Only then start to assess the numbers. Most likely, like the numbers in the book, they're not credible to support the hypothesis. Which by the way there is no hypothesis for¬†you can make¬†decisions¬†in the presence of uncertanty without estimating
So let's look further at the difficulties with Standish and why NOT to use it as the basis of a conjecture
A simple google search would have found all this research and many many more. I get the sense V didn't do his homework. The bibliography has very few references to actually estimating, no actual estimating books, papers, or research sites. Just personal anecdotes from a ¬†set of experiences as a developer.
The Standish Report failure mode is described in¬†Darrell Huff's¬†How to Lie With Statistics -¬†self select the samples from the survey. Standish does not provide any population statistics for their survey.
None of these questions are answered in Standish reports. No Estimate picks these serious statistical sampling error up and uses the, as the basis of the pure-conjecture that Not Estimating is going to fix the problems. This would garner a high school D is the Stats class.
Next comes a chart that makes¬†a similar error. This reference is from Steve McConnell's book, but is¬†actually from another source. The No Estimates book does a poor job of keeping the references straight. It is common to¬†misattribute a report, a graph, even a phrase. The book needs a professional editor.
The graph below is used to show that estimates are usually wrong. But there is a critical misunderstanding about the data.
I'm in the early parts of the book and already have a half dozen pages of notes for either fallacies, incorrect principles, 30 year old references, and other serious mistakes on¬†understanding on how decisions are made in the presence of uncertainty. My short assessment is¬†
It's a concept built on sand.Related articles Myth's Abound All Project Numbers are Random Numbers - Act Accordingly The Failure of Open Loop Thinking How to "Lie" with Statistics Statistical Significance How to Estimate Software Development Capabilities Based Planning IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes
When riding a¬†single track like this¬†one behind our neighborhood, I came to an understand of the tradeoffs between stability and control. In our conference sessions, we speak about how the Wright Brothers learned this concept as well.Here's another trail being ridden by our son at Nationals in 2013. who's¬†massively better than I will ever be. But same tradeoff between stability and control is needed¬†to be ranked 33rd Cross Country and 23rd Short Track at DII in¬†the nation, with team taking¬†2nd overall.
In both cases, nationally ranked and rank amaetur, control of bike is the key. Stability is a relative term, depending on speed, terrain, skill, risk taking tolerance, ¬†experience, technical equipment, and other intangible factors.
We speak at conference where program planning and controls is the topic. Starting 2 years ago, our foundation for speaking about managing in the presence of ¬†uncertanty is the Wright Brothers.
Most earlier experimenters in powered flight focused only on one or two¬†of the primary problems - (a) A set of lifting surfaces, or wings, (b) A method of balancing and controlling the aircraft, and (c) A means of propulsion -¬†¬†and did not consider the final design from the outset. The Wrights recognized that each of these areas had to be successfully addressed to build a working airplane. They believed that the aerodynamic and propulsion problems would be comparatively easier to solve, so they first concentrated on how to maintain balance and control.
Many believed that air currents were too swift and unpredictable for human reflexes. Therefore, an aircraft had to be inherently stable for the pilot to be able to maintain control.¬†Because of the Wrights‚Äô extensive experience with the bicycle‚ÄĒa highly unstable but controllable machine (just like the mountain bike)‚ÄĒthey saw no reason why an airplane could not be unstable yet controllable as well.
The notion of¬†Control is missed used in software development projects. Misused and misunderstood. Control inside the upper and lower control bounds is a critical success factor. What are those upper and lower control bounds? Good question. They have to be estimated in the start. They become cleared as the project progresses. They have to be adjusted as new information emerges.
In projects, the question for Stability¬†is a false quest. All project work is uncertain. Stability is short lived. New inputs arrive every day. Just like new inputs arrive while riding down the flat trail for cruising around the open space in the neighborhood or more so¬†on the bumpy high speed trail of collegiate racing.
Even if the trail is defined in from of you, the small disruptions and many times big distributions input your control of the bike. The key is¬†Control over Stability. Staying in control will get you across the finish line, down the trail, and home again to ride another day.
Skills of Maintaining Control on the Mountain Bike and the Project
Starting from our house there is a nice loop Left Hand Trail, that is easy, has a few climbs, and a few descents, uncrowded, and provides a nice view of the small hills before the real mountains start . Combine that with the Eagle Trail, Sage Trail, and North Rim Trail and it's a nice 7 mile loop
There's lots of misinformation going around again in the #NoEstimates community
Here's the starting point¬†to clarify and debunk those concepts
Here's some more details, once it's been confirmed you have domain experience
In the end it's simple. Anyone speaking about the difficulties or the waste of estimating is likely on the spend side of the software development equation. Those on the¬†pay side know (or should know) they needed estimates. They can get the estimates from those most qualified to provide them - the developes. Or they can just make them up. Probably better to have a bottom up estimate.Related articles Humpty Dumpty and #NoEstimates Want To Learn How To Estimate? Let's Stop Guessing and Start Estimating
¬†When we hear about all the suggested ways to improve the effectiveness of our development effort, if we're to going work on improvements, let's go where the REAL money is.¬†
Here's the IT budget for the Federal Government. This is larger than¬†all the IT systems found everywhere else in the world, plus all their custom built IT stuff. This is not the embedded systems. These are business systems.
So if we're going to make improvements in the spend of IT for better value, let's start here.
¬†Related articles Estimating and Making Decisions in Presence of Uncertainty Intentional Disregard for Good Engineering Practices? What's in a Domain?
The latest thread in agile is ...
the continued paradigm of deadline-driven development is killing the benefits that Agile Software Development can bring.
It is suggested¬†by Neil Killick¬†that ...
...¬†using genuine time constraints as a factor in the prioritisation of work rather than as a focus for its execution, the odds of meeting those "deadlines" are actually improved.
Not sure what a¬†genuine time constraint is versus any time constraint. But the conjecture that¬†Executives of software product and service companies always want stuff delivered faster, cheaper and better. Agile principles and methods are believed to be a way to achieve this ignores several fundamental principles of all work and especially software development work.
¬†All project work has uncertanty. Reducible uncertanty and irreducible uncertanty.
Agile does not remove this uncertanty. Agile is NOT a risk management process.¬†Genuine¬†constraints don't remove this uncertanty., I've spoken many times in the past about how to¬†Manage in the Presence of¬†Uncertainty.
These¬†principles are¬†always in place. More so on Agile projects, where emergent requirements are encouraged, which in turn drive uncertanty further to the right in the Probability Distribution Function of the possible range of durations, costs, and technical performance shortfalls.
When those uncertainties are not considered and handled, any project is going to have an increased chance of being late, over budget, and have technical issues.¬†
Setting¬†genuine¬†constraints may make this issue visible, but does not remove the¬†risk to the project's probability of success. Only active risk management and the necessary margin can increase this probability.
The only protection for irreducible uncertanty is¬†Margin and the only protection¬†for reducible uncertainty is¬†active risk management. Both of these activities require careful planning and execution of the¬†plan, along with the estimate of the probability of occurrence of a reducible event and the statistical distribution of the naturally occurring variances¬†and the probabilistic¬†impact on the success of the project.
This is the Reason for Planning
It's been suggested I work in a unique domain, where deadlines and need dates are themselves unique. This is False.
No credible business, no matter the size, Doesn't have a need date for the Value produced by the software project. If there was no¬†need date, the developers would show up whenever they wanted after spending whatever they wanted, with whatever they thought the customer needed.
Ignoring the simple¬†time cost of money and the time phased Return of Investment of (Value-Cost)/Cost, any business that intends to stay in business is spending money for software - either developed or purchased - to provide some value to the business. Not having a¬†need date for the production of that Value means the business is ignoring the core principle of retained¬†earnings. Even non-profits and not-for-profit business (and I've worked there as well) have a¬†time value of money¬†economic model.
So if you're going to produce¬†value for your customer, that value is most always time sensitive other wise it's de minimis value. If it's time sensitive, there is a deadline. If there's a deadline, reducible and irreducible uncertanty and the risk it produces must be handled.¬†
Risk Management is How Adults Manage Projects -¬†Tim Lister
‚Ä† The naive notion that scrum teams are self contained and need no external support is only the case when there is little at risk for the resulting code. Cyber security, Database integrity, performance validation, operational integrity are external surveillance roles on any Software Intensive System of Systems. This is called Governance and guided by documents like ISO 12207, ITIL V3.1, COBIT, DoDAF, ToGAF.Related articles Risk Management is How Adults Manage Projects Essential Reading List for Managing Other People's Money Agile Software Development in the DOD The Art of Systems Architecting Seven Principles of Agile Software Development in the US DOD Deadlines Always Matter
Here's some thoughts on the economics of software development using other people's money, after 3¬†weeks of working a proposal for a major software intensive system of systems using Agile.
So to come full circle¬†
Why Do We Need Estimates?
It can't be any clearer than this - if you¬†¬†don't know what something costs or is going to cost in the future, you¬†can't make a business decision about it's value
When you read¬†estimates are a waste, estimates are non-transferable, estimates are wrong, estimates are temporary think again. Go ask those paying if they need estimates to make decisions for the business. If they don't, then continue to spend your customers money. If they do, they may consider looking for someone who knows the difference between willful ignorance of how to estimate software development and someone who can provide that information needed to stay in business. On our proposal team, this would get you a¬†2nd¬†place prize in the¬†estimating¬†capabilities¬†contest - which is a¬†one way¬†trip home with weekends off.Related articles Capabilities Based Planning First Then Requirements Incremental Delivery of Features May Not Be Desirable Quantifying the Value of Information Essential Reading List for Managing Other People's Money Decision Making Without Estimates? Economics of Software Development Risk Management is How Adults Manage Projects Process is King Deadlines Always Matter
It's common to misquote famous quotes. The #NoEstimates advocates love to use a Deming quote
It is wrong to suppose that if you can‚Äôt measure it, you can‚Äôt manage it ‚Äď a costly myth.
This is used in support of the fallacy that estimates aren't needed to make decisions in the presence of uncertanty. They are for, all the reasons listed in the 100's of blog posts here and other places.
But more important is the use and misuse of quotes without checking on the validity of the quote. This too seems common among those quoting without confirmation, attribution, or establishing the proper domain and context of the quote. It's just sloppy¬†thinking at best and willful ignorance¬†at¬†worst.
I spent the week speaking at the College of Performance Management conference where government and industry come together to work on the issues of cost, schedule, and technical performance management process improvement needed to increase the probability of program success.
This community of program controls, cost analyst, earned value managers and program managers is accountable for providing information to decision makers on enterprise and complex projects and programs. It would be unheard of to make statement that aren't based on well researched background and principles. The antithesis of the rogue agilist¬†currently populating the #NoEstimates community, spending other people's money (which I doubt takes place on anything but¬†de minimis projects) with no consideration for the principles of managerial finance.¬†
To learn more about the Deming quote start here and check for yourself when you hear or read any quote that doesn't make sense in practice. It's likely wrong, misquoted, misattributed, or taken out of context.Technical Performance Measures Assessing Value Produced By Investments Who's Budget is it Anyway? Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter Software Engineering is a Verb
If we don't remember those who have¬†died, they died for nothing
From 1775 to Present - 2,852,901
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.What's the Smell of Dysfunction? Making Decisions in the Presence of Uncertainty Making Choices in the Absence of Information Making Conjectures Without Testable Outcomes Estimating and Making Decisions in Presence of Uncertainty Making Decisions In The Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains.¬†
Uncertainty is all around us. In the project world, uncertanty comes in two forms:
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:
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.
Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fool do not imitate the success of the wise - Cato the Elder
Any conjecture not based on testable principles, independent of personal opinion or anecdotes cannot stand up to the questioning of the wise.Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
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
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.Related articles Intentional Disregard for Good Engineering Practices? Calculating Value from Software Projects - Estimating is a Risk Reduction Process How to Estimate Any Software Problem Quote of the Day - All Things Project Are Probabilistic Probability and Statistics of Project Work How We Make Decisions is as Important as What We Decide. An Example of Complete Misunderstanding of Project Work Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
"It is the mark of an instructed mind to rest satisfied with the degree of precision that the nature of the subject admits, and not to seek exactness when only an approximation of the truth is possible." Aristotle¬†
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.¬†
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 Related articles Debunking Failure is not an Option Project Risk Management, PMBOK, DoD PMBOK and Edmund Conrow's Book
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?
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.¬†
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:
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.
¬†Related articlesRisk Management is How Adults Manage Projects Making Choices in the Absence of Information Decision Analysis and Software Project Management Risk Management is Project Management for Adults Economics of Software Development How Not To Make Decisions Using Bad Estimates Complex, Complexity, Complicated Software Engineering is a Verb Making Conjectures Without Testable Outcomes
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.