Thursday 13 March 2014

#NoEstimates is not for me, part II

I've written some posts about the #NoEstimates topic. I found it very interesting. And very "giving" and learning. But I've come to the conclusion that it doesn't exist. Why? Let me explain.
But first, this is my definition of "estimate", the transitive verb: http://i.word.com/idictionary/estimate

"Estimates are waste"

Yes, they might be. Anything can be waste. Easy: Stop! Don't do stupid things on purpose. Nothing new or special about that. #NoAnything would apply, or maybe more specific #NoWaste might be a more appropriate tag? Nothing more to say about that.

"Explore alternatives to make decisions in software development. That is, make decisions with 'no estimates'"

Why would you want to do that? Why find alternatives to something obvious? Can we make decisions without meetings? Sure. But why? Meetings are a great way to make decisions. Making decisions with other people is the best known way to make decisions. Why explore alternatives to that? Same thing with estimates. Are there alternatives to the wheel? Yes, you can use an airplane or a boat. But the *wheel*, it's unbeatable, one of the first thing mankind invented, and it's still the best. Why explore?
And, a decision - by definition - is to choose between one or many future paths. And whatever we say about the future - it's an estimate. Can't argue that. Thus, "no estimates" is not applicable when making decisions. At least not in software development.

Update:
If "exploring alternatives" is what we like to do, with the purpose that it's better to have *more* alternatives, then I don't get the "no estimates" either. Estimates are great knowledge when making decisions, why remove that alternative? Why remove any alternative?

"Not getting the question of 'how much/when?' at all"

This I can get. Deliver often and more important: deliver something valuable often. But this is true even when you choose to do estimates. Nothing to do with "no estimates". But if we work this way, the question of "how much/when?" might not come as often (or at all)? Sure. But still. Someone has to pay for the work getting done. That person wants to know, roughly, what he/she is expected to pay. And he/she wants to know in advance. Can't question that. Unless you plan to work for free, this is always true. Thus, "no estimates" doesn't exist. 
In the "smaller loop" (when someone already knows, roughly, what the expected cost is and "the work" has started) you might throw away estimates. This is the only valid point of "no estimates" as I can see. I've done similar things before (without even knowing that "no estimates" existed). But it's close to my first point above. Don't do stupid things. If no one requires you to do estimates - don't! And if this is the only valid point of "no estimates" then it's not much to "hang in the Christmas tree" (as we say in Sweden when something is of not much value).

"Focus on value instead of costs or estimates"

Yes, of course. But this has nothing to do with estimates or "no estimates". You can do both. At the same time. And value is tightly coupled with cost. At least in software development.

"Forecasts is not estimates"

No comments on that. Learn English, maybe?

Final words

I might still be convinced though :-)

6 comments:

  1. The problem with statements like "Don't do stupid things on purpose." is that while they are perfectly reasonable, they seldom are actionable.

    Who does anything stupid on purpose? Many does estimates-estimates (like story-point game and then estimating tasks by hours), and don't think about it at all. They just keep doing it because Scrum. Some might subconsciously think that maybe there could be alternatives for that. #NoEstimates puts a spotlight on certain type of waste -- unnecessary estimates.

    ReplyDelete
  2. Sure. But again, that's not been the thrust of the #NoEstimates folks, except maybe lately as they've backtracked from their extreme stance that ALL estimates were wasteful, deceptive, not necessary. (e.g., "I can’t recall any situation where estimates were of value to the actual job at hand." or "People often tell me “even though we know the estimates are inaccurate, they are better than nothing”. I prefer nothing.").

    No one objects to reducing things that are unnecessary. But there's room for a LOT of discussion, positive in nature, about the many times that estimates provide helpful value, promote stakeholder confidence, inform business decisions, etc. There has been little/no receptiveness on the part of #NoEstimates advocates to engage on those topics, and they've consistently bailed on answering even their own posed questions or discussing others' answers to those questions.

    As a result, I and others have trouble, at this point, regarding #NoEstimates as a genuine exploration or as a discussion being held in good faith. Seems a lot closer to sheer evangelism, along with mostly just plain old cheerleading from like-minded individuals.

    ReplyDelete
  3. Seems to me that you are only thinking about this from your context as a consultant/contractor. It is a totally different situation in other contexts. I haven't estimated anything since I quit as a consultant last year. We practice Build Measure Learn (from Lean Startup). Estimates are meaningless in that context.

    Maybe you can find a way to get No Estimates to work for you as a consultant. I don't know. I'd be happy to discuss it over lunch sometime :-)

    ReplyDelete
    Replies
    1. Let's have lunch! :-)
      I bet there is estimates somewhere. But I'd love to hear more about that!

      Delete
  4. Antti,

    "Don't do stupid things on purpose" is a management process used at a large nuclear cleanup program I worked. It is completely actionable, if you make explicit effort to ask simple questions:
    1. Is what we're about to do support the goal of providing the needed capabilities to the customer or stakeholder.
    2. Is what we're about to cause irreparable harm to the project, people, the environment?
    3. Is there anyone in this room that thinks this is a bad idea. If so it is encumbant on all the other people in the room to consider the room cause of that concern and confirm within a reasonable doubt that we have considered to conseqeunces of the decision.

    These questions and many more all come from the Rasmusson nuclear safety and safeguards report in the 1970's It is applicable to any domain.

    This notion - and a very naive and many times dangerous notion - of "let's try this a see what happens" is counter to that paradigm.

    Don't do things that risk the integrity of your customers project, money, or business success. Period. Not exploring on the customer's money unless have explicitly defined that experimenting in a WBS element called "experiment using my money."

    ReplyDelete
    Replies
    1. Glen,

      Having read your reply I feel I need to explain what "let's try this and see what happens" means for us.

      First of all, there are two types of "exploring": exploring over the product (what is built) and exploring over the process (how is it built). The latter is the one I'm mostly talking about.

      Here are some of the "let's try this and see what happens"-activities from past couple of months:
      - instead of live daily meetings, handle daily standups via email (due to time diff)
      - instead of regular stakeholder demos, organize them when there is X number of features to demo
      - instead of whole team planning meetings, divide into smaller groups (this one we noticed didn't work)
      - instead of estimating stories in story points, we ask ourselves "can we make this smaller?"
      - if we have 2 hour meeting, decide that we have 10min mandatory break in between

      This isn't really even that much about #NoEstimates, it's standard continuous improvement / PDCA stuff.

      I'm spending our bankers' money. I would feel irresponsible if I *didn't* explore ways that make our team and our organization to produce value as effectively as possible.

      I'm sensing you are more talking about exploring over the product?

      Delete