My answers to "Consolidating the #Estimates/#NoEstimates Debate"

Background

This post is my answers to Shim Maroms questions in his great blog post, which you can read here: http://quantmleap.com/blog/2014/02/consolidating-the-estimatesnoestimates-debate/

I'm a bit late on the response, but I hope you can forgive me. I've been back and forth with this #NoEstimates "thing". At first really into it. But then really disliking it (for various reasons, you can read me other blog posts and get a sense of that yourself). Mainly, I think it was because there where no "general guidelines" or "actionable items" on how to "do it", and that frustrated me. And I'm that kind of person; I like (want) guidelines or books to read, or whatever, to get me started. I can't really think for my self, and that is needed if you're after #NoEstimates ;-)

I also took the "extreme" stance that estimates are always present when making decisions. And I was right, they are always present when making decisions, but then we have to take the broad definition of the term and that is not what #NoEstimates is about. It doesn't mean developer estimates, or the typical formal (usually dysfunctional) delivery of them is always required. That is, the way we usually use estimates in software development today is actually pretty dysfunctional (you all know what I mean). We need none of those, i.e. #NoEstimates.

But now, I have taken the right to define my own version of #NoEstimates. I don't think anyone owns the hashtag, so I guess I'm entitled to define it how I like. You may not like my definition, and you're entitled to not do so as well :-)
But it goes something like this:

"If you have any problem or dysfunction with estimates, it's not the estimates you have a problem/dysfunction with. I.e. a #NoEstimates problem/dysfunction."

What do I mean by that? Well, it means you don't have to try to "improve" your "estimation techniques" or anything like that. Improve other things, like customer collaboration or  how to have an open communication or improve honesty, trust, transparency (or anything typically "agile"). And never "blaim" the estimates if project is late or over budget. It isn't the estimates. Don't even discuss estimates, i.e. a #NoEstimates discussion. It's other things (like dysfunctional management, lack of trust, missing a clear vision, misunderstanding in requirements and/or expectations, no risk handling, bad communication etc etc etc). You can call this root cause analysis, and they will probably never lead you to estimates. They are just that: estimates. If they turns out to be incorrect, something probably happened along the way. They where right, for you, when you did them. And estimates are not meant to be accurate, they are by definition rough (read Merriam-Webster's definition, if you don't believe me). Thus, they are never right (or you're just lucky).

I've also realized (through discussions) that some developers actually writes code without estimates. And it's working for them and the company they work for. I can't deny they exists :-)

But - and this is important - it's not universally applicable and there are no guidelines. Actually, you should not even seek for "no estimates". It might just, sometimes, be a natural outcome of something else. #NoEstimates means you should not let estimates drive you anywhere, not even towards "no estimates" (funny enough).

The reason people are seeking #NoEstimates is because they relate some kind of dysfunction with estimates. We all have that in common. Both proponents and opponents. I see no reason to "start doing 'no estimates'" just for the sake of it.

Long rant about that :-) But it's important for me to let you know this and get you into context before you read my answers. Here they are:

Answers

"Are cost estimates required in order to manage software projects?"

No. But they are usually (almost always) required if someone wants to know cost before deciding to start the project at all. Sometimes getting something out quickly is more important than estimating the cost first. And some companies actually don't let "developer estimates" drive their business, not even for cost. How? Ask them :-) But this is, again, all about context and specific situations. I sometimes write code without estimating the cost first, as well.

"Are cost estimates an effective tool for controlling costs?"

In those situations where they are needed, yes. And those situations are very common :-) In the broad definition I guess cost cannot be anything else than an estimate (when writing software that is). But are "developer cost estimates" an effective tool? Yes, that too. If we remove all dysfunctions that goes along with them (if that is possible), as I've said.

"Do estimates stifle creativity and kill innovation?"

No. But if they are considered as promises (again, another dysfunction) they might create pressure on developers which, in turn, stifle creativity and kill innovation. But not the estimates themselves.

"Do people need estimates? And if so, why?"

Yes. In the broad definition it's what we do all the time. We won't survive without estimate. They've been around since mankind. Even animals estimate. Do people need developer estimates? No. No one really needs those (in that sense). But to know cost of something you must estimate that cost. If we could tell you cost without developer estimates, we would probably do it, thus we don't really need them per se. But, so far, I think there is no other way but to estimate (although some claim they can).
But, my point, if we would remove all associated dysfunctions with estimates, they are a great tool, thus we need them. For knowing cost of something.

"Is the very act of estimation results in the creation of uncertainty?"

Yes. But up to a point it might be silly to try to estimate something. If it's completely unknown how long something might take (that happens) start with a PoC and budget it. What is produced in the PoC can usually be used in production code. Thus, it adds real value and makes further estimation easier. PoC is usually a "no estimates" approach, IMO (in the sense that it's not driven by estimates). Maybe you can do an entire project with PoCs? I don't know

"Is estimation a practice still hanging over from the Waterfall era?"

No. XP and Scrum (considered agile, I'd say) explains how to estimate (story points etc). But most agile principles actually are a step towards less dysfunctional estimates, by highlighting alternative ways to estimate.

"Is No Estimation better than Bad Estimation?"

Strange question. What is a "bad estimate"? You probably don't know that until afterwards. And then, as I've said above, it wasn't the estimate that was bad. If "bad" means: "I'm intentionally making a bad one" I'd say yes. But that's just hypothetical.

"Is Estimation really just a form of Guessing?"

No. If it is, ask yourself why you are guessing. Surely something else (not related to estimates) is wrong.

"Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?"

No. As I've said, if pacifying is needed you have a "no estimates" problem (that is, a problem not rooted in estimates).

"Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren’t estimates a tool used to apportion blame afterwards anyway?"

First question: yes (as I've said, it's not the estimates "fault", it's other things that fail).
Next question: it might be. But, again, you don't have an estimates problem then.

"Is costing a necessary tool for determining business value?"

Yes. But it's very common that the value (or mainly benefit) part is forgotten by customer. They focus merely on cost instead. Or the "value part" is missed to communicate down to the dev team. This is what #NoEstimates is trying to address as well. But the problem is not related to estimates, it's about lack of communication and/or lack of focus on benefits as well as cost.

"Does the scope drive the budget or does the budget drive the cost?"

Depends. Can't easily be answered without context. It's still quite common that the scope drives the budget when it actually doesn't have to. Basing the budget on some optimistic estimates with no margins can be "lethal". It's also quite common that customers don't want to tell their budget. Afraid we might "burn it all", just because we can. Perhaps. But has nothing to do with estimates. It's about low trust and poor communication and/or honesty and collaboration.

"If estimates are required in order to support decisions, can decisions be made without estimates?"

In the broad definition, no. A decision is, by definition, "choosing between future paths". And the cost of choosing one path over another is crucial for decision. Always.
But if we talk about e.g. "formal delivery of an estimate", decisions can be made without those, yes. And decisions can also be made without "developer estimates". For instance if something is really important to get done quickly - and that is more important than knowing the cost before starting.
But the "cost" of all those decisions are in the end: estimates.