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!
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
In a recent workshop, a¬†participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in¬†What Does Agile Mean to You?)
I suggested this could be his working definition:
That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)
These are practices that increase your agile capabilities:
You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.
I have some previous posts that might be interesting if you also are wondering what agile means for you:
For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.
Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.
We covered how you can think about your geographically distributed agile team:
Here are the articles I mentioned:
I wrote about the timezone bubble chart in¬†Managing Timezones in Geographically Distributed Agile Teams
Here are three posts about¬†Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.
I even had a chance to rant about management.¬†We had a blast, as you can tell. Hope you enjoy it.
I’m a new contributor to the TechBeacon site. I have an article up, called¬†Small-world networks: a lightweight alternative to SAFe for scaling agile.
Hope you enjoy the article.