The Case for and Against Estimates, Part 4

When we think about the discussion about estimates and #noestimates, I have one big question:

Where do you want to spend your time?

In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)

In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off. 

In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.” 

For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)

In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean,  you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.

Here’s the way I like to think about #noestimates:

Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.

I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.

In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.

On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.

When I think in #noestimate terms, I think of showing value for the entire product.

Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.

When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.

In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.

Back when I wrote code for a living, I was not good enough to deliver in  hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.

When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.

In my work, I want to show value as early and as often as possible.  When I work with teams and managers, that’s part of my work with them.  Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.

I have found it helpful to create an order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.

The smaller the deliverable, the more often  you can get feedback and show value. I have seen these benefits from working this way:

  • The project ended earlier than we expected. That’s because we delivered “enough” to satisfy the PO/customer. (I’ve seen this many times, not just a couple of times.) If we had spent more time generating a detailed estimate, we would not have delivered as quickly.
  • We learned enough about the deliverables that we were able to do more discovery (as Ellen Gottesdiener says) as we delivered. We made the whole requirements process continuous and just in time. We did not require hour-long pre-sprint planning meetings. (Okay, that’s only happened twice. I have hope for more experiences like this.)
  • We were able to fix things before they got too large. We’d started in one direction on a feature set, realized we were headed in the wrong direction and replanned what to do and how to do it.

To me, the idea of #noestimates is tied up in small chunks of value.

#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.

The posts to now:

  • Part 1 talked about targets and order of magnitude estimates.
  • Part 2 discussed when estimates are not that helpful. I did not include bad management in this post. Managers who treat estimates as commitments are not helping anyone.
  • Part 3 is about when estimates are helpful.
  • Part 4, this post, is about #noestimates.

I’ll do a summary post, including a pointer to the original article in part 5.

Tags: , , , ,
Previous/Next Posts
« »

14 Comments

  1. Glen ALLEMAN

    The notion that we’d rather spend your time coding tan estimating is a strawman at best. It send the message “I so important I can’t possibly bother with being a member of the business team, where estimates are needed to make decisions.”

    Those paying for your coding have a fiduciary need to know how much, when, and what will be produced.

    That is a “coders” – labor – view of how business and business decisions are made.
    This is not only self centered it ignores where their paycheck comes from.
    Now “coders” may not be good at estimating, but even that is a strawman. I can get you within ± 15% of a starting estimate in 5 question. NOT an order of magnitude which is ± 100%. OOM is an Exponent value 10^1 = 10, 10^2 = 100, 10^3 = 1,000. That an order of magnitude estimate.

    Here’s how to estimate any software problem, in less than 90 seconds http://herdingcats.typepad.com/my_weblog/2016/05/how-to-estimate-anything.html

    Those cones of uncertainty that NE’ers love to use must have units of measure on the vertical axis. Every estimating handbook we use – in any domain that is not de minimis calibrate that scale. They use them without calibration as an excuse that estimates are of no value upfront.

    So time to stop with the excuses. Our domain is not your’s but applying principles of making decisions in the presence of uncertanty when spending other people’s money is a obligation of those spending the money, otherwise they’ll be relegated to just being told what to do, by those who have stepped up to that obligation.

    It’s time to make this clear – if coders don’t what to estimate or learn how to estimate at some credible level, they will become just labor, with their work planned, managed and assessed by someone else. I doubt that’s what anyone wants in our software development domain.

    Reply
  2. Glen Alleman

    And by the way, our domain is no different that any other domain at the business level. Just the scale.

    Making decisions in the presence of uncertanty requires making estimates of the outcomes of those decisions.

    This is a immutrable principles of the Microeconmics of Software Development and Managerial Finance.

    Those conjectures estimates are a waste, and we need to get back to producing value have failed to learn an immutable finance principle

    ROI = (Value – Cost) / Cost

    You Can Not determine the Value of an object without knowing the cost to procure that object. Both Value and Cost are mandatory to make a Return on Your Investment decision.

    So when we hear “focus on Value, not cost” that person never attended a High School accounting class. Don’t listen to that advice, useless you plan on becoming just labor on the project

    Reply
  3. Jim Grey

    The kinds of software I’ve always built has been sold to other businesses to help them do things like manage marketing campaigns or move work through a manufacturing floor or provide customer service in various domains. In each case, most closed deals had some deliverables associated with them, things the developers needed to build to fulfill the deal. Additionally, taking features to market creates revenue opportunity, and companies want to maximize that. So they all have wanted some predictability around delivery.

    I’ve read in other blogs about are companies that have lower needs for that predictability because of the markets they serve. I scratch my head over how that’s possible, but all I know is B2B software. I do know that even in the B2B companies I’ve worked for, when they’re still in startup mode there are bigger problems to solve than predictability for a long time.

    I like Mike Cottmeyer’s predictive-adaptive/emergent-convergent axes (here: http://www.leadingagile.com/our-compass/). I’ve been part of companies as they’ve shifted quadrants in that model, and it’s a hard transition as it always goes in the direction of desiring greater predictability, generally as the company “crosses the chasm” into mainstream markets. I feel like my job as a program manager is to honor the inherent unpredictability in software development while framing things for company leaders with as much predictability as I can. If I keep checking actual progress and resetting expectations around delivery accordingly, usually leaders can cope. And this process provides so much insight into a team’s effectiveness that can be used to help it execute better.

    Reply
    • johanna

      Jim, thanks. I had not seen the axes. Love it!

      I have seen more need for predictability when you have a “close” customer or you do custom work. I have seen more need for more frequent releases when you have mass market, even if that market is not consumer.

      Reply
  4. Dave Gordon

    Johanna, I just wanted to say I truly admire you for being willing to write about controversial topics in an even-handed way. Not everyone is willing to risk becoming a piñata to advance our professional dialog.

    Reply
    • johanna

      Dave, thanks so much. My coffee cup has heard things I have not typed.

      Reply
  5. Glen ALLEMAN

    May I suggest that you comment …

    “In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.”

    Is not based on any direct experience with the programs I work on. A $400M Fed Civ IT program delivers working software to a major government agency every 3 weeks into production.

    This is a familiar and troubling example of making unsubstantiated claims about how Agile at Scale for Software Intensive System of Systems using Agile in the form of SAFe 4.0 processes.

    Reply
  6. Glen B alleman

    I’d like to add that another program I work (PMO, Scrum Process Improvement), that delivers “value to the customer” every Thursday evening for 700,000 users of a State ACA enrollment and qualification system.
    The notion that our programs behave in the way you conjecture is simply that – conjecture.
    These two examples, are similar to other programs we work where Agile at Scale produces production value from every week to a maximum of 4 weeks.
    The notion of a Product Roadmap and Release Plan makes that value visible on Day One for the work for the Team. The customer can see the increasing value delivered by the 2 to 4 week delivery of production software and how that value fits into the business strategy – usually a Balanced Scorecard with measures of effectiveness and measures of performance assessed in Dollars against to cost to produce that value.

    Reply
    • johanna

      Glen, that’s great. I agree that other people can do what you do in terms of delivery at scale. That’s why I wrote Agile and Lean Program Management.

      I see more programs that have trouble delivering.

      Reply
  7. Henrik

    Hi!

    A comment on: “Noestimates is not about not estimating”.

    May suggest changing the name then? I mean, if that’s the case then the name isn’t very helpful or at worst even confusing or perhaps damaging (I can provide link where someone raised this issue). Just like when I code and declare variable and function names; I aim at clear intention/meaning. Otherwise a rename isn’t that hard.

    I’m not comfortable with the “it got stuck” argument. Because: aren’t we able to be “agile” here? “It got stuck” sounds too rigid for my taste. Imagine all the things we wouldn’t be able to change just because “it got stuck”.

    Kind regards,
    Henrik

    Reply
    • johanna

      HI Henrik, you and others have suggested this. I would love it people changed the name! Maybe the people who originated the #noestimates hashtag will chime in. Maybe they have a different way of thinking.

      I realize you think “it got stuck” is not a good answer. Maybe you have suggestions for a new hashtag?

      Reply
      • Henrik

        It seems to mean a lot of different things. Not a single definition of what people mean by it. In your case (based on what you write), I’d suggest #VDD (Value Driven Delivery)? Shorter as well 🙂

        Reply
        • johanna

          Henrik, lovely. Maybe I will start using #VDD.

          Reply
          • Henrik

            😀 Cool! Perhaps even #FVDD for even more clarity (as in Frequent Value Driven Delivery)? 🙂

Submit a Comment

Your email address will not be published. Required fields are marked *