I think this is a simple question:
In your software development efforts, would you eliminate estimates* if you found they bring no value? Put another way, if it costs (time, money, effort, whatever) to do estimates, and you get no return for that expense AT ALL, would you still do those estimates?
Few Are Willing To Answer This Question Outright
I’ve asked this question to about 50 people (face-to-face, in conference sessions, in “Skype” conversations, and in other forums) and here are some of the typical things I hear in response (note that these “answers” don’t answer the question at all):
- I still like estimates, even if they bring no value, because they help me think about my work
- We NEED estimates to make decisions
- I just use them to determine velocity
- My boss still requires them, even if I think they are waste
- We need estimates to be able to bid jobs – our customers require them
- It depends on the context
I rarely hear the answer I originally thought I would hear:
- Dang right I’d eliminate them! Anything that is a cost that brings no value is WASTE and I would rather spend my money some better way. I won’t keep any process, practice, procedure, policy, or plan with no pay-off. (And quit spitting, will ya?)
I hear a more reasonable answer when I ask the question like this:
Same question (more or less) without the word “estimates”: If waste is anything that has a cost but has no value, would you eliminate waste from your process were you to find it?
Most of the time the answer I hear to this is “You bet I would”.
It seems to me, for the time being anyway, that there is some sort of problem people have when I insert “estimates” into the conversation.
The question is hypothetical
Why are few willing to actually answer the question, and instead “dodge it”? I don’t know. I might be asking it wrong.
I pose hypothetical questions to myself all the time. One of my favorite “thinking tools” is to take the opposite side of some belief I have. For example: I love pair programming. It feels right, helps me work faster and stay on track, accelerates my learning, gives me confidence in my code, things like that. So, I will challenge myself and ask: What if I’m wrong? What if pair programming is a wasteful practice? How could I prove that? What would I do if I did prove it?
Exploration of questions like these help me grow my ability to do continuous improvement. At least it feels that way to me.
I’m Dedicated To Making Things Better
I am always on the alert for waste. It comes in many forms, yet it is often hidden, or disguised as something of value. It’s fun, interesting, exciting even, to find and eliminate waste. And, it is just plain good business. A penny saved is ten cents earned. If you don’t understand how that works, I’ll explain it some other time.
I find it helpful to remember the old Einstein saying about insanity, which I paraphrase here: We keep doing this, it doesn’t seem to work, we need to do better next time, we try to do better, things never get better. Perhaps “getting better at this” is failing, and “this” is not the right thing to do at all.
Once I’ve opened my eyes to the possibilities, I usually find big improvements are going to start happening. The old thinking and old practices that have been blocking me from “better” are gone, and I can allow myself to imagine the possibilities, and to start innovating.
All I ask
So here is what I ask: Think of it like debate class.
The proposition: “Estimates are waste and we must eliminate estimates in software development”.
Take the affirmative position supporting the proposition, and prepare your arguments. Suggest ways you could prove that estimates are a waste. Propose how you could replace estimates in your process. Imagine you could convince your customer to hire your company without a bidding process – perhaps something more like choosing a doctor than buying a car. Stuff like that.
We won’t really debate – this is just an exercise. Are you willing to stretch your thinking a bit? It shouldn’t take long. And you can quit any time and watch TV instead.
Some other posts I’ve written on the topic of estimating:
- Estimation is Easy and Useful: Estimate a game of Chess
- Do Estimates Do What We Want Them To Do?
- No Estimate Programming Series – Intro Post
- No Estimate Approach For End-Of-Life Legacy Support
- Notes From A Conference Session On No Estimates in Software Development
- A Comment And Response from Estimate Chess Post
- Can We Code Without Estimates?
* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.
Disclaimer: There are many situations where estimates can be meaningful and useful. This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.