Herding Cats: #Noestimates Has Come to This

June 02, 2017

#Noestimates Has Come to This

This is a chart from an agile conference where #Noestimates was a topic. For the most part, the briefing follows Tony Magennis' approach from his book. So the first part is following standard estimating principles. What's fascinating is the evolution from the original post going on 4 years ago ...

... which states clearly and concisely that decisions can be made (in the presence of uncertainty - which is ALWAYS present on software development projects) - WITHOUT estimating the impact of those decisions.

To this Manifesto style statement that is restating in different words the principles used in all estimating processes in any domain as well as the estimating principles stated in the references found in Chapter 5 of the Bibliography for Agile at Scale.

So let's look at this manifesto:

Probabilistic over Deterministic - there is NO deterministic process in software development. There's not even a deterministic process in the production of Toyota Camry's. It's always probabilistic. By probability, it means there is uncertainty. Actually, these processes are both probabilistic processes and statistical processes which produce Uncertainty in two forms: Aleatory and Epistemic. Aleatory uncertainty produces an irreducible risk to the project. Only margin can be used to protect against aleatory uncertainty. Epistemic uncertainty produces reducible risk, which can be dealt with directly with experiments, tests, redundancy, and other intervention processing. So no credible management system assumes a deterministic process. If it does it's doomed to fail on day one.
Delivery over Development Time - to Deliver you need to Develop. The granularity of the delivery is the flexible parameter. It's a strawman to use waterfall anymore. Even in the US DOD Waterfall is not allowed. So drop the Waterfall Strawman. Our performance management system requires an assessment of Physical Percent Complete every month in the Integrated Performance Management Report (IPMR). To have this be credible, we status the work every Thursday with Physical Percent Complete assessment. This manifesto statement is a false equivalency. ^†
MVP Scope over Full Scope - the full scope of any project is NOT possible in any real sense up front on any Software Intensive System of Systems (our domain). It's rarely possible to have that much insight into any development project. From large construction to software development. This is another false equivalency. Rolling waves, planning packages, emerging processes are all standard project management processes.
Data over Intuition - this is an example of not attending the High School statistics class. Past performance, reference classes, parametric models, Monte Carlo simulation, method of moments, and other estimating processes are standard practice. In our domain, best engineering estimates are the LEAST desirable form of estimation, and in some acquisition domains not allowed. Another false equivalency.

There are lots of issues with estimating, even in sophisticated estimating environments. I work several programs with state-of-the-art estimating processes and tools and we still have issues. Does that mean we don't need estimating?

Hardley, and here's why.

These are better questions to ask, but these questions do not lead to the answer of #NoEstimates either. So let's answer these questions with the material found in existing guidance...

In what context would estimates bring value, and what are we willing to do about it? This is one of those inverted logic question used by #Noestimates advocates - like so senator when did you stop beating your wife? The real question is when are estimates NOT providing value? The simple answer is when we are working a de minimus project. That is when there is no downside to being wrong about the cost and schedule. If you accept the There is NO Principle ... quote above about making decisions in the presence of uncertainty, then an estimate of some kind is needed to decide.
How much time do we want to invest in this? This is a simple question and answer. What's the Value at Risk? Low risk - low value, quick estimate. High Risk and/or High Value, you'd better have a higher confidence of that cost and schedule, along with the increased probability that you'll be delivering the right value at the needed time for the needed cost top those paying for that value. By the way, YOU CANNOT KNOW THE VALUE OF ANYTHING WITHOUT KNOWING THE COST TO ACHIEVE THAT VALUE. This is basic Microeconomics of decision making.
What can you do to maximize value and reduce risk in planning and delivery? You can start with Tim Lister's quote. Risk Management is How Adults Manage Projects. Risk management means managing in the presence of Aleatory and Epistemic uncertainty. This management REQUIRES you make estimates. No Estimates? No Risk Management. No Risk Management? No Adult Management. Be an adult, manage risk with estimates of aleatory and epistemic uncertainty, estimates of the impact of those risks if they were to turn into issues, the estimates of the cost to mitigate those risks, estimates of the residual uncertainty, and estimates of the impacts of that residual certainty.

† False equivalence is a logical fallacy in which two opposing arguments appear to be logically equivalent when in fact they are not. This fallacy is categorized as a fallacy of inconsistency.

Posted at 02:08 PM in #NoEstimates, Capabilities, Decision Making, Economics, Estimating, Governance, Management, Performance-Based Project Management®, Planning | Permalink

Comments

So let's look at this manifesto:

Probabilistic over Deterministic - there is NO deterministic process in software development. There's not even a deterministic process in the production of Toyota Camry's. It's always probabilistic. By probability, it means there is uncertainty. Actually, these processes are both probabilistic processes and statistical processes which produce Uncertainty in two forms: Aleatory and Epistemic. Aleatory uncertainty produces an irreducible risk to the project. Only margin can be used to protect against aleatory uncertainty. Epistemic uncertainty produces reducible risk, which can be dealt with directly with experiments, tests, redundancy, and other intervention processing. So no credible management system assumes a deterministic process. If it does it's doomed to fail on day one.
Delivery over Development Time - to Deliver you need to Develop. The granularity of the delivery is the flexible parameter. It's a strawman to use waterfall anymore. Even in the US DOD Waterfall is not allowed. So drop the Waterfall Strawman. Our performance management system requires an assessment of Physical Percent Complete every month in the Integrated Performance Management Report (IPMR). To have this be credible, we status the work every Thursday with Physical Percent Complete assessment. This manifesto statement is a false equivalency. ^†
MVP Scope over Full Scope - the full scope of any project is NOT possible in any real sense up front on any Software Intensive System of Systems (our domain). It's rarely possible to have that much insight into any development project. From large construction to software development. This is another false equivalency. Rolling waves, planning packages, emerging processes are all standard project management processes.
Data over Intuition - this is an example of not attending the High School statistics class. Past performance, reference classes, parametric models, Monte Carlo simulation, method of moments, and other estimating processes are standard practice. In our domain, best engineering estimates are the LEAST desirable form of estimation, and in some acquisition domains not allowed. Another false equivalency.

Hardley, and here's why.

These are better questions to ask, but these questions do not lead to the answer of #NoEstimates either. So let's answer these questions with the material found in existing guidance...

In what context would estimates bring value, and what are we willing to do about it? This is one of those inverted logic question used by #Noestimates advocates - like so senator when did you stop beating your wife? The real question is when are estimates NOT providing value? The simple answer is when we are working a de minimus project. That is when there is no downside to being wrong about the cost and schedule. If you accept the There is NO Principle ... quote above about making decisions in the presence of uncertainty, then an estimate of some kind is needed to decide.
How much time do we want to invest in this? This is a simple question and answer. What's the Value at Risk? Low risk - low value, quick estimate. High Risk and/or High Value, you'd better have a higher confidence of that cost and schedule, along with the increased probability that you'll be delivering the right value at the needed time for the needed cost top those paying for that value. By the way, YOU CANNOT KNOW THE VALUE OF ANYTHING WITHOUT KNOWING THE COST TO ACHIEVE THAT VALUE. This is basic Microeconomics of decision making.
What can you do to maximize value and reduce risk in planning and delivery? You can start with Tim Lister's quote. Risk Management is How Adults Manage Projects. Risk management means managing in the presence of Aleatory and Epistemic uncertainty. This management REQUIRES you make estimates. No Estimates? No Risk Management. No Risk Management? No Adult Management. Be an adult, manage risk with estimates of aleatory and epistemic uncertainty, estimates of the impact of those risks if they were to turn into issues, the estimates of the cost to mitigate those risks, estimates of the residual uncertainty, and estimates of the impacts of that residual certainty.

† False equivalence is a logical fallacy in which two opposing arguments appear to be logically equivalent when in fact they are not. This fallacy is categorized as a fallacy of inconsistency.