cumulativehypotheses

TL;DR

You may be pleased to learn that this is probably the penultimate thing I have to say here about #NoEstimates.

Anyway, it’s for these reasons…

It’s conceptually incoherent

From what what I can gather from following twitter discussions, and reading blogs, and articles, and buying and reading the book, then, in #NoEstimates land, supposing that someone were to come and ask you “how long will it take to develop XYZ piece of software?” then any one of the below could be an acceptable #NoEstimates answer, depending on which advocate’s line of reasoning you follow:

1. Estimation is morally bankrupt and I shall have no part in continuing the evil of it. You are a monster! Get out of my office! But fund the endeavour anyway. Yes, I do mean an open-ended commitment to spend however much it turns out to take.
2. Estimation is impossible even in principle so there is no way to answer that question, however roughly. But do please still fund the endeavour. No, I can’t indicate a reasonable budget.
3. Estimation is impossible even in principle so there is no way to answer that question and even if there were I still wouldn’t because you can’t be trusted with such information. No, I can’t indicate a reasonable budget. It’ll be ok. Trust me. No, I don’t trust you; but trust me.
4. Estimation is so difficult and the results so vague that you’re better off just starting the work and correcting as you go. It’ll be ok. Trust me. No, I still don’t trust you.
5. Estimation is so difficult and the results so vague that you’re better off choosing to invest a small, but not too small, amount of money to do something and learn from it and then decide if you’ve come to trust me and want to do some more (or not, which would be disappointing but OK). For your kind of thing, I suggest we start with $BUDGET_FOR_A_BIT, expect to end up spending something in $TOP_DOWN_SYNTOPIC_ESTIMATED_SPEND_AS_A_RANGE
6. Estimation is difficult to do with any useful level of confidence and the results of it hard to use effectively. What would you do with an estimate if I did provide it? How could we meet that need some other way?
7. Here is a very rough estimate, heavily encrusted with caveats and  hedges, of the effort required to deliver something of a size such as experience suggests that what you asked for will end up being. No, I will not convert that into a delivery date for you. Let me explain a better way to plan.
8. OK, OK, since you insist, here is a grudgingly made estimate of a delivery date in which I have little faith, I hope it makes you happy. Please don’t use it against me.

For the record: my preferred answer is some sort of combination of 5 and 6, with a hint of 4, and 7 as a backup. And I have turned down potentially lucrative work on the basis of those kinds of answer being rejected.

That’s a huge range of options, many subsets of which are fundamentally, conceptually, incompatible with other subsets. Which means that #NoEstimates doesn’t really seem to me as if it’s much help in deciding what to do.

Except…one good thing about #NE is that it does rule out this answer: “let me fire up MS Project and do a WBS and figure out the critical path and…” which is madness, for software development, but you still see people trying to do it.

Also for the record: In my opinion far too many teams spend far too much time estimating far too many things in far too much detail, and in ways that aren’t sufficiently smart or useful.

Even in an “Agile” setting you see this, and for that I blame Scrum which has had from the beginning in it this weird obsession with estimating and re-estimating, and re-re-estimating again and again and again. I don’t do that. And I certainly don’t do, and do not recommend task-level estimates (or even having tasks smaller than a story).

I can’t understand what anyone’s saying

It seems as if the “no” in #NoEstimates doesn’t mean no. Or maybe it does. Or it might mean: prefer not to but do if you have to. Or it might mean: I’d prefer that you didn’t, but if it’s working for you carry on.

And the “estimate” in #NoEstimates doesn’t mean estimate. It means: an involuntary commitment to an unsubstantiated wild-arsed guess that someone in authority later punishes you for not meeting^§. Or it might mean estimate after all, but only if the estimate is based on no data. If there’s data, then that’s a “forecast”, which is both a kind of estimate and not an estimate.

“Control” seems to be a magic word for some #NE people. It’s said to them in the morally neutral, cybernetics sense but they hear it in some Theory X sense, as if it always has the prefix “Command and ”. This creates the impression that they have no interest in being in control of development, budgets, etc. Which might or might not be true. Who can say?

So not only are the #NoEstimates concepts all over the place, they’re discussed in something close to a private vocabulary—maybe more than one private vocabulary. This is not an effective approach to an engineering topic.

Nevertheless: it’s strong medicine and it’s being handled sloppily

…which, if you’ve ever taken strong medicine you’ll know is a poor policy.

In the contexts for software development that I’m familiar with^† the idea of making estimates as an input to a budgetary process at the level of months, quarters, years and maybe (hopefully) beyond is really deeply baked in. Maybe this is part of why Scrum has managed to find such a better fit in corporate land that, say, XP ever did, because a Scrum team can seem to still play that game.

For a development team to around and say even that estimates are too difficult to make useful so lets do something else instead is very challenging to the conventions of the corporation. Conventions which I believe should be challenged, in principle. To turn around and say estimation is (and always was) impossibly difficult and management were doing bad things with the results of it is going to deeply challenge and upset many people in an unhealthy way. That’s not the way to effectively change organisational habits. We saw this before with Scrum.

Now, I happen to be of the opinion that estimation is hard, but can be done well, and you can learn to do it better, and the results of it are often misapplied. And I’ve come to the opinion that the most effective and/because least upsetting route to dealing with that is to re-educate managers to do their work in a better way such that they stop asking for estimates.I  find that coaching managers to ask more helpful questions beats coaching programmers to give fewer unhelpful answers.

For the record, too: I agree that too many enterprises use developers’ estimates in a way that is invalid in theory, unhelpful in practice, and questionable in its effect on the long term health of the business (and the developers). But, also for the record, I do not agree that this is an inevitable consequence of some intrinsic problem with estimation.

But in the #NE materials that I’ve seen there’s not really much recognition of these organizational aspects of the proposed change. It seems mainly to be about convincing developers that they shouldn’t be producing estimates and explain how misguided (and best) or evil (at worst) management are to ask for estimates in the first place.

We’re just not smart about this kind of thing

…and the treatment of #NoEstimates that I’ve seen fosters exactly the kind of not-smartness that can get us into a real mess.

The industry, and corporations within it, and teams within corporations have a tendency to lurch from one preposterous extreme to another, and to wildly mis-interpret very well intentioned recommendations. This is a particular problem when the recommendation is to do less of something that’s perceived as irksome.

eXtreme Programming offers a good example. When considering a proposed way of working I often find it useful to consider to what it has arisen as a reaction. On one hand, #NoEstimates seems to be partly a reaction against the very degenerate Scrum-and-Jira style of “Agile” development that many corporations are far to comfortable with. And on another hand, it seems to be a reaction against some really terrible management behaviour^* that’s connected with estimation.

eXtremeProgramming can be usefully read as a reaction against the insane conditions^** in large corporate software shops in the mid 1990s. People who really wanted to be programmers rushed to XP with joyous relief. As it happens I took some convincing, because I kind-of wanted the models thing—and not just boxes-and-arrows, I love, love, love me some ∃s and ∀s—to work. But it doesn’t. So, you know, I’m able to recognise that my ideas need to change, and I’m prepared to do the work.

Anyway, in part of the rush to XP we found that people abandoned the writing of design documents—these days they’d be condemned as muda, but that Lean/kanban vocabulary wasn’t so widespread then—but unfortunately the design work that we were meant to do instead in other ways didn’t really get picked up. Similarly, BRDs and Use Cases and all that stuff went out of the window but good requirements practices tended to vanish too. And the results were not pretty.

And so, over a long and painful period we had to invent things like Software Craftsmanship to try to re-inject design thinking, and we—that is, Jeff Patton—had to introduce things like Story Mapping to get back to a way to talk about big, complex scope.

I expect the worst

I invite you to get back to me in, oh, say, 5 years and check on this…forecast: Either #NoEstimates will have burned out and no-one will really remember what it was, or…

1. There will be a[t least one] subscription taking membership organization  devoted to #NoEstimates
   1. Leading members of that organization will make their living as #NoEstimates consultants and trainers, far removed from any actual development
   2. This organization will operate a multi-level marketing scheme in which the organization certifies, at great expense, senior trainers who train, at substantial expense, certified trainers who train, at not outrageous expense, certified #NoEstimates “practitioners”
2. adoption of #NoEstimates will turn out to lack some benefit of estimation that #NoEstimates advocates wont’t see and can’t imagine and some other practice will have to have been invented to get it back.

And then the circle will be complete. I don’t think that we’re collectively smart enough to avoid this dreary, self-defeating outcome.

Update—as if by magic, this twitter exchange appears within 12 hours of my post (NB I mean no criticism of either party and I thank them for holding this conversation in public):

Noel asks: What is the first thing one should consider when contemplating a move to NoEstimates?
And Woody replies: #NoEstimates isn’t something you “move to”. It is about exploring our dependence on and use of estimates, and seeking better.

I expect that many conversations like this are taking place. And that’s how the subtle but valuable message fades away and the industry’s hunger to be told the right thing to do  (and then, worse, do it) takes over.

§ A terrible idea which I am happy to join in condemning

† Which is largely in corporations, by which I mean for-profit enterprises which intend to be consistently profitable over a long period.

Although I have worked at, as it were, newly-founded companies with few staff, little money and one big idea, working out of adapted loft space I don’t characterise those as “startups”. That’s because the business model was not to throw fairly random things at the wall in the hope that one of them stuck long enough to pay the bills until the next funding round arrived; repeat until exit strategy kicks in or broke—which is how I understand “startups” to work. That’s a world that I don’t understand very well because I haven’t done it.

So: some of the corporations I’ve worked have been product companies, and some sold a service, and some were small and local and some were large and global, and plenty of variations on that. That’s the world I understand, and what I write here grows out of that understanding.

* Years ago I was asked to brief the management functions of a certain corporate entity about this new “Agile” thing that the technology division wanted to do. This was interesting.

The F&A people wanted to know when, during an iterative, incremental development process they were supposed to create the intangible asset on the balance sheet representing the value-add on the CAPEX on building the system, so that they could start amortising it.

The HR people wanted to know how, with a cross-functional, self-organizing team in place, they could do performance management and, and I quote, figure out “who to pay a bonus to and who to fire”.

I’ve recently heard of companies that link the “accuracy” (whatever that might mean…) of task estimates to bonus pay. And I agree with J.B. that it’s fucking disgusting. What I very much doubt is that fixing that state of affairs is primarily a bottom-up exercise in not estimating.

** Around that time I held—mercifully briefly—a job as a “Software Engineer” in which the ideal we were meant to strive for was that no code was created other than by forward-generation from a model in Rational Rose.