Don't Do Stupid Things On Purpose - Is it stupid?

"DDSTOP - Don't Do Stupid On Purpose". I came across this by Mr Glen B. Alleman on twitter. You can read some of what he's written on the topic here: http://herdingcats.typepad.com/my_weblog/2014/05/ddstop.html
It's aimed at the #NoEstimates movement. But DDSTOP doesn't seem to originate from that (if you read the post, at least).

DDSTOP sounds good at a first glance. We should actually not do stupid things on purpose. And sometimes it kind of feels like we do, at least I feel that. It happened today actually. We were requested to estimate a change request that wasn't really thought through. At least we had quite low confidence in giving a credible estimate on the effort required. So for a while we talked about how we could give an estimate and what it should be at. Then it struck me; "Wait a minute! Customer collaboration! Let's book a meeting instead and go through this together with them. Why not even let them hear what we think, directly, instead of 'delivering' the estimate." Everyone in the team agreed. Meeting is now booked. To be continued... :-) I call this approach "no estimates", because we made a decision without estimates - we decided to *not* provide an estimate, i.e. "no estimates". We *will* give an estimate. And that leaves me with: "no estimates" is not "never estimate". And we also avoided a "misuse" of them; we avoided a "guesstimate". And doing the estimate in collaboration with customer at the same time as we look at what is to be done, is also much better, in my opinion. But now I'm really off-topic...

I don't really like DDSTOP as an approach or mindset or whatever it is. I feel it has a "blame" tone. Like: "I/You/He/She did a stupid thing, shame on me/you/him/her!". And even if we don't actually say that, we might implicitly set a culture of not wanting to try new stuff; "Oh, I don't dare to try/do this, it might be stupid, someone might even interpret it as me being stupid on purpose... That banner over there says that and all, oh well...". In my opinion, that is not a culture we should foster. In fact, quite the contrary.

I claim we actually *should* do stupid things! It reminds me of a movie quote I love. From The Three Musketeers. D'Artagnan is about to leave his parents to meet the world and seek adventures:

D'Artagnan's Father: There's one more piece of advice.

D'Artagnan: I know, I know. Don't get into any trouble.

D'Artagnan's Father: Wrong. Get into trouble. Make mistakes. Fight, love, live. And remember, always, you're a Gascon and our son. Now go. Go.

(http://www.imdb.com/title/tt1509767/quotes?item=qt1793828)

A wonderful advice!

My take: Try! Fail! Learn! Be creative! Ignore stupid!

And when someone makes an obvious stupid thing, shame on *us* (as a system or organization) for allowing it to happen. See it as something positive! A chance of learning - and improvement - in the organization. And not just wag it off as "that was just X doing a stupid thing, and furthermore on purpose". There is no learning and improvement in that mindset (or whatever it is).

Taking the example from Glen's blog above; a foam filler was used without reading the directions on its applicable.

"Stupid! And on purpose; not reading the directions."

Well I'd say: "Shame on *us* for not educating people on how to use the foam filler instead, and other safety equipment. Maybe we should even arrange other courses on how to perform CPR as well?"

It's "culturally" important to not put any blame on employees. Not even a slight indication that we do. Not even open up for misinterpretation of the concept that might lead in that direction (I obviously might have misinterpreted DDSTOP. But if I have, others will as well). Because it might lessen (or even kill?) the company's most precious recourses; creativity, innovation and learning.

I think that banner was actually a rather bad idea. I think DDSTOP as a way of thinking is a bad idea. Not stupid though... ;-)

#NoEstimates is not #NeverEstimate - my take

This is not a true story, I'm sorry. But I really think this is an approach a company could use. And there are probably companies out there that are doing this, daily. I just want to give an example to state my view.

If you follow the #NoEstimates discussion you might come across the statement that "#NoEstimates != #NeverEstimate" ("!=" is a programmatic operator (in some languages) that means "not equal to"). But what does that mean? In twitter discussions (where most of the discussions happen) it kind of tends to become "defend your point stances" like discussions. What I mean is; it feels like it becomes a "never estimate" vs "always estimate" discussion - even though we say #NoEstimates actually doesn't mean "never estimate" (or that opponents actually thinks that "always estimate" is something great too?).

This is unfortunate in my opinion. It muddles the real topic.

So, to give some "credibility" to my points - because I believe in the ideas/thoughts behind #NoEstimates - I'm going to give an example of what "it doesn't mean #NeverEstimate" means, in my opinion.

These thoughts comes from after reading the book "The Lean Startup" by Eric Ries (http://theleanstartup.com/). Those of you who have read the book will recognise the idea I'm presenting and those of you that haven't; read it! It also has some big influences from the "Impact Mapping" idea (http://impactmapping.org/) - read that book too, if you haven't.

An Example

Let's say I have a customer that wants to "update the design of their web site". There's nothing wrong with that, right? Now they want to know what that will cost and when it can be expected to be finished. They might crank in some additional changes when they are at it, or not. Doesn't really matter here.

Now what happens? Well, first they have to contact some web designer company that have to look at this and give an estimated cost of what a "design update" might cost. When that's done someone has to implement the design into the real web site ("real code"). That's probably another company who does that - they need to give an estimate of cost for the update as well.

Nothing strange going on here. The project might even (unusually) be on time/budget in this example as well. All is fine. All companies involved might even celebrate the "Web Site Design Update" project. A true success! And it is. ...or is it?

I mean, in a project sense it is. We didn't break budget and we released on time. That *is* great. But still... all that time and money spent - was it worth it?

I guess no one really knows.

Because what is the hypothesis? What assumptions about our web site user's behavior have we made? What is it we want to learn about them and their behaviors that will give us a competitive advantage? In what way will they help us earn/save money? And - very important - how can we measure that our hypothesis is correct or not?

Well, we do it by making experiments. Trying/testing our hypothesis. Thinking small. Focusing on how we can gain (measure) that knowledge as cheap and fast as possible - by cutting all waste, that is; remove everything that doesn't contribute to the learning we seek. Doing minimal effort to get to that knowledge.

How can we apply this here?

Well, what's the hypothesis about updating the web site design. Well, that depends on what the company do. But let's pretend that the main purpose of the web site is to steer the visitors to a certain place or doing something special; like "becoming an applicant for X" (there can be many different purposes of a website that gives a company real value - that is $$$, in the end).

I guess the hypothesis then becomes: "If we update the design, more visitors will apply for X".

Now, that becomes: "How can we prove this assumption is correct?" "What's the minimum thing we can do to test it, and how can we measure that what we do is the actually affecting those metrics?"

On a web site, let's do an "A/B test". That is, let half of (or maybe a specific set of) users see and use the new design and let others see the old one. Try it on just the start page or a specific flow. And while having this focus on "experiment", maybe we should look at improving the user experience as well? An idea we might not have come up with at all if we just focused on "updating the design"..?

The outcome of this might be that the new design had no, or little, impact at all on the behavior of our customers/visitors.

Then an update of the *entire* site might not be what we should spend our money on. This "failure" (hypothesis turned out to be incorrect) is great! We have *learned* something about our customers and their behaviors. We can use that to our advantage. "What more can we learn!"

But also. We haven't spend a lot of time and money on all the estimates and the time and money on updating the entire site - which would have proven to be a "failure" in the end anyway; but a costly failure, a late failure.

But - now to the point - there are estimates here (maybe it doesn't really have to..?)

We have to give some judgment on how much to spend (estimate) and how long it will take (estimate) to perform this experiment, because an experiment isn't free :-). But, I rather give an estimate under these conditions. And it's less "sensitive" if a "1 month" estimated cost is "off" then if a "6 months" estimate is.

And what if the assumption turned out to be right; the new design made a great impact on e.g. the number of applicants? Well, either we estimate the cost of updating the rest of the web site, or we iterate with next assumption or whatever we want to learn next. 

If we choose to update the entire site we now have a much better certainty on the effort of doing so, since we have already done some.

But by choosing to do this in small batches there are other benefits as well. Instead of having the design team hand-off their designs to the next team and move on with their next project - we work together. And we will save time and money! Why? Because if the design team move on with another project they might have to be interrupted in that project when the other team have questions on how to implement the design or problems occur. Those interruptions can be costly and cause delays - and most certainly if these interruptions becomes "the norm". 

To quote Peter Drucker (I'm not sure it was actually he who said it, but it's attributed to him):

"There is nothing so useless as doing efficiently that which should not be done at all."

My Rules of Estimation

In this post I'm just going to write down some of the things I've found about estimates. That is: when estimates fill a purpose (some say they *always* do, and I'm more into the ideas of #NoEstimates to lessen the dependency on estimates... But this is off topic in this post).

These are things that apply to me and the situation and context I'm in (types of customers I have, size of projects etc). I'm not saying these are universal truths or are general guidelines. It's merely my opinions. There's no real news in here either, it's rather old stuff. I just want to share them and keep this as a reminder to my future self.

I won't go into lots of details on these items, just list them as shorter notes. I might revisit these items later on and update them.

1. Estimate or commitment?
   Someone buying software (or anything really) aren't that interested in estimates. They seek commitment (promises). So they are probably not asking for estimates, but for a commitment. But don't confuse estimates with commitments, two different things and requires different approaches. Here's a metaphor on the difference I like (by Mike Cohn): http://mountaingoatsoftware.com/blog/separate-estimating-from-committing
2. Find out the budget
   It's there for sure. Then try to discuss what can be built for that amount of money. If they don't want to tell their budget (it's a trust issue really but...) it's rather easy to find it out anyway; Tell them something clearly too high and work your way down ;-)
3. Find out the "roughness"
   Maybe "This year" is okay as an answer? Or "Less than a month"? Don't just assume they want "estimates as you usually do". Probably they don't need precise answers - you just provide it anyway - they need accurate answers (I'll get to this soon). But, if they really seek a precise answer it's a sign of something that is probably a bit risky and you should look out for it.
4. Find out the value
   If the cost is to be estimated, the value must also be estimated. Calculate the Return Of Investment (ROI). If value and cost is close (low ROI value), it's probably time to cut scope. It's a risk anyway, and it should be discussed with customer. Sometimes this can reveal the level of "roughness" on the cost estimates as well (item 3). Maybe cost isn't that relevant (high ROI value)?
   Value always trumps cost!
   Sometimes they can't (or won't - a sign of trust issue?) estimate the value. If so, one could really ask why this project should be carried out at all..? Anyway, go back to item 2 and you probably have the value somewhere...
5. Estimate in collaboration
   Who says we can't estimate together? I've written a blog post that touches that subject: http://kodkreator.blogspot.se/2014/03/what-noestimates-has-taught-me.html
   "Customer collaboration" right? I see no problem in this if there is trust (and maybe even if there isn't?). A customer might have much valuable information to provide when estimating. At least they will learn - and feel they are a part of and/or have opinions about - the estimation process you have and the estimates you come up with. Great value, in my opinion. They might claim it's a waste of their time. But I think it can be very valuable for them. We have nothing to hide, right?
   If it's not possible to estimate in collaboration at least don't present your estimate as a "truth" or "this is how it's going to be". Collaborate! Help. Guide. Tell where there are uncertainties or where you feel there should be margins. Tell them some margins might be used, some don't. It's like inviting people for dinner - you want people to be satisfied so you tend to buy too much food, and it's okay. Discuss risks. Read more here: http://www.leadingagile.com/2014/02/use-agile-build-next-home/
6. Confidence level
   Try to provide your estimates with a confidence level. This is actually not used at all where I work, but claimed to be utterly insane not to in other domains.
   Create a graph (usually in a Weibull distribution form), it doesn't have to take much time to create or use maths. Just use your "best bet" and then min-max values and create a distribution curve by free hand, it's enough to give you an overview of your initial "best bet" estimate. And discuss what you should "commit" to.
7. Don't be an optimist!
   There might be a good reason for you to be... But usually - and especially with estimates - there might not be a reason to be. Ask yourself: "Who will benefit from us being optimistic here and not be pessimistic instead?" There might be reasons, as I said, but usually not. One reason I can come up with is if there is no true "benefit" from doing a software project, like updating to a new version of some CMS or something. But one could really ask why we should do it, if there is no clear "value" in doing it.
   Read some of what I've written here: http://kodkreator.blogspot.se/2012/01/my-estimates-are-too-optimistic.html But always remember "Hofstadter's law": http://en.wikipedia.org/wiki/Hofstadter's_law
8. Preciseness is not accuracy! 
   For instance: "952 hours" is not a good estimate. If anything it might clearly show that it's a sum from a number of other estimates. But, please, stop provide estimates like that!
   It's better to be correct than precise. It's better to say "By the end of this year" or "In august" than to say "2 August". Let the specific date be decided later on. Maybe you don't have to present the exact number of hours you estimated at all? Maybe you even shouldn't? Customer is probably only interested in what it's going to cost and roughly when to expect it.
9. Always keep a deadline - however it was set!
   Okay, this is not true. There might be good reasons to postpone a deadline, but it's a provocative title right :-)
   Anyway, I actually thinks deadlines - often - should be held. Even if they are off. Postponing deadlines can be discouraging for both the team and your customer. And it always feels good to make the "finish line". And you probably have *something* to deploy.
   What do you do? Trim the tail! Read more here: http://www.crosstalkonline.org/storage/issue-archives/2014/201407/201407-Cockburn.pdf
10. Say No (or: don't always say Yes)!
    Even if I like item 9 it doesn't always work (as I've said). There's still something else you should keep doing during project: say "No". Or actually - and better explained - don't always say "Yes!" to everything. If things change (and they will) we have to say "This will make the initial estimate a bit obsolete" and re-estimate (if needed). There's nothing wrong (in my opinion) to re-estimate if things change, even small things might affect schedule (and surely if you provide those precise estimates I talked about). Read more here: http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question
    Real user input is always good and should be encouraged. But all changes comes at a price (when you drive with estimates (or you could think about trying to lessen the estimate driving i.e. #NoEstimates. Damn! Now I'm there again. Sorry.)).
11. Intervals
    Presenting estimates as intervals is okay. And sometimes even preferable to e.g. mark some kind of uncertainty or confidence. It will keep your back safe at least :-)
    But remember that some customers might tend to hear the lower interval while you tend to hear the higher. And you run a risk that the lower value will start traveling in the organisation... (dysfunctional, yes, but there's always a risk).
12. Focus on iterations
    Do everything you can to always try to have something "usable" to deliver. Don't build (arbitrary) parts of the system/application but ask instead: "If we abort this project after the next sprint/iteration and deliver - what will it look like then?" That is, focus on the most important things first.
    Try to have a "beta site" or "beta application" and continuously deploy to it. Let real users see it and use it - get real feedback. Don't listen to *all* feedback, but more is better than less (and one is infinitely better than zero).
13. Prototype!
    You don't have to stop prototyping (and by "prototype" I include things like mockups e.g. in Balsamiq) just because project has started (and please use prototypes before you start the project as well). Don't finish all the nifty little details 100% (see previous item as well); give users something they can see and interact with. It doesn't have to work all the way to database and handle all "edge cases" etc. Read more here: https://medium.com/@ppolsinelli/from-noestimates-to-yesprototypes-1b51f6a63e5d
    Remember that real user input is something good! Change is better than following a plan, right?

Remember, this list is mainly written for my own purpose, and it fits me and my context. But I'll be happy if you would like to provide some comments on your thoughts and opinions.

Capabilities (or why IT projects fail)

When you (as a company/organization/department/whatever) have an idea or a need or a problem you want to solve you may not have the ability to materialize the idea or solve the need/problem. You then need an ability to do it - a capability. That's the definition of "capability" I'd like to use when it comes to software (or IT in general).

If a company have an idea/problem/need that might result in them wanting some kind of capability that requires software.

Now, they want to know what that capability (via software) is going to cost them to get and maybe they need it at a specific date or at least when to expect to have their new capability ready. Nothing strange, who wouldn't?

The software is built. It might unfortunately be over budget (underestimated obviously), late (underestimated obviously) or it didn't provide the capability they needed.
But, I say it really doesn't have to matter. At least why it is a "fail". Maybe it's on (or below?) budget, on time (or maybe early?) and the right capability was provided and it still is a "fail". Why? Because the idea wasn't that good or the need wasn't really something someone actually had or solving the problem didn't really mattered.

So, how can you know before you have the capability? Well, you can't. The only way to know is to actually have it. But. There's a mind shift here. (Some are actually already doing this) Validate. At the end of the day it's all about learning. You want to learn that your idea is good or that the need is actually a need someone has or that solving a problem is worthwhile. And eventually you *will* learn (or not, if you choose not to do it).
And you can only *assume* that the capability will give you that learning.

Now, you can either start thinking about it (analyzing) or you can start acting, creating. That's the mind shift. I'm not saying: Stop thinking! Stop analyzing! But instead of "Let's postpone this to next meeting" (or whatever), think "What can we do today/tomorrow that will bring us learning about this? Is there anything small we can start doing?". I.e. how can we try - and validate - this assumption we have? Anything? Think "small". Think "learn". Think "validate".

If I take it to the extreme, I basically think they have two options (according to The Rule of Three they should have three options and not two, because 1 option is a trap, 2 is a dilemma, 3 is a choice :-) - heard through George Dinwiddie and Jerry Weinberg. But I'll let you ponder on that third option yourself. Or let all the "gray zones" in between these two extremes be those options).

1. Assume there's a software project ahead and start defining it. Gathering requirements, start planning, estimating etc.
2. Assume there's something small that can be started now (or as soon as possible). With the focus on validating that the assumptions are correct. Maybe we can continue iterating from there or at least we are more confident (validated) that the capability will make a difference and can go to point 1 above.

I'm not saying some (most?) companies aren't doing this already. But this is my experience, and the customers/companies I've met don't have much of this mindset. Your experience may differ.

And I suggest that if you have validated that the basic idea or need or problem will "pay off" it might not matter that much if project is over-budget and/or late? It's never something good, I admit that, but we might not consider it a "fail"?

But then again, it feels good being able to "blame" the IT project (and probably the "supplier" - someone else!) for being the "failure" instead of trying to change your own behaviors, seeing your own responsibility..?

Estimates: Lies and Guesses?

Terry Bunio has already written a blog post on this Are #Estimates Lies? #NoEstimates. But I like to give my point of view on this topic as well.

To make a long story (blog post) short: "Estimates are not lies and guesses". There, you can stop reading here if you like :-)

Still here? I'm glad you would like to read more on my thoughts on this :-)

I hear that these statements are something that the #NoEstimates "community" claims to say or hold true. I haven't actually heard so much about it, but if it's true I would like (as a person thinking that the ideas behind #NoEstimates are good) to reject these statements - if so. But... there is a grain of "truth" in there... There is a reason why someone would call them "lies" or "guesses". Let me dwell on it.

Estimates are not lies or guesses - in the unicorn world! :-)

If you look at the pure definition of the word "estimate" (Merriam-Webster) you can see that it's not about guessing or lying. In the the definition you see words like "judge", "tentatively", "roughly", "approximate", "general".

But is this really the only usage of it, in the world of software development? Rhetoric. No.

And this is what #NoEstimates are trying to address. And this is where I think that #BetterEstimates and #NoEstimates share the same "interest". Maybe, in the end, we share the same solution to the problem: Communication! And in "communication" I put in words like "honesty", "transparency", "forthrightly" etc. Things that make communication meaningful and without "smell". Ok, maybe you should never be 100% honest etc? There might be situations. But you get it, nothing is ever 100% "true" or "false".

How does #NoEstimates fit?

In my opinion, I think it fits as a "topic" in this discussion about "dysfunctions" or "smell" associated with estimates. I see the hashtag as a "prefix" or an "abbreviation". I don't seem to get much throughput there, maybe I'm seeing things wrong? What do I know... But it's still my opinion, and I hold myself the right to change it later on, if someone points me at better :-)

But let me explain a bit.

Guesses

Sometimes I actually have no idea on how long time I think it's going to take when asked "How long..?" or "When..?". Usually it's because it's too vague or it feels too "big" to give a credible judgement - or anything else. 

The most honest thing is then to say that: "I have no idea" (or similar) (and when I do, we usually stop discussing estimates).  But when we're doing planning poker, or something else, it might not be easy to say that. Or when faced with some types of customers (you know which ones I'm talking about... :-) ). There's then a risk/chance that you do something that is more comparable with a "guess". Sometimes maybe the planning poker session is "forced" with: "We don't have time to discuss the details here, we must come up with a figure tomorrow" - i.e. "forced" to guess. 

Then I think #NoEstimates fits as #NoneOfThoseEstimates.

Sure, it's "bad management" or DDSTOP. But it fits the conversation, in my opinion. Like: "STOP!" or "NO!" (#No!Estimates?).

Lies

Sometimes, when I estimate, that estimation magically turns into a deadline. I.e. there is no "real" deadline (like market window, synchronization with other things etc), the estimate becomes the deadline. As in "We think we can pull this off in X sprints/iterations." and looking at the calendar that will occur at December 6. And the date is communicated up to the CEO (or whatever).

And in other times, estimates are "gamed". Like "Really that much!?" or "You have to cut that!". Usually in some "bidding" context. But I have actually heard customers say that directly faced with an estimate (and there are other reasons, than the estimates, why they say that).
And in other times, estimates are used because someone "above" needs a number to pass up the chain.
Etc...

In these scenarios you could actually call the estimates more like "lies" than "judgements".

Sure, again it's "bad management", "bad communication" or DDSTOP. But it fits the conversation. Again: #NoneOfThoseEstimates or #No!Estimates.

TL;DR

There are lots of other dysfunctions associated with estimates. All fits the #NoEstimates hashtag. Does it then mean: "Stop all estimations!"? Of course not.

And #NoEstimates also speaks of some "paradigm shift" on how both business and IT approaches software and how it is looked upon. But that's another topic :-)

But, #NoEstimates are centered round the fact that estimates are good if they are valid and used for the correct reason. No one thinks otherwise.

To fear #NoEstimates

There are two primary emotions. Some say. So do I :-). At least there are two emotions that all other emotions "derive" from. It's better that you read someone else's definition, and this one correlates well with my own definition. It is claimed to come from Elisabeth Kubler Ros (I haven't looked up the source, but it doesn't matter who has said what - I still like it):

"There are only two emotions: love and fear. All positive emotions come from love, all negative emotions from fear. From love flows happiness, contentment, peace, and joy. From fear comes anger, hate, anxiety and guilt. It's true that there are only two primary emotions, love and fear. But it's more accurate to say that there is only love or fear, for we cannot feel these two emotions together, at exactly the same time. They're opposites. If we're in fear, we are not in a place of love. When we're in a place of love, we cannot be in a place of fear."
Quote

So whenever you act, you act based on one of those two emotions. Fear or love.

When you're in the state of fear you attack. When you're in the state of love you embrace.

Behind fear is actually a call for help. Every person in fear is in some way asking for help. That thought can be helpful. That thought is comforting.

What does this have to do with #NoEstimates?
If you oppose #NoEstimates, ask yourself why you oppose it, based on those two emotions. You can actually ask yourself that question for anything, not just #NoEstimates. It's a really great exercise, but off topic in this post :-)

I have to admit that my #NoEstimates "journey" have been up and down. Initially I liked it, but then I started to dislike it (you can read all my previous blog post, if you want, to get a sense of that journey yourself). And now I'm back where I started :-)

So why did I oppose it ("back then")? Thus, why did I feel "fear"? This is basically what I thought:

Too broad definition

One of the reasons was that I started to see that estimates are a big part of what we do, every day. We estimate all the time, from big things to tiny little things. Heck, I even estimate when I write code (e.g. "How long will this piece of code take to complete, compared to if I write it like this instead?").
So, I started to oppose the whole #NoEstimates thing. I opposed it since it felt "silly". And feeling something is "silly" can easily be derived from the "fear" emotion. At least it's not an act out of "love".

Now I have chosen "love". In that emotion you don't see things as "silly". You instead ask yourself why you think it's "silly" (what do you fear)? Am I in a state of misunderstanding? Have I missed anything? Then I act on that emotion, instead of on my fear. I stop "attacking" and start "embracing".

Never estimate?

I also thought that it meant that you should aim at abolishing estimates, completely. This goes along with my previous point when it comes to the "fear" emotion.

When I choose "love" I see that I'm not seeing clearly, I'm missing something. Why do I act as seeing it as something "silly"? Does it really mean this?

Doesn't work for me

I also opposed it since I couldn't see how I could apply it in my own current profession. Maybe I still can't, but it's not the thing. I'm not going into details on what the "thing" is, it's not the topic. 

And no one really told me how I could apply it. Just "explore".

So, you could say I felt anger. And maybe jealousy? And I don't think I have to explain that anger and jealousy isn't derived from "love" at least? :-) When you're angry (or jealous) you easily "attack" (cause you're in a state of "fear").

When I choose "love" I can embrace that it works for others. Find inspiration and joy.

"Knowing cost..?"

How could you possibly tell someone the cost of something (if they want to know) without estimating? And isn't cost crucial when making decisions? Again, it's the "silly" thought. Or even the "Not doing this is really bad/stupid!" thought. That's attacking.

As I've already said, if I choose "love" I embrace that I haven't understood completely. You start asking embracing questions, not attacking ones.

"It's just bad management"

I felt that estimates are not the cause of the problem. And it isn't. I still believe that. The root cause is always people. Do I "fear" we're solving the wrong problem?

When I choose "love" I don't attack, instead I see that neither #BetterEstimates nor #NoEstimates will solve the "people problem". So either approach is ok, in that sense. Whatever might do the "people problem" at least better is worth trying. And #BetterEstimates have I already tried, and still are trying - so let's embrace another option. If I can. And embrace others who are trying.

Universal approach

Back then I was missing "actionables". I wanted to "do #NoEstimates". I thought it could be applied in any domain in any context anytime. And I was "frustrated" no one told me or showed me how to start. I was missing someone telling me when estimates where appropriate and when "no estimates" where appropriate.

Clearly a "cry" for help. An act when you're in "fear". You could also say I was feeling "frustrated" or maybe even "angry". Not feelings from "love".

But if I choose "love" I see that you shouldn't perhaps even seek #NoEstimates. It may be an outcome (from retrospectives). The only "seeking" you should do is trying to be inspired and realize "maybe I can't start, but what *can* I do?".

"But isn't it still a genuinely bad idea?"

This is more of a reflection I'm having now rather than something I believe I felt back then. So I'm going to see how you can approach this with "love".

Some developers/teams actually don't do estimates, and it's working for them. Why not be inspired instead? Encourage them, even if you can't possibly see how you could apply it. And if it turns out it actually *is* a genuinely "crappy" idea (even for those devs/teams), don't you think they would stop themselves (or be stopped)? Don't you think it actually won't be "universally" applied? But why don't you let someone else try, if they can and want to and it is for the better (for them)? As I said, be inspired instead. No one is forcing it on you. And if it turns out it actually is the universally-new-great-way-of-developing-software, don't you think it will be well tested in lots of domains and proven to be a better way first (like agile)? As I said, no one is forcing you to try or even telling you that you should try. Why not watch, listen, learn? Even if it "fails", it was worth trying it. There's a saying, I can't find it now (please help!) that goes something like this (out of my head): "It's better to take that step and fall than to be left standing on one foot the rest of your life".

And if you really think that trying to lessen the dependency on estimates in software development is a bad idea, why do you want to stop others from trying? What emotion is driving you? If they fail, even badly, they might still feel it was worth the try. You don't have to try. You even shouldn't. Maybe you fear (pun intended) it will drag a "bad name" around the whole software development "thing" - if others fail? I don't think you have to fear that. Really. If #NoEstimates is such a bad idea(?), I think I pretty much *know* what will be "blamed" as the cause for those "failures" (if so) ;-)

Conclusion

I think my feelings where: "that's silly!" or "frustration", "anger" and "jealousy". Those feelings are not based on "love".

So: let love drive you! :-)

"But aren't you allowed to criticize anything?"

Of course you are! I don't say - and no one is saying - that fear is something bad. Fear is as equally good as love - in the right situation. If you don't ever fear, you probably won't live a long life :-) 

And I claim that "criticism" can be derived out of either love or fear (as many other emotions).

But, just know (or try to see) what emotion is driving you in a specific situation. Are you acting out of love or out of fear? It might sometimes be hard to tell, but I think you know deep down. Are you attacking or embracing?

And even more important: is the person you are interacting with acting out of love or fear? If you look at another person, the one you're having "issues" with ("attacking" you), as someone who is "afraid", it might help you solve the situation better. Understanding the other person and why he/she acts the way he/she is acting right now. And remember, you can always *try* to let love drive you instead.

I don't propose a #NoFear hashtag. Even though you sometimes can choose love over fear, i.e. #NoFear (pun intended again) :-)

Estimates and promises

First, I'd like you to read this post by Joakim Holm about promises: "Promises, promises" Done? Fine, I hope you're now on track what a "good" promise is. In short (if you didn't read), if you *must* make a promise, then promise your own behavior. Only. If you start promise outcome you're taking a big risk. A risk of losing trust (among other things).

How does this correlate to estimates or "no estimates"? Well, in many cases estimates becomes just that: promises. It shouldn't, because is just an estimate, but can you avoid it? Have you ever given an estimate that didn't end up becoming a promise of outcome? Well, lucky you, if so :-)
Because when asked "How long do you think this will take?" simply honestly say what you think. It's as easy as that. It shouldn't be more complicated than that. It's an estimate, god dammit! (sorry about that rant...)
But, the problem arises if you give them a number (or a range, for that matter). Because it's very easy for that number/range to become: a promise. And more specific: a promise of outcome. And the problem becomes even larger if that number starts to travel up to the organization. It becomes a "promise chain", and you're, unfortunately, at the bottom. This is nothing strange really, it's human behavior.

So, what can you do? Easy. Don't give a number/range.

Wait a minute... Will that actually work in business?

No. I'm sorry that won't work. People need that number. So you have to give that number. And you will (one day or another) get in to trouble. It's as simple as that. Well, to be honest, if you get in to trouble it wasn't because of the estimate, something else is wrong or dysfunctional (and that's my version of #NoEstimates, as in: "It's never the estimates fault", but people don't seem to buy that :-)

So, to get around the problem you can try to pad that number and talk about margins, probabilistics and all kinds of stuff. But I'm sorry, it makes no difference. It will still be a promise of an outcome. And since you can't possibly *know* the outcome, it's always a risk.

Sure, if you're very very confident (like 99.99%, can you ever be 100%?) you will make that number, give that promise. But how often are you in a situation where you can be that confident for software you're going to write? If you think of it, you're always too optimistic and, at best, give maybe 50/50 chance. Read more here "My estimates are too optimistic" And if you would start to give higher confident estimates (to give a "promise of outcome" I'd say you need to go up to over 99.99%) your customer will probably say "That's way too much money". And then all you did was to help them abandon the project. Or you resort to promise an outcome with lower confidence = RISKY!

And I would even claim that if you (with customer) don't come up with other ways of solving the problem or that you (with customer) learn something - along the way, as you *do* stuff - that will make the solution even better than what you initially thought, it's probably a failed solution. At least it's a mediocre solution if that happens. So, the only thing you *know* is that things will change - if you (with customer) wants to build better. This is basically why most companies abandon waterfall and go for agile; you can't know in advance what you want, so it's better to iteratively work the requirements as you go. But how can you ever promise an outcome if you *know* it will change? Easy, you can't promise that.

What to do?

I'm sorry, there's probably nothing you can do. Give numbers and get in trouble :-)

Actually there are ways of working that minimizes or even eliminates the need for someone to ask for numbers. But that is out of scope of this article.

Still...

If it's possible there's something you *can* do. I'm not saying it is possible in your scenario/situation, it's up to you to decide.
But you can decide how you want to lead your life. It's up to you. If you give promises of outcome it may affect you or others negatively. Working long hard hours, neglecting family and friends to meet that promise you gave. It creates pressure and stress that will lessen quality of what you build and will increase the technical debt. And more. All in all, promises are powerful stuff. It affects you heavily. But you can choose how to live.
You can choose to say no. If it makes your life better. It's up to you. And good people will probably appreciate someone who says no.
What do I mean by saying "no" in this case?
If you are going to estimate cost/time. Require that the person asking gives *you* an estimate first. An estimate of benefit or a budget and when it has to be done. You can call it "real constraints". And then all you (together) have to do is to see if what you think (yes, an estimate) is close to what they think (yes, an estimate). If it is close, then there's a risk. Simply discuss this risk then. Solve it together. Probably you (as in: you and your customer) will end up cutting scope to a point where you feel comfortable you *can* promise an outcome (that 99.99%). And if everything works smoothly (how often does that happen?) there might be time left to add small improvements one by one (this is close to the approach I talked about earlier, on how to not getting a request to give a promise of outcome at all). Hence, this scope cutting can result in a half MVP (Minimum Viable Product): a PYNPO (Product You're Not Proud Of), or even a half PYNPO: the PYMTGO (Product You Managed To Get Out). :-) Then work from there.
Or maybe not. Maybe you are comfortable to say something like: "I see no problem to get this done for that price and/or that time." Sure, that's a promise. But if you know you *will* make it (fulfill promise of outcome), unless you get run over by a truck or get your hands cut of: make that promise! But how often are you that certain of your promises of outcome in software development? Given you cannot know in advance what you will learn and improve and adapt to as you go along.
Or you (as in customer in this case) can agree to "live with the risk". Simply "Let's do our best. If it succeeds, it does. At least we have tried and has gotten something." I've actually worked like that in many cases, when something started a bit (or way?) too late and cutting scope is not applicable. If you're honest, customer is usually fine with that, they know they started late and can't require you to do miracles just because of that.

Bottom line, avoid signing contracts that acts as promises of outcome. It can be done. And remember "Customer collaboration over contract negotiation" is being agile.

I've also written another blog post on almost the same topic: "What #NoEstimates has taught me"

Risk sharing

I've mentioned risks. And in this case it's about "risk sharing". You both take a risk when getting into a project with only "I think this can be done within this time/budget, but I can't promise it". If you think of it, risk sharing (in itself) is actually fine. Because it is a promise of behavior: "I promise to ___ if ___ happens". That is all fine. It's an easy promise to keep, if you know you will do ___ if ___ happens, that is :-)

So, how do you come up the figures of what ___ is? That is up to you. But do you have to put up figures there..? Think about it.

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.

Response to "People Need Estimates"

This is a response to Neil Killick's great post http://neilkillick.com/2013/04/18/people-need-estimates/

The essence of that post is this:

"With #NoEstimates you set the price and/or date, either through experience and choice (for e.g. setting price/date for the kind of work you do regularly, with a fixed team and cost) or through a real budgetary or time constraint (e.g. “I’ve only got $100k, what can we build for that?” or “The Australian Open starts in 3 months so the Aus Open app needs to be ready to go live the day before”.)"

OK, but why? I think this is it (from same post):

"When estimating a date or cost you are creating uncertainty around those things, because you are guessing. You are saying “we’ll deliver somewhere between here and here”. However, if your delivery date and/or cost is set by a real constraint, as advocated by the #NoEstimates approach, you have created certainty around those things."

But I don't really see why this is called "no estimates"? It's more like #EstimateScope. And I believe that it's associated with equal amount of problems as doing "regular" estimating.

I'd like to state one thing and then create a little scenario.

My statement

Working with real budgetary or constraints is really good. We do that in our business from time to time. But there are problems associated with it (I'll get to it soon) and very often business don't have a budget constraint, they have an idea or a problem they want to materialize or solve. They want to know how much to budget for that. Sometimes (quite often actually) customer have no real monetary benefit of solving this problem or idea (or it's very hard to calculate it). Then they still need to know the cost (roughly) so the board can prioritize among other things to do in the organization. "Shall we do this thing this year, or is it better to wait and try to see if we have more money next year, or shall we try to save money to next year to do this?". I see nothing wrong in this kind of discussions. And I can't "blame" my customers for not having a real monetary benefit of everything they do (even if they perhaps should, or should they really?).

Of course they have a sense already of the cost for things, and this is usually not communicated. I believe this is a "dysfunction" and that this sense should be communicated. Then we (as suppliers) will be more motivated what goals we're working at and knows the constraints behind this project. All great. But it doesn't really solve anything in the end (I'll get to this in my scenario later).

When it comes to "setting price/date for the kind of work you do regularly" I don't quite get this. I sense we're talking about portfolios or something similar? But isn't that super boring? The whole purpose of why I'm a software developer is to be able to solve problems or materialize ideas. I don't want to do "regular work". The beauty lies in creating great stuff and solve customers ideas/problems with solutions I haven't really built before. And if "work you do regularly" is about using the same frameworks, platforms and languages then this is how we set price already i.e. we estimate how much of this "regular work" is required.

A scenario

Lets create a little "play". Starring Me (M), Customer (C) and my CEO (O).

C: I have this idea!
M: Great! Let's look at it.
(Going through the idea in workshop like forms or similar)
C: So, do you think you can do this?
M: Yes, it seems like a great idea. And I can do it.
C: How much do you think it will cost?
M: Well, may I first ask what this is worth, what is your budget or can we create a budget?
C: Yes, I estimate we will have a profit from this at $100.000 per year for about five years time. So the benefit for us is roughly $500.000. But we need to have at least a break even in first year, so I'd like it to cost no more than $100.000. But we may decide do it anyway depending on what you come up with (estimate).
M: So the budget is $100.000?
C: Yes, but not necessarily. If you think it's more we may still decide to do it. But that depends, I can't tell right now, I will need to discuss that with the management team. If so.
M: Great! Thanks. I'll get back to you. Cheers!

(Me going to my CEO (O))

O: So, how did the meeting go?
M: Great! They want to build this thing and have a budget of $100.000 roughly.
O: Superb! Then we need to check if we can build it for that amount. Because if our cost for building it is close to that budget it's a great risk for both us and our customer.

Play over.

Whatever we do we still end up with estimates. We need to know with some degree of certainty (or margins) that our cost for building a thing isn't close to the budget our customer have. Otherwise we might soon be out of business.

And if we think we can build it for $20.000 or maybe $50.000. How do we know that without calling it an estimate? We haven't built this thing before. And *not* estimating and just return to the customer with the response: "Yes, we can build it for $100.000", is that professional? Customer will certainly ask: "But how much is it?" And they should be told what we think. Because it will make their decisions easier. If it's $20.000 we surely have a quick "Go!". And if it's close to $100.000 they might have to do some more thinking before we get a *quick* "Go!" (i.e. we slow down their process by not answering what we think - by estimating).

So, in this scenario #NoEstimates would actually be worse. It could even get us out of business; if we deliver stuff that costs us more than our customers pay us (budgets).

(This scenario is actually the business I'm in, this is what we do).

And what happens if we don't estimate and say: "Let's adjust scope so we can build *something* for that money (budget)"? Well, customer might end up with something they can't really use. What's the value in that? The common answer to this problem is: "We always work on and deliver the most valuable things first, thus they always have something they can use". I don't believe that. In my business (solving ideas and problems) the customer have a vision of what "done" is, and the idea ("done") usually doesn't deviate much when building it. The *details* of what will be built might deviate, but not the initial idea/problem. And not delivering that idea completely ("done"), but merely having "increments" of the idea ("done"), equates to unusable. That's my experience. E.g. how does increments of a "booking system" look like? "We can book, but have no UI"? "We can book, but have a crappy UI that no one wants to use"? "We can book with a beautiful UI but can't view the bookings made"? 

Of course, "done" doesn't mean we should build all little nifty details of everything in the first release. Plain agile thinking. Think of it as an MVP (Minimal Viable Product). But this MVP must be estimated. After that we can plan what will be included in next release (continuous improvements). But there is another thing that strikes me: knowing "size" of a feature is valuable for customer. There might be two (or more) "equal valuable features" and then an estimate of size will help decide which one of them we should include in the next release (prioritization). And even if features don't have equal value, customer might want to include those small sized features (estimated as such) anyway. It's their money, let them do that if they want to.

"Need for estimates"

No one "needs" estimates per se. Estimates without real need is nothing worth. But estimating is the tool we use for deciding things: *to choose between future paths*. We have had a need for that since mankind and we still need it in almost everything we do in our everyday life and business.
And no one really says "we need estimates". At least I've never heard it. And if someone do say that they're a victim of poor management (the basis of the decisions are not communicated). What can you do about that? That's the real question you should solve.

So, is this #NoEstimates tag just a misinterpretation? Is it equal to "Plans are nothing; planning is everything"?

"Estimates are nothing (NoEstimates); estimation is everything" #NoEstimates #YesEstimation

Answers to Woody's questions

Woody Zuill is suggesting that we should ask ourselves - and answer ourselves - a couple of questions regarding estimates. The questions are available here: http://zuill.us/WoodyZuill/2013/04/25/agile2013-lightning-talk-noestimates/

I probably have misinterpreted how the questions should be used, but here it goes anyway.

Here are my answers:

• What are estimates, anyways?

"a: to judge tentatively or approximately the value, worth, or significance of
b: to determine roughly the size, extent, or nature of
c: to produce a statement of the approximate cost of"

Source: http://www.merriam-webster.com/dictionary/estimates
In software, it's usually perceived as the act of guessing how "big" something is. Usually disconnected from the business needs (those buying the code we write), but I'll get there.

• Are estimates useless? wasteful? harmful?

They might be perceived as those things. Usually because they are disconnected from the business needs (those buying the software). We need to collaborate and communicate better. If you produce estimates down a "promise chain", and you're at the bottom, of course that's what you'll feel. But does that make estimates wasteful and harmful? No. The use of them might be. But can be avoided with better communication and collaboration (internal and external).

If they are percieved as the things above (i.e. as a "weapon" and not a tool), you are probably a victim of "dysfunctional management". Don't "blame" estimates for that. And, starting with (or even trying) "no estimates" will certainly not stop this "dysfunctional management". It might even make it worse.

A "thing" cannot be harmful, only human behavior.

• Who needs them? Who is asking for them?

In the end, or directly, those who is going to pay for the code you write. They want to know, roughly, how much and when to expect what they pay for. Usually that is missed down the chain.

• Why do we think we need them?

Who are "we"? Developers? We don't really need them. But they might be a great additional tool when e.g. discussing the complexity of something, read more here: http://eirabrunstad.blogspot.com/2014/01/no-estimates-hype-or-not.html

I like to have more options, not less, so removing estimates ("no estimates") as a tool seems unpragmatic, in my opinion.

• Can we have successful projects without estimates?

Not sure. Depends on domain and context. And what is "successful"? To me it's about delivering something my customers are happy with and hopefully provides expected value to them. But if we deliver late and over budget, they are of course not going to be happy. But customer must feel that the "cost" put in to it is less than the value it provides. Both must be estimated beforehand, otherwise business (those buying our software) can't evaluate if it's worth starting the project at all.

• When will this be done? How much will it cost?

Estimate it. Those buying the software wants to know. Of course they want to know. It's their right to know, it's their money.

If you can give a sense of cost and time without estimates, please let me know.

I've often heard: "Fix budget. Define cost and let scope flex." But if I was a buyer of software, that's not how I would prefer it. Not always at least. And how will that solve any problems? How do we avoid customer adding lots of scope? The cost is defined - let's add! Or, how do customer knows what they have in mind will be done in time and available for the cost defined?

The "problem" will just be pushed to another place, "same sh*t, different name".

• How can we decide if we should do a project without knowing the cost?

Flip coins? :-) Jokes aside, there might be occasions for this, but they are probably rare. I don't even know any.

I wouldn't want to do anything without knowing the cost of it. I'm a DIY. I always "require" estimates from myself. Why? To know the cost and value for different solutions. Why? To determine which way to go. I.e. which project to start now, and how to do it.

I don't think software is any different. I write code as well, and writing code is just as uncertain as remodeling my old house :-) But a rough sense of cost and "benefit" I certainly want before tearing down a wall. To not mention my wife :-)

I don't think my customers reasons any different.

• Is NoEstimates better than MoEstimates?

Less is more :-) Not having any estimates at all (no estimates) seems worse than swimming in them. At least as a buyer. But if I (as a buyer) is going to pay for the estimates, I'd like to have "enough". Enough so you, as a provider, feels comfortable with them. Up to a level where I will not be certain you know what you are doing at all :-)

• How expensive are useful estimates?

Very context depending. In my domain, they are not very expensive. We could (and should) improve how we deliver them and communicate them and collaborate them. But expensive? Not very, in my opinion.

• How useful are inexpensive estimates?

Ours are pretty inexpensive, and useful for our customers. Useful enough so they can decide.

Consider "blink estimates": http://dannorth.net/2013/08/08/blink-estimation/

"Gut feeling" (instant) estimates are actually very useful.

• If it takes you “no time” to do estimates, are they of any value?

"No time" I interpret as "blink", thus see previous answer. They are valuable. Wouldn't write a contract based on them, but valuable? Yes.
Some say "gut feeling" or intuitive estimates are not estimates in that sense. I might agree on that, at least I know what they mean. But, even if we do "implicit" estimates, why not make them explicit? What's wrong with that?

• If estimates are waste, would you still do them?

No. Of course not. But are they? Really?

• Is the reason you do estimates because “someone requires I do estimates”?

No. Customers wants to know what they are expected to pay and when to expect it to be finished.

I can still see how some organizations fail to communicate the need for them. But fix that. Don't start (or try) "no estimates" first of all. Communication and collaboration will get you to a point where you see the real need and use of estimates, why we provide them and what they are used for by those really wanting them.

• Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?

No. But I can see how this can be in some organizations. But I've covered this. You won't fix "dysfunctional communication and collaboration" by starting with (or trying) "no estimates". Fix the other things first.

• When someone asks for an estimate, what do you do?

I make sure they are connected to real need (time and/or money or prioritization of items based on effort vs value). In my domain they usually are. 

A good approach would be to ask what the estimates are going to be used for and who is the real receiver of them.

• When estimates don’t work well for us, should we just get “better at doing estimates”?

No. Do a root cause analysis of why estimates isn't working for you. I bet you will see the root cause as "bad communication (internal and external) and collaboration (internal and external)". 

• If estimates are useful and easy to do, why do we still have so many problems with estimates?

They are not easy to do. Is programming easy? If we are skilled enough to write software, we should be skilled enough to estimate the effort to write it as well.

Why do we have problems with them? Again: "bad communication and collaboration".

• How would you plan a project if you were NOT allowed to do estimates?

The same way as I do today. Define what "done" looks like (in collaboration with customer). And in which order things needs to be done, and prioritize valuable and/or "risky" tasks first. And discuss project risks overall

If you ask how to schedule a project and connect resources without estimates, I have no idea.

• Can you imagine any reason why estimates might be harmful?

No. Only the use of them. A "thing" cannot be harmful, only behavior can be. Considering doing away with estimates (no estimates) won't fix the reasons for harmful behaviors.
Remember the "statement": "Guns don't kill people, people kill people". That statement is actually true, but contains a big error. See it? Well, guns are designed to kill. There is no real usage of guns except killing (well there are some sports made up around gun shooting, but that's basically playing: "who's the best at killing most efficiently"). That's not the thing with estimates. Estimates aren't designed to be harmful. They have been around since mankind (heck, even animals estimate). But are they harmful by nature? No.

• Can you imagine some better way?

No. There might be alternative ways. But better? Don't think so.

• How important are predictions?

Very.

• Can you “sell” programming without estimates?

No, not in my domain at least. More important question: is buyer willing to pay for programming without having a sense of how much? It's not the "seller" who gets to dictate the rules. It's not his/hers money. "Customer is always right".

If we can "sell" programming without making estimates I would be happy to know how that can be done.

• What about estimating the “value” of a feature?

Yes, that needs to be done as well. Business (or "buyers") do that already (hopefully). Anyway, it's not your money. But let's try to keep communication and collaboration open. That goes for everyone.

• Are there things where estimates make sense?

Yes. Lots. I've written about some already: http://kodkreator.blogspot.se/2014/04/useful-estimates.html

• What is “No Estimates” anyway?

Exactly, good question. I don't really know. Usually it's interpreted as "refuse to estimate" and/or "estimates are always waste". But I think it's not. Don't really know how to approach it though...

• If estimates are good for some things, does that mean they are good for everything?

No, of course not. But estimates are very often present in everything we do in life. "How much shall I eat? When? Will I make it to the meeting in time? Can I afford this? Is it worth it? Can I cross the street before that car gets here? Will this thing fit here? Will this code be more readable than that? Will it be more maintainable? Will it have good enough performance?" etc etc. 

We haven't found a better way to "create letters on some media" to communicate and/or document some text. Should we seek ways to stop that and try better ways? Maybe, not sure it's sane though. I believe estimates are the same. We have even been doing estimates longer than we've been creating letters on some media. Why should they go away now?

• Does “No Estimates” mean we don’t use estimates at all?

No. But where do we use it and where should we not use it? How should I, as a developer, approach it?

• What are “Whole Team Estimates” and does it help at all?

The team sits and estimate together. Collaboration is great. So yes, it helps. Better up would be "Customer collaboration estimates", i.e. estimate in collaboration with customer. Not sure how that can be done though.

• If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?

No. If you don't understand enough, collaborate with customer: "How do we progress?" Everything will be great if we start communicate and collaborate.

The team/developer building the thing should get a chance to estimate it again. Or the team/developer estimating should be the one(s) building it. Important "rule". Poor management if that doesn't happen.

• How much are you willing to invest in estimates to get useful information from them?

That depends. Talk to customer. Collaborate and communicate. It's their money. "Spikes" and "Proof of Concepts" are some tools to gain knowledge for better understanding or build prototypes or mockups. But those needs to be estimated as well, "How much should we budget for a PoC?". But that's approaches to be able to produce more accurate estimates.

• Does it matter how good estimates are: are “wild guesses” good enough?

Why make "wild guess"? If uncertain, talk to costumer. Collaborate.

• Are the decisions you are making that are based on estimates good decisions?

Yes. Depends on how the estimates are delivered, under which circumstances and by whom.

Response to "Can we put an end to this ‘Estimate’ game of fools?"

This is a response to the blog post: http://blog.frankel.ch/can-we-put-an-end-to-this-estimate-game-of-fools
I think writing a blog myself is the best way to share my alternate opinion on the matter. (The original blog post is quoted in this post for easier reading).

When I was a young software programmer, I had to develop features with estimates given by more senior programmers. If more time was required for the task, I had to explain the reasons – and I’d better be convincing about that. After some years, I became the one who had to provide feature estimates, but this did no mean it was easier: if the development team took more time to develop, I had to justify it to my management. Now, after even more years, I have to provide estimates for entire projects, not just fine-grained features.

This is a management dysfunction. The ones estimating must be the ones developing the thing estimated. Or add margins in the estimates for "junior" (or inexperienced, we all are from time to time) developers. Never blame developers for "wrong" estimates. It's how poor managers use them. That's what's wrong, not the estimates.

But in essence, what do we need estimates for? For big enough companies, those are required by internal processes. Whatever the process, it goes somewhat along these lines: in order to start a project, one needs estimate in order to request a budget, then approved (or not) by management.

We need them for making business decisions. I'll come to this later. But, just as you say: business needs to budget investments (projects) and prioritize them with other (even non software) projects.

Guess what? It doesn't work, it never did and I’m pretty sure it never will.

Why does some companies do this well then? Maybe look at how they are doing it?
The business needs budgets. If you've ever been a member of the board at any organization or cooperative, you know the importance if this. Very often the board needs to know what to budget for something that needs to be invested, and how can they do that without asking us for estimates? Even if they know the value of an investment they need to know the cost as well, it's called ROI (Return Of Investment).
One thing we usually miss is to add margins when needed (for uncertain items). Read this post: http://www.leadingagile.com/2014/02/use-agile-build-next-home/
I always add margins when I invite guests for dinner or when I go traveling or remodel my house. Do the same with software development.

Maybe we can keep price fixed and estimate the scope. Not as good in my opinion. Why not build the best thing? Maybe your customers are happy adding budget (or use margins) for some things (added scope). It's all about customer collaboration. Tell them where they should add margins/buffers.
If estimates are still "wrong", in the end? Well, "execute your risk plan" for this (which you discussed with the customer/stakeholders before project started: "What if the estimates are wrong?"). Don't have any "risk plan", fix one next time, but for now remember: Customer collaboration.

Note: some organizations are smart enough to realize this and couple estimates with a confidence factor. Too bad this factor has no place in an Excel sheets and that it is lost at some point during data aggregation

Exactly. But, why do you think it has no place in the excel? And why is it lost? Fix.

Unfortunately, my experience is the following: estimates are nearly always undervalued! Most of the time, this has the following consequences, (that might not be exclusive):

Yes, stop lying to yourself. Optimism is a disease when estimating.

In general, the first option is to cancel all planned vacations of team members. The second step is to make members work longer hours, soon followed by cutting on week-ends so they work 6/7. While effective in the very short-term, it brings down the team productivity very soon afterwards. People need rest and spirit – and developers are people too!After pressure on the development team, it’s time to negotiate. In this phase, project management goes to the customer and try to strike a deal to remove parts of the project scope (if it was ever defined…). However, even if the scope is reduced, it generally is not enough to finish on budget and on time.The final and last step is the most painful: go back to the powers that be, and ask for more budget. It is painful for the management, because it’s acknowledging failure. At this point, forget the initial schedule.Meanwhile and afterwards, management will communicate everything is fine and goes according to the plan. Human nature…

 Management dysfunctions. Tell how you feel. Don't accept working overtime because someone is using estimates as promises. Fix the dysfunctions. Customer collaboration. Quit, at worst.

In some cases (e.g. a bid), that’s even worse, as the project manager will frequently (always?) complain that those estimates are too high and pressuring you to get lower ones, despite the fact that lowering estimates never lowers workload.

Same thing as my previous response. What's the purpose of using estimates as pressure? They are used for making decisions and understanding. Don't be optimistic. Don't accept pressuring. Ask what the estimates are going to be used for. Seems like they are used for something else here. If things don't get better, quit at worst.

You could question why estimates are always wrong. Well, this is not the point of this post but my favorite answer is that Civil Engineering is around 5,000 years old and civil engineers also rarely get their estimates right. Our profession is barely 50 years old and technology and methodologies keep changing all the time.

Estimates are never right. It's in the nature of estimates. It's *estimates*. But my estimates are almost always close, at least close enough. And if things change so much that the initial estimate is off, tell customers or stakeholders. Remember *Customer collaboration*.

I’m not a methodologist, not a Project Manager, not a Scrum Master… only a Software Architect. I don’t know if Agile will save the world; however, I witnessed first-hand every upfront estimate attempt as a failure. I can only play this game of fools for so long, because we’re all doomed to loose by participating in it.

Don't play games. Be professional. That goes for everyone in the organization.

Useful estimates

When someone asks me to produce some kind of documentation, I always respond with asking back "What is it for, and who will use it and for what purpose? Documentation quickly becomes outdated and needs continuous updating. We need to know all this before providing it."

We should respond the same thing when asked for estimates (just replace "documentation" with "estimates" and you're good to go).

Unfortunately I think the #NoEstimates "movement" tends to "drag down estimates in the dirt". I feel I need to lend it my hand...

We need to recognize that estimates have a lot of value. Sometimes it's actually not even a good option to try do away with them.

Here are some:

NB! When I say "you" below, I mean "the team" including product owner (of course) in collaboration with "customer" (or whoever is paying for the software you produce).

Prio

When there are items in the "backlog" (or other "idea list" you have) that have roughly the same value (actual or perceived), estimates provides great knowledge. Maybe you want to pick the "easiest" items or maybe you want to do the opposite and tackle the "hardest" items. I'm not talking about risk or value here, they are roughly the same (but still, estimates may provide great knowledge even for those).

Worth doing

Sometimes some items or projects doesn't have a clear "payback". They actually exists. Or maybe the "payback" is quite difficult to measure. But it's still an item or project the business wants to do (anyway, it's not your money). Then an estimate provides great knowledge to decide if it's worth doing. If it's too "expensive", maybe it's not worth doing it at all, not even a small increment/PoC/MVP/walking skeleton or anything.

Or maybe it is? Then we still need to define how much to spend on it and estimate if we can produce anything useful or gain enough knowledge for it.

If we can't measure the "payback", how can we know it's "too expensive"? I don't think it matters, it might just be a gut feeling or a wild guess (just like our estimates..?). But remember, it's not your money.

Worth doing #2

This is the most obvious, in my opinion. This is when you "know" what the investment is worth. You know what the goal is and how to measure the "success".

Maybe you want to start building on the most valuable or "risky" part first. Or build a MVP (Minimal Viable Product) or any other incremental approach. Or maybe you must have it all (that actually happens).

But, whenever you want to spend your money on something, you want to have a sense of how much (and sometimes when to expect it). I think you have the right to get that sense.

As a customer (the one buying your software), maybe I can define the cost upfront? Sure. But it's quite often not how I want to spend my money. "I want it all and I want it know!" :-) Seriously, I usually know what I'm after, I just want to know how much that is.

I might already have a sense of how much it is. Let's then see if we share that view. But maybe I haven't got a clue? I must then have the right to know if it's worth doing.

Anyway, I have a right to know how much this thing is, that I want. Even if I probably (in the end) don't want exactly that thing I thought I wanted. But please, tell me anyway. Tell me that it might be more expensive, or cheaper. Tell me I probably don't want what I think. Tell me what risks you see and other "unknowns" that might be expensive. Tell me how you want to solve that. Where should I put margins.

But let me know how much I should "budget". Let's solve it together.

Whenever I invite people for dinner I have margins. I over-estimate. I want to know it's enough for everyone. Even if it was "waste" in the end. I can eat "the waste" myself later. If my budget is low, I probably cut down on the number of guests, or buy something cheaper to eat. But let's all be honest with this. Be transparent. And my local supermarket will gladly help me with this. They will surely ask how many guests I've invited and what "quality level" I'm aiming for. But they will surely estimate the amount of food I should buy, and I will say I want to have margins.

Can we do the same?

Shared understanding

Sometimes estimates are great to determine if you have the same sense of the "complexity". Or if you share the same view of "done" and how to get there.

This is true both inside and outside the team. Maybe your customer have a budget already, or they might have a sense of the cost already. Let's see if we share it or if it's doable?

If your customer have no budget or no clue at all, estimates provide little or no value when it comes to "shared understanding". Just saying.

Are there other cases where estimates provides great value? Please let me know, and I'll happily consider updating this list.

For the #NoEstimates discussion to be viable we need to consider when estimates actually are valuable.

What #NoEstimates has taught me

This is a story from a real life scenario. It's about how estimates was turned against me and how #NoEstimates has taught me to act next time. At least, try to act. I.e. explore :-)

The scenario

I was hired as a "resource" (consultant) at one of our customers. Once we had a meeting. They wanted to discuss a new (a larger) change on an existing application. I.e a new feature. I was the one who was going to build it. After discussing their new great idea, the inevitable question came: "Can you look at this and get back with an estimate on the size of this?".

You all know this story, but here it is anyway:

I knew this customer, I had worked with them for quite a long time. I knew they actually said "Give us a promise!". I knew they would complain that my estimate would be "to expensive" and I should look at trying to cut it.

But at the time I didn't think this was something strange, "It's how it is, it's how it's done".

Thus, I got back with an estimate (I actually kind of already "knew" the size, or what I was going to answer, when we discussed the idea). Knowing they would use it as a promise I first got an approval of my estimate from my manager. I presented my estimate to the customer and was very, very clear (did I say very clear?) that it was an *estimate*. They where actually all great with that and didn't even asked if I could cut it. Happy days!

Not. The estimate became a promise anyway. And the estimate turned out to be "wrong". Things took longer than expected (has that ever happened to you? :-) And my estimate was held against me.

As I said, you all know the story.

What I'm going to try next time

I don't work with this customer anymore (for other reasons than my estimates I should point out. It was actually a great customer, even though I don't describe it as one). So, I'm not sure I will be ably to try this approach, but I might try it in another form on other customers.

I should have played with opened cards. Knowing they wanted promises and not merely estimates. This is what I should have said (or at least this is how I feel, now, I should have said):

"I think you want a promise, a commitment, and not an estimate. Is this true?" They would probably not admit this and answer something like "No, we want an estimate to know what this will cost us and when to expect it." I should then try to respond "If it is an estimate you want, I think we should book another meeting and look at the size of this work together. We will then, all, have a shared understanding and a better sense of cost and time." They would probably say "That is not necessary, you are the expert, we believe in your expertise.", me: "Then I believe you do want a promise and not merely an estimate. I then would like to discuss what we should do if my estimate turns out to be wrong, before I provide one." Maybe I would add: "I have a sense of the size of this work already if you'd like to hear? And I believe you already have a budget for this, explicit or implicit, but let's all try to be explicit; may I ask what you had in mind and see if we share that view?"

You have to know that this was actually a very decent customer (even though it might not look like it). Perhaps a customer with some dysfunctions (who hasn't got any?) Thus, I think they would get this. How the discussion would've turned out after this I can't grasp right now. But it's a start. I'll try and evaluate and learn, and try new things again.

Any ideas? Please, leave comment with your thoughts and experiences.

The NoMeetings Hashtag

This article was removed.
It could easily be interpreted as "mocking" or a "parody" of another hashtag. And it also could be read as a bit "aggressive".
This was not my intention, sorry.

Respons to "Estimation Isn’t Agile" article

This is a response to a blog post written by Craig Buchek: http://blog.boochtek.com/2014/03/23/agile-estimation
I claimed, on twitter, that I had this opinion once as well, but have "changed my mind". He then asked me to write a blog post about my thoughts on it. It's a great idea. So, here it is.
I'm going to quote his blog in here, for easier reading.

I don’t believe that estimation should be part of any Agile practice.

Estimates is a powerful tool. Like any powerful tool, you must learn to use it first.
If you can be agile with or without estimates is an opinion, I don't question that :-)

One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).

The text makes me think that the estimates was delivered as "single point numbers"? Estimates should come with a range and probability. There are lots of ways to do this.
Secondly, I think it's time to talk to this manager. She needs to learn how to use estimates as well. It's not only developers that needs to improve. Solve the root cause first, don't "blame" estimation. Her behavior will not get better if you (or anyone) stop doing estimates.

But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.

The reason estimates are treated as commitments or promises is because how we use them and present and communicate them. If they become contracts is up to you.
E.g. if a bunch of developers take half a day (or a couple of hours or maybe days) to come up with a, probably "accurate", number, no wonder the estimates are treated as commitments. Who wouldn't? They don't know how you came up with that number. They think you are professionals!
Instead, deliver a range with probability. Some say this doesn't work. I disagree. It's not uncommon to hear the doctor say: "It's a 70% chance this operation goes well". You can handle that, everyone can handle that. And then you trigger another discussion, an important one: "What's the 30% risk?"
And, some kind of "promise" must be made. The ones paying us to write their software should be able to know, in advance, roughly how much they're expected to pay and when to get it. Why should we not answer that?

Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.

Yes, agile is about seeking improvement. And doing things better. Improve how you use estimates. Improve how you use your tools. That goes for any tool in your toolbox. As I said, estimates is a powerful tool. Learn to use it. Improve, yes.

Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.

This is a red herring. No project should be on time and budget. Then you're doing it wrong. If you hit time/budget, then you A) Was very, very lucky or B) Adjusted things to hit the time and budget. I'd rather have something great a bit late and more expensive than something bad on time and budget. That is, if budget and/or time isn't crucial. But then, I'd have no problem cutting scope.
This goes for everyone. Put on your customers glasses - they'd probably have no problem if you signal, in time, that the estimate seems to be wrong. It should actually have been a part of the risk discussion before project was started. But still, adjust estimates when you know better. Remember: customer collaboration.

Improved Estimation

To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.

Yes, plans change. Estimates change. Embrace change. Don't lock estimates, keep the conversation going. If you must lock them? Get good lawyers :-)

When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.

I agree. Story points are "lousy" when talking to the ones paying you money to write their software. But this is only my opinion. Some use story points, and they work great. Good for them.

Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.

Don't be optimistic when delivering estimates. This is a common mistake. Why not deliver your "worst" estimate? Who will be sad if you deliver faster? Probably the opposite - they'll be glad! Until they've eventually seen through your "scam" :-) And if your'e trying to "win" a project, or if customer wants to decide if a project is "worth doing" then you should *not* provide your "worst" estimate.
So, start by trying to deliver your estimates with ranges and probability.

What Can We Do Instead?

Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?

I don't think so. If we can, great! Please, let me know! :-)
If managers use estimates to create "predictability", they should improve. Nothing will fix "stupid". Other than stop doing stupid things. Stop estimating will certainly not fix that.

I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.

Agree, but this doesn't exclude estimates. You can do this anyway. But, how do the ones paying us to write their software know (roughly) when the thing you're building for them is "shippable"?

What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.

Agree. Nothing to do with estimates though.

Arguments 

1. Why can’t you just tell us how long it will really take?

Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.

No, you don't *know*. That's why we're *estimating*. If someone takes your estimates for "knowing", rethink how you deliver those estimates. Again, you can't refuse the ones paying us for writing their software the right to get a sense of how much and when.

2. But we have to tell our customers what to expect.

Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.

No, they don't need exact dates. Why do you think they do? Instead, stop delivering exact dates. But they do want to know roughly how much and when. And, estimates comes with a probability.
And everyone should/must have a common understanding on what "done" looks like. No chance of success otherwise.

3. But we have to have messaging about new features.

OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.

I don't understand this point.

4. But we’ve promised these new features to the customers by this date.

Ah, so you’ve made promised to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.

Put on your customers glasses. If someone has promised to deliver something to you and they don't, what would you do?
And, you are actually at it. Don't be optimistic when delivering estimates. Common mistake. Also think about how you deliver your estimate, they should not be interpreted as promises.

Risk

Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.

This is a bit of a confusing point. Yes, estimates are risk. Talk about it with the ones paying us to write their software *before* the risk becomes a problem. Customer collaboration. The risk was *not* to ask for estimates. And don't put trust in them. But that depends on how you deliver them, how you communicate them - customer collaboration.
By the way, who asks for estimates? I've never heard: "We want to buy some estimates!" What they want to know, roughly, is the cost and time. How you provide it is up to you. If you can do it without estimating, good for you! But you can't "blame" the ones paying you to know roughly, in advance, how much and when to expect it. Usually/always you must estimate that.

Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.

Agree. Nothing to do with estimates/no estimates though.
Usually, in all other situations you handle "unknowns"and uncertainties by having margins or "buffers". If you want to buy a TV, you have a "roof" price, but you might still adjust it depending on what you find :-) And if you go on a trip, don't you bring "a little extra", just in case? And if you remodel you kitchen, don't you have margins for certain "unknown" costs that might occur? Well, you should at least. And wouldn't you want to have someone, an expert, to point out these "uncertainties"?
Same thing with software. Talk to the ones giving you money to write their software. Let them know your "unknowns" and your uncertainties. Maybe they want to create "buffers" or margins as well. It's called risk handling. And let them decide later if to use them or not - in collaboration with you.