Dear Peter, Glen, Trevor…and friends,
As some of you might already know, I’ve been hanging around in the #NoEstimates hashtag for quite some time. Even before that, before I even noticed that there was a hashtag, I and my team had been practicing a less-no-better-fewer-leaner-estimates kind of software development.
To sum it up, my story is basically that, in a context of co-called “Agile” software development, I was not comfortable with how estimates were done (the whole poker planning thing). Instead of trying to improve our estimation process, to make it more accurate and reliable, which is a path I respect, I, in a Lean-minded attempt, tried to remove estimates as much as possible and use historical data instead. I know that there is a recurring discussion out there about the very definition of what an “estimate” is and the difference there is between “estimate” and “forecast”. Honestly, although this discussion drives – consumes – a big part of the whole #NoEstimates thing, I don’t care much.
Ever since I began to read things about #NoEstimates, on twitter or elsewhere, I keep asking myself the same question. I might already have tried here and there to talk about it. Maybe I sometimes was a bit too vehement (euphemism), which may or may not explain why I still haven’t found The Answer. That is why I’m writing this open letter.
So my question to you is very simple :
Why do you even care about #NoEstimates ?
#NoEstimates is a hashtag where people who want to try to do software development business without estimates gather and talk together. To be precise I should write “do their software development business”. What I am meaning here is “I am a software editor, and I run the company without estimates because I do blah blah” : good for you! On the other hand “Estimates are a very useful tool for me and I can’t possibly imagine why I should not use them in the context of this US DoD public procurement I’m interested in.” : good for you too! That’s OK if you use estimates successfully. I once asked if anybody had ever heard of a no-estimate-like story in the context of public tendering. The answer was “no“. That’s not a big deal either.
So why do you all fight #NoEstimates like it was some kind of a threat ? Does anyone of you think that he is going lose his job if #NoEstimates proves usable in some domain ? Would it somehow jeopardize your business ? Please ! Please tell me why this permanent, impassioned rant about #NoEstimates !
P.S. : I know, because I’ve seen it already, that some of you will accuse me to try to avoid having a discussion : not at all! On the contrary I am really, genuinely eager to understand the very Why of all this.
P.P.S. : This open letter can be read as a follow-up to #NoOthers and #NoEstimates
Thanks Matthias.
To begin, I am not ‘anti’-#NE. My objections to it are not the idea of doing (some) projects without estimates. As I’ve said before, I’ve done projects in the past where I didn’t put together an estimate. My objections are more around the reasoning being put forth for the concept.
When I first heard of #NE I was directed to a number of posts that attempted to explain the reasons. The problem I had with almost all of these is twofold.
The first issue has to do with the reasons given for adopting #NE.
“Estimating is difficult, estimates aren’t accurate, we could spend that time writing code, estimates don’t match with real progress, all we’re doing is pulling numbers out of the air anyway, estimates are used to drive progress and produce bad s/w, etc – therefore the answer is to not do them.”
All of these may be true, but NONE of these have to do with estimates or estimating. They have to do with BAD estimates, bad practices, or bad management. An estimate is simply a tool, a method of gauging ‘expected’ progress. It’s not a concrete measure (or shouldn’t be), If you’ve got an estimate that doesn’t match, then double check your process, your assumptions, your historical data, you understanding of how estimates are made, etc. Don’t simply blame the tool because it’s hard.
The second argument has to do with the larger field of ‘project management’, and an unfortunate current trend to simply blame the tools when things don’t go right, and the disturbing trend to start tossing out every tool or measure in favor of ‘just doing the work’. NoEstimates, NoTools, NoTesting, BeyondBudgets… all of these are being espoused as revolutionary concepts. But more problematic, especially to someone who’s being involved in the pm field for several decades, is that as these are rolled out, each one is stood up on a pillar of ‘the old ways don’t work’.
And that’s the crux of my particular issue. The traditional ways do work, they have for the past 50+ years. In fact, the traditional pm methods have been around for awhile, and are continually refined to be more applicable, more useful. When they don’t work it’s because of either A) it’s not the right application, or B) it’s being used incorrectly. And I’d say that B is by far more often the culprit. Project Managment is about looking the project and the tools, and deciding what’s appropriate. And sometimes we get it wrong. But sometimes we also have people doing it that don’t really know how. And then when it goes wrong they blame the tool.
So, anti-#NoEstimates? No. I am anti ‘blame the tool when you don’t know what you’re doing, blame the tool when it’s the wrong tool, blame all the tools when you’d rather not learn how to use them correctly, and then blame ‘traditional’ project management”. Whew, that was a mouthful. 🙂
And before I’m blasted for being ‘stuck’ or a Command and Control adherent – I was using Agile concepts back before there was an Agile. I was managing portions of construction projects using a chanson board before I’d ever heard of kanban. Because it made sense. Not because the traditional ways didn’t work.
I’m anti ANY bad practice. The tools work, but sometimes the ones using them don’t. I don’t disagree with #NO. Just don’t come out and say it’s because estimates don’t work, or traditional project management practices don’t work, or this is the future of project management. We have decades or experience, and thousands of built projects (from software to submarines to buildings to business change, to events) that say different.
To take it a step further, most of the practices being espoused now as new, the future, a better way, whatever, can be found in the processes already around (traditional project management) including Agile processes.
Hi Trevor,
Thank you very much for this very interesting response.
You might have noticed my use of anti-NoEstimates, which is very different from pro-estimates. My goal here was to understand how some pro-estimates people became anti-NoEstimates.
Pro-estimates have very valid critics that are worth discussing, the main one IMO being “Don’t blame the tools”. You mentioned it. I am writing another post where I summarize my thoughts about NoEstimates and I will try to address this issue specifically (and also answer to some of Glen’s usual questions)
I am more interested in your second point here, which really is what this open-letter is about. It is very interesting to notice that, given your experience, you could very well be part of #NoEstimates. I would be glad to know in what situation, what domain, and how, you could actually do some projects without estimates at all. (I need to google about that : maybe you already shared your experience somewhere:) )
Yet you are more an anti-#NoEstimates than a #NoEstimates guy, and it seems to me that it is mainly because of some unfortunate “absolute” statements (“estimates are evil”, etc.). I will discuss this more in my next post, but what I can reply here is that I don’t share this point of view. #NoEstimates is and has always been about trying things, some say “exploring”, no “absolute” here in my opinion.
Anyway thank you very much once again. I really hope that all of this will make the whole discussion a little more…civilized.
Matthias,
Thanks for the response. I’m all for a civilized debate.
I don’t have to to go into this deeper (yet), but you’ve identified one of the problems – not everyone sees things the same. So you see #NE one way (not absolute), others see it differently. Those are the ones I’m responding to.
One example showed up yesterday – under the hashtag #NoTesting, the justification was that testing was required because owners ‘didn’t trust the devs’ . The suggestion was that trusting more would elimate the need for (I assume) useless testing.
I’m not sure about you, but on every project I’ve ever done I’ve gone through a testing or a start-up phase. Not because I didn’t trust someone, but because Murphy’s Law is alive and well, and as professionals we have a responsibilty to verify our work. I’ve yet to be in a situation where everything went perfectly. Trust doesn’t beat equipment failure or a bad line of code.
It’s those types of absolutes that I challenge. Mainly because younger or less experienced people that are in charge of projects jump on this because it’s less work, and focuses and ‘feeling good’ (trust) rather than professionalism, and that in turn perpetuates into more ‘bad’ managment.
We should be working together to improve project success, not arguing over hashtags, suspect ideas, or bad practice disguised as good.
Trevor
Matthias,
One of the core conjectures of #NoEstimates is that decisions about software projects can be made in the absence of making estimates about the attributes of the project. These attributes – at their simplest are the cost of producing the needed capabilities produced by the project over some period of time. Each of these are coupled to the other two in a dynamic behaviour http://www.slideshare.net/galleman/measures-of-effectiveness-measures-of-performance-technial-performance-measures
The suggestion that each of these attributes can be discovered in the absence of estimating their values appears to ignore the Microeconomics of decision making. That is outcomes in the future need to be assessed with information in the past, present, and future. Writing software for money is a Microeconomics process where alternatives – choices based on opportunity cost – are made on probabilistic assessment of those choices.
I’m not anti-#NoEstimates, I’m anti-ignoring the basic principles of business management when spending other peoples money.
Since those proffering #NoEstimates don’t appear interested in engaging on this level of discussion – the business processes of software development – it has been difficult to have a balanced discussion.
So the question – why am I anti-#NoEstimates? the answer is “It violates the principles of business management.”
I have a paragraph by paragraph response to your post, but first what to assess you response to my position before proceeding.
– Is there recognition that business process comes first?
– That microeconomics are the foundation of spending money, other peopls money, on the development of products or services.
– That those suggesting decisions can be made in the absence of estimating the impact of those decisions, have yet to show how the business processes can be addressed, beyond personal anecdotes?
Been thinking about your title and the notion of of “anti-no-estimates” That sets the tone that criticism of an idea is anti-that idea. This is a disease of the internet, since in another setting, legitimate criticism of any idea is calling just that criticism. Is the criticism informed? I’d say so for some simple reasons:
▪︎ The conjecture of no estimates is that decisions can be made in the absence of estimating the cost and impact of those decisions. While at the same time not showing how this can be done.
▪︎ That conjecture – and it is a conjecture in the absence of evidence – violates the principles of Microeconomics, where “opportunity cost” is the basis of decision making. And opportunity cost is in the future along with the benefit and the cost of that benefit. Both require estimates if those value are not directly in hand.
So I’d challenge you to invert the conversation. “How can decisions be made in the absence of estimating their cost and benefit to some degree of confidence (since both are probabilistic)?
Putting out an idea in the absence of evidence to support that idea is called opinion. But that’s certainly not what the originators of No estimates are saying. They’re writing books, they’re giving seminars, they’re proselytizing the idea that decision can be made in the absence of estimating.
When challenged to shown how that works, they invert the argument and assert rudeness, trolling, and “you’re like talking to a box of rocks,” which I take as saying “you’re simply too dumb to understand my brilliant idea.”
With that, time to call BS on the notion, wait for the “book” to see what the market has to say about this notion of violating Microeconomics. Maybe there’s a Nobel Prize in economics in there somewhere, maybe it’s just an uninformed opinion about how the business of writing software for money works. My money’s on the latter.
For now your letter is neither open nor unbiased. Go ask your CFO if she’s interested in paying for development without some understanding of how much, what, and when? And fixing the budget just bounds one of the three random variables, so don’t fall for that uninformed notion either. Go talk to those who actually “own” the money, and it’s not the developers, unless you’re self funded. If so no one cares what you do with the money.
Glen,
First I want to apologize for taking so long before answering to your comment. I’ve been pretty busy recently and I didn’t want to write something in haste.
So thank you very much for commenting, and replying to my open-letter. These two comments, and the one you also left on “Ravings on #NoEstimates” post – not that you needed them – are very clear about your point of view, and your critics toward #NoEstimates. If I may, I won’t talk about the critics any further here, since the focus of the open letter is “anti-NoEstimates”
There is a big distinction in my opinion between criticism of something and being anti-something. That is why I wrote this letter : I wanted to understand why some people, including you by the way, spend so much time trying to hunt #NoEstimates down. I wanted to understand their motivations. Unfortunately I don’t have the answer yet.
The main thing I don’t understand is that most of what you say is what most of the NE folks say. I mean Monte Carlo simulations, probabilistic estimations, etc. : we talk about them all the time. You say “bad management practices” and we say that as well. The only difference I see is the angle of attack : when you say “don’t blame the tool, learn to use it” we say “why not trying different tools”, when you say “violating microeconomics” we sometimes say “why not?”… but in the end we often agree.
The main point here is : you don’t think there are any situation when we can get rid of estimating, and you don’t see why someone would want to do such a thing… so be it. There are people out there who think (opinion, yes) that there might be ways to get rid of estimating in some situations and for the better. Why don’t you just let go?