 |
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.
|
