The difference between failure and success is the difference between doing something almost right and doing something right.
— Benjamin Franklin
using Principles, Practices, and Processes to Increase Probability of Success
For any closed loop control system ‒ let’s assume we want to manage our project with such a system ‒ has a signal representing the current state of the system. For software, this can be value produced (assuming we have a unit of measure for that value in the for of effectiveness, performance, key performance parameters, or technical performance measures). https://goo.gl/DP6Jw is an overview of this process.
To control this process using feedback and corrective actions ‒ in the same way, your closed loop controller for your air conditioner or heater does - a sampling rate is determined based on the rate of change of the underlying processes.
For a software project, let’s start by answering a critical question – how long are you willing to wait before you find out you’re late? For your Honeywell or Nest controller on the wall, that sample rate is measured in seconds. So the answer to the software question needs to be determined by two things for a closed loop control system:
These measures, corrective actions, and resulting outcomes operate in the presence of statistical and probabilistic processes. Stochastic process control is the field of study. I cut my teeth writing FORTRAN 77 code for the control system for flying, driving, and swimming machines and then for stationary machines, like a power plant, refinery and paper mills.
For the software machines the principles of closed loop control in the presence of noise and changing conditions are the same ‒ https://goo.gl/cUcXNj
The sample rate is also applied to the target to steer toward – the set point in the case of the temperature or cruise control. The estimate of Desired (or even contractual) schedule, cost, or technical performance of the software project.
The granularity of these estimates determining the dynamic behavior of the system ‒ the software project. Too large and accumulation of errors occur. Too small and wasted information is produced and possibly even over controlling the system.
When we hear the question at what level of an agile project do we estimate – Vision, Theme, Release, Feature, Story, or even Task ‒ the first question is again
How long are you willing to wait before you are late, or the room is too hot, or you've driven into the ditch, or the radar station steering control has lost track with the incoming target, or your exothermic reactor has gone over-temperature and blown up?
This answer tells you the granularity of the control systems sampling and corrective actions as well as telling you the granularity of the steering target needed to maintain control of the underlying process.
So don't let anyone suggest estimating at any level - Feature, Stroy, or Task is right or wrong until they can answer...
Managing software development projects is a Closed Loop control system. Subject to all the principles and practices of Closed Loop control. Any suggestion of another method of managing must be tested against these principles first before continuing the conversation.
I saw a blog post about the Top 5 Reasons Your Project Fails recently. They were all good reasons, but those reasons were symptoms, not causes. We seem to always identify the symptoms, but until we fix the cause of failure, those symptoms will return.
The symptoms were:
But these are simply missing practices and processes of the 5 Immutable Principles of project success
So let's look at the symptoms and the principle that could have addressed that symptom
So with the 5 symptoms assigned to the 5 Principles, corrective actions can be put in place to avoid the outcomes.
Never attribute to malevolence what is explicable by incompetence. - Robert J Halon
When we hear all the bad things that go wrong with projects. The misuse and abuse of data, people, tools, and processes, I get a smile when I remember Halon's quote.
Removing things, changing things, installing new things will not address the root cause of bad management and especially bad project management. Only replacing the people will fix the root cause when they are willfully ignorant of how to do it right.
There's a never-ending opportunity to learn how to estimate in the presence of uncertainty. Here's some resources for informing that learning process.
Don't need estimates? - the project is de minimis
The presentation "Quantifying the Impact of Agile Practices," Larry MacCherone at the RallyOn 2013 Conference, presents some results on estimating impacts. The chart below shows 4 estimating types, including No Estimates, the sample sizes for each type and the components that make up the estimating types.
The Software Development Performance Index (SDPI) scale on the left ranges - by eyeball measurement - from 46 to 55.
The Higher the number the better the performance of the process. The presentation speaks to the components of the index further.
But first another piece of information ...
Teams doing Full Scrum have 250% better Quality than teams doing No Estimating
But are these differences meaningful statistically?
Let's start with several reading assignments, before answering
Let's start with the numbers from the chart
Since the raw underlying data is not available, we can't do any p-Factor assessment from the population samples, but there is a simple question that can be asked.
Are there any statistical differences between the 4 SDPI's? If you look below at the quick and dirty assessment of the only data available, it looks like all 4 approaches are within a single digit variances of each other. Not that useful actually.
So the critical question still remains
How can you make a decision in the presence of uncertainty without estimating the impact of that decision?
The essence of mathematics is to not make simple things complicated, but to make complicated things simple - Stan Gudder
This notion that estimating is hard, estimates are a waste because they are always wrong, willfully ignores the basic mathematics of making decisions of in presence of uncertainty. The foundation of all decision-making, Probability and Statistics. Without this understanding there can be no credible information provided to the decision makers.
“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
(Alice’s Adventures in Wonderland, Chapter 6)
When we hear
The idea behind the #NoEstimates approach to software development isn't to eliminate estimates but, rather, to explore other ways to solve problems without specifically asking, 'How long will it take?'
We first need to ask by what principle of decision making in the presence of uncertainty, what kind of business project has no interest in how long will it take? The answer seems to be a de minimis project.
Because in the real world not Wonderland with Unicorns, those paying have some sense of where they want to go, how much they are willing to pay, how long they are willing to wait to get there, and what value will be produced by their investment. De Minimis projects have no concern for those answers.
And those spending that customers money appear not very interested in applying known solutions, instead are answering with the Cheshire Cat's words, since the No Estimates advocates appear to live in Wonderland.
For those interested in learning how to produce credible Estimates and make decisions in the presence of uncertainty, here's some starting places that have served me well:
There are many dozens of other books, and 100's of papers describing how to make estimates in the presence of uncertainty.
After you do some reading and you hear someone say, estimates are hard, estimates are guesses, estimates are always wrong. estimates are a waste, we can decide with estimates, you'll know they didn't read any of these, haven't a clue what they're talking about, and just making things up as the go. Just like the cat
Mike Cottmeyer posted
This is an interesting article that misses the point of what's going on. Companies have too much management because they are poorly architected and not organized around value producing assets. When you don't have sufficient encapsulation, you end up with too much orchestration. Management is not the problem. It's a symptom of the problem. Firing, or redeploying managers, without fixing the underlying organizational issues will fail cause you to faster and harder. The solution is to refactor the organizational architecture, increasing encapsulation, and then redeploy managers as you are able to reduce the need for them.
The root cause of this dysfunction is the lack of line of sight traceability for Why the firm is in business to how the firm fulfills the strategy needed to deliver on that WHY.
Here's one way that has been shown over the years to connect the dots between Why and How and critically importantly, how the projectize the work efforts needed to implement the strategy.
While this quote appears inverted in our self-centered world, the expert has eliminated the nonsensical, naive, amateur, simple minded options and narrowed the choices based principles, practices, and processes of her profession. It is trivially easy to assert I'm exploring new ways of doing things when there is no bounding governance principles to guide your exploration. If the exploration takes place in a de minimis world, the options are boundless.
The SAFe Reference Guide is out.
The website has most everything you need, but it is hard to use and when printed in simplified mode doesn't contain the embedded pictures.
In our local Agile Meetup at Rally, Charles Bradley went through the 3 major methods for agile at scale - SAFe, LeSS, and Nexus
This book is a very useful even if you're not using SAFe, there is invaluable content in the book, including many pages on estimating.
So get the book SAFe , it's the latest in how to manage software development At Scale. LeSS has similar advice, Nexus not so more, you have to attend their classes.
Thanks to Sean Craig's Live Sketch Note for capturing concepts directly from Woody Zuill's talk. This is a good starting point for answering the mail on the notion that decisions can be made in the presence of uncertainty without estimating the impact of those decisions.
Let's look at these Notes and plausible responses to the conjectures. But first, let's look at the motivation for a blog post like this one from Bono's admonition ...
There’s nothing more dangerous than an idea – or a person – that’s almost right. – Bono
I attended our Agile Meetup last night, where the speaker walked through the three current Agile at Scale development methods, all based on Scrum - SAFe, LeSS, and Nexus. He had an interesting statement.
Each of the authors have a different, sometimes slight, sometimes major, approach to producing software using their methods. But each author (or currator of the mehod) has extensive experience testing that method in the field against a broad range of domain and environments. 1,000 to 10's of 1,000's. There is no sure basis of credibilityy for the No Estimates conjecture that decision can be made in the presence of uncertainty without first estimating the impact of the decision.
When we hear a suggestion about a process that inverts the logic of normal business activities based on a governance framework - say Microeconomics of Software Development, we need to ask who benefits? How would that suggestion be tangibly beneficial to the recipient that is now inverted?
Estimates are for the business, why would the business no longer want an estimate of cost, schedule, or technical performance for the provided capabilities they are paying to have developed?
Turns out of course, it's not the business that has lost the need to estimate, it's those spending the money provided by the business that are suggesting estimates are not needed. This conjecture started long ago when an original post, from his chief coder position at the lawn sprinkler company. (I have those sprinkler heads on my lawn, and they're pretty nice). But his conjecture starts with estimates are a waste, not saying for whom they are a waste for.
Anyone in the finance department, paying his salary, paying the developers has a fiduciary need to know what something will cost when it is done. And since ALL and I Mean ALL software development operates in the presence of uncertainty, the only when to have knowledge of that cost, schedule, and technical content is to make estimates. The further conjecture that estimates are hard, can't be made, and are always wrong, simply affirms that those making those claims don't know how to estimate. That is clear, but that has nothing to do with the principles of estimating in the presence of uncertainty.
I'm no longer a developer, having left development in the early 80's after a career of writing FORTRAN 77 code for missile defense systems that is still in place today. But that has nothing to do with the principles, practices, and processes of writing code using current languages and tools. If you find it hard, but go find someone who doesn't find it hard.
So let's look at what's being said here about managing software development in the presence of uncertainty using other people's money
Transformation comes from pursuing profound questions than seeking practical answers
It's not your money
Here's an extract from a Deloitte handbook about business decision making
Effective governance and decision making establishes a framework for transformation and can improve the odds of solidifying change and realizing the benefits of transformation.
Control and Certainty about What?
If you're not managing risk, if you're not making estimates about these risk, you're not managing the project as an adult
Control our Urge to Control Things
If the types of decisions we make requires estimates, then are there better types of decisions?
If you accept that project have uncertainty, then making decisions in the presence of this uncertainty requires you estimate the impact of that decisions. #NoEstimates has yet to state how, in the presence of uncertainty, that a decision can be made with NO Estimates. Only that they are exploring for ways to to this. Been exploring for going on 4 years now, seems to have found nothing. Which would support the notion that the microeconomics of decision making is still in place and any decisions in the presence of uncertainty requires making an estimate.
The Fear of Losing Control is a Big Barrier to Change. Control is Illusion. Fear is Real
Just another platitude without any basis in principles of closed loop business and technical management
The cycle of non-improvement
There is no evidence that No estimates improves anything for those paying for the software development. This is a consistent issue with the conjecture that No Estimates fixes problems, without idnetifying the root cause of the problem, testing the hypothesis that No Estimates fixies the problem, and that this fix can be syndicated beyound the personal ancedote of the orginal conjetcure
What is an Estimate?
This question has a simple answer. It is not a Guess. It is not a promise. This question and the answers used by No Estimates advocates is used to manipulate the situation. Bad Managers use estimates as promises. Those with no experience, skill, or knowledge of estimating consider estimates as Guess's. Both are wrong, both are behaving as if they are in a Dilbert carton, following the script of a dysfunctional set of characters.
There endless numbers of books, papers, tools, classes on how to estimate software projects. These have all been provided in this blog before and can be found again. But here's a starting place - Estimating Software Intensive Systems. Read this and you'll have the start of all you need to break the cycle of uniformed, unsubstantiated states about what is an estimate, how are they made, and how can they be used to make decisions in the presence of uncertainty
Most of the things that matter can't be measured
Let's establish a baseline here. We're writing software for money, usually other people's money. In this context - a business context, Lord Kelvin has good advice for us. Writing software for money is not about the self-actualization of the individuals on the team. That may an outcome, but those paying ae not paying to improve the staff's psychological wellbeing.
When you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind. …It may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science. - Lord Kelvin (1824—1907)
So what is the quest of the advocates of No Estimates? It's not actually clear.
I can only conjecture that the purpose of Not Estimating is to return control of the work processes to those doing the work by removing the decision making processes from those owning the money. It's the anarchistic approach to software development.
I, the one providing the labor in exchange for payment, am the one who will be telling you, the paying, when I'll be done, how much it will cost when I'm done, and what you'll be getting for that time and money. I am the one in charge of the effort to spend your money.
Thought interferes with the probability of events, and in the long run therefore, with entropy - David L. Waston (1930)
All project work is probabilistic, driven by underlying uncertainties, both reducible and irreducible. Willing an outcome in the presence of these uncertainties does not make is so. The only useful process to manage in the presence of uncertainty is to estimate the outcome of any decisions made by the participants of the processes by which the project operates
The mantra of Agile is Trust the team. In some domains, that is an admirable goal. In other domains it's a naïve path to disaster. I work in the latter domain, on mission critical, sometimes national asset programs, but always mission critical - can't fail, must work, must provide proper information when called upon to do so.
When we are called on to perform a Root Cause Analysis of why the system failed to do what it was suppose to be, we find the same thing that Dr. Bill Corcoran suggest is found on all root cause analysis processes.
An inescapable fact is that the competent investigation of every harmful event reveals that the causation of the harm includes the mistaken/ naïve/ unwarranted/ gullible/ imprudent trust and confidence in one or more erroneous/ untrustworthy theories, assumptions, standards, devices, procedures, processes, programs, people, institutions, agencies, contractors, and/or conditions. The functional alternatives include monitoring, curiosity, skepticism, and the “questioning attitude.”
Here's some quotes to apply when you hear agile means trust of the team, why are you questioning our processes, our methods, our organizational models. (Thanks to Dr. Corcorn's news feed today):
So saying it again for clarity - you can't make a decsion in the presence of uncertaty without estimating the outcome of that decision. When you do, be preared to conduct a Root Cause Analysis of why your project went in the ditch. Trust is necessary but far from sufficient when spending other people's money on non-trivial development efforts.
Much of the discussion around project management processes, especially around agile, and most especially around the misconceptions of Estimating as espoused by the #NoEstimates advocates, starts with the misuse of reductive reasons based on single factor analysis.
Here's how it goes.
When we see these two concepts used together we get things like as the cartoon of the Reductionist view of a single concept - If you did it this way, you'd be from 3X to 10X faster.
So here's the problem and the solution. Complex systems are part of the solution to all complex problems. Anyone claim complex problems can be solved with simple systems, needs to have a testable working system, in that complex problem space. I work in a complex problem space - literally space flight, aircraft flight, the ground systems that enable those systems to Fly. As well as biopharma, electric utilities (nuclear and conventional fired), complex enterprise IT systems (dozens to many dozens of interacting systems).
When you hear a simple and many time simple-minded solution to a complex problem - Applying No Estimates will remove the dysfunction on software projects (this is the ontological inverse of the statement estimates are the smell of dysfunction). We can be reminded by H L Menken's quote:
For every complex problem there is an answer that is clear, simple, and wrong.