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 method) 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 credibility 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 is 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 way 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 are still in place today. But that has nothing to do with the principles, practices, and processes of writing code using current languages and tools.
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
- Let's assume we are in the business of spending other people'ss money to produce value in exchange for that money.
- It is likely those paying us have some sort of governance process in place for managing the spend of that money.
- Governance is about decision rights. Who has the Right to decide?
- Asking profound questions? Who's job is that? Those spending or those paying? This is a crass point of view I know. But in many ways, business is crass, harsh, rude, to the point. It's about the money. Unless we live and work in a socialist society, someone has to pay for our efforts. That someone has and expectation of getting their money back, plus some more sometime in the future. That expectation is called Return on Investment and requires some knowledge about the future - the uncertain future - to make a decision today. It is always encouraged to ask questions. But in the end, those paying have the say on how the money is spent, NOT those spending the money. Anyone not understanding that has no understanding how business works. It's not a democracy, it's a business.
- So practical answers are less important than profound questions? Interesting conjecture. Who's most interested in practical answers and profound questions? Those paying or those spending.
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.
- So when we hear about transformation what does that actually mean?
- Transforming how the business works? Process improvement?
- Transforming how we develop software? New methods, processes, tools?
- Transforming how we spend money? Better ROI, some magic formula for better ROI?
- Woody doesn't say. It's just transformation.
- What are the profound questions?
- For the business, a few profound questions of a time cost of money project are likely
- When will we be done?
- Will we show up on the needed date with the needed Features?
- For the business, a few profound questions of a time cost of money project are likely
Control and Certainty about What?
- There is no such thing as a certainty on projects - this is a false argument, has been a false argument since man started building things, anything, not just software.
- Projects are uncertain. Uncertainty creates risk.
- Uncertainty come in two types and these two types of uncertainty are always present on projects
- Reducible uncertainty - Epistemic uncertainty, which can be handled with margin and redundancy
- Irreducible uncertainty - Aleatory uncertainty, which can ONLY be handled with margin
- Uncertainty is the source risk. Risk does not exist in the absence of uncertainty.
- Risk Managment is How Adults Manage Projects - Tim Lister
- Risk management requires making estimates of the probability of occurrence, the statistical behavior of underlying processes, the probability of the impact of the risk if it were to come true and become an issue, the probability of the residual risk even after the actual risk has been mitigated
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
- Managing the spend of other people's money, while producing value in exchange for that money means having control to some degree of that spend process.
- Management is a verb
- Management is a closed loop process
- Close loop process makes use of control to keep the process (development of software) moving toward the target
- Without control, the project is Open Loop
- Open Loop control doesn't use feedback to take corrective actions
- Not estimating is Open Loop control. Another No Estimates advocate claims NE is closed loop control. I suspect he didn't attend a Process Control Systems class, nor has any understanding of control system loops.
If the types of decisions we make requires estimates, then are there better types of decisions?
- This is a typical question like when did you stop beating your wife Senator? It's a question designed to have no answer but rather make some unsubstantiated statement.
- Not sure there are types of decisions unless there are decisions in the absence of uncertainty and decisions in the presence of uncertainty
- If there is no uncertainty, making a decision is easy, no need to estimate. It's obvious what to do, obvious the outcome.
- Never seen a project where there is no uncertainty. Even production lines have uncertainties during the day.
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
- This is one of those platitude statements Woody loves to make.
- Would he say that about driving his car?
- Would he say that about skiing in the back bowls of Vail?
- Would he say that about his 401(k) investment plan?
- How about the cost budget for the room addition to his house?
- Closed loop control is control in the presence of emerging drivers.
- Open loop control is Not control from external drivers, but manual change.
Just another platitude without any basis in principles of closed loop business and technical management
The cycle of non-improvement
- The cycle of estimate, work, estimates off, requirements unclear, invest in better estimates and requirements is labeled as a cycle of non-improvement.
- No root cause for this behavior, just a statement of bad behavior.
- Without root cause, only the symptom is observed.
- Without root cause, any suggestion of a corrective action - no estimates - has no credibility, since the problem has not been identified but the solution is proposed.
- Any proposed solution to stop doing something requires direct evidence that not estimating will improve requirements fidelity and improve the probability of delivering the needed software as needed.
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 Guesses. Both are wrong, both are behaving as if they are in a Dilbert cartoon, 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 uninformed, 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
- Matter to whom?
- It must matter to those paying.
- For those paying, measuring is a critical success factor for determining of the money is returning the expected value at the expected time.
- Without asking and answering that question Woody's quote has no basis of applicability.
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.
- Improve the probability of success of project work? Can't see how that can be, since making decisions in the presence of uncertainty - which appears on all projects - requires we make estimates about the outcomes of those decisions.
- Reduce the workload on the developers of software products or services? Perhaps, but that leaves open the need to have some probabilistic understanding of where the project is going in the presence of uncertainty to someone else.
- Reduce or remove the dysfunction of managers in making decisions in the presence of uncertainty? Certainly not, since that uncertainty is present whether you estimate it's impacts or not. Not Estimating does not remove the dysfunction of humans.
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.