Continued Discussion with Steve McConnell

Steve McConnell has responded to my response to his response to the #NoEstimates ideas. We have now exchanged emails, and I may touch on what’s said there. Mostly, however we’ll talk here about his responding blog entry. Go have a read of that, please.

Welcome Back!

There’s a lot to cover here. I’m going to try to do two things. First, I’m going to briefly address Steve’s concerns expressed in the above article. Second, I’m going to try to re-frame the conversation in hopes of driving out some important issues.

Theme

In Mary Doria Russell’s wonderful book The Sparrow, someone says:

Wisdom begins when we learn the difference between “I don’t understand” and “that makes no sense”.

What we’re trying to do here, I hope, is to understand. And while we may not agree, I think we’ll find that the ideas we’re talking about, both those pointing toward doing and improving estimation, and those pointing toward avoiding estimation where possible, do make sense and have merit.

Steve’s Article

Steve makes three main points. I’ll address them one at a time, leading each time with a quote from his article:

No, my example is not expert estimation

Ron’s first example is based on expert estimation using historical data and directly supports #KnowWhenToEstimate. His example actually undermines #NoEstimates.

Is my example based on expert estimation? No. It’s based on history but not on estimation. Our contractor does not estimate. He displays historical data as examples. He does not use them to create an estimate. If anything, he’s proposing some kind of magical incremental kitchen project. (I hate these building examples.)

Is there an implied estimate? Are we somehow, contractor and couple, forming an idea of what kind of kitchen is possible for $30,000. Yes. But we’re not saying, at any point in time, “We’ll build the kitchen we want for $30,000.” We’ve built a common understanding of what’s possible. We’re not working to that number.

Now, you can quibble with that, and call it an estimate. I really don’t care. If it’s an estimate, fine, then we need a new word for that other thing where you write down that you’ll build a kitchen for $30,000. See this related article about definitions.

Does the example support #KnowWhenToEstimate? Only if the answer to that question is “not now”, because the example doesn’t lead to estimation. Mind you, someone who’s thinking we should estimate, or thinking we really do and call it something else, will say “We’ve got history, we’ll use it to estimate”. Great. My guy has history and doesn’t use it to estimate.

Does the example undermine #NoEstimates? I think not. I think it is a kitchen-focused example of how to use history for something other than estimation.

Does Steve think it would work? Apparently not. And in kitchen building, I don’t think it would either. In software, it does work, because many of us are doing it.

Let’s underline that. #NoEstimates works. People are working successfully without estimates. I suggest that it makes zero sense to suggest that it doesn’t work. It would make more sense to figure out when it works, and why. I’m going to take a cut at that in the second part of this article.

Mind you, it’s always great to have that data. The question is what you do with it. My contractor has made no estimates. He has information which could be used to make estimates. Steve has noticed this. But he seems to have missed that my contractor made no estimates. This has led Steve to his second statement:

Yes my example does assume scarce resources

Ron’s second example assumes resources exceed what is needed to satisfy the requirements. When assumptions are adjusted to the more common condition of scarce resources, Ron’s second example also supports the need for estimates.

Well, yes, I am assuming that there is a solution to “satisfactory kitchen within $30,000”. That is in fact a condition of scarce resources. If in fact there is no such thing as a satisfactory kitchen for $30,000, we should not do the project.

Do we need estimates to decide whether a satisfactory kitchen is possible for $30,000? No. History suffices. Does looking at pictures of sample kitchens costing less than $30,000 constitute estimation? I think not. If you think it does, tell me how much the couple’s kitchen is going to cost.

When you try to do that, you’ll realize that you still don’t know what they want or what they’ll choose. You don’t know if they’ll spend $4,000 on cabinets, or $8,000. All that we know is that they’ve seen enough kitchen-price combinations to be confident that they can iteratively build a kitchen that they like.

This bit of the conversation does drive out some assumptions that I will expand upon in the second part. Briefly, I am assuming:

• we are going to go ahead;
• we have too much to do;
• we can find a satisfactory result by scope management;
• we’re working incrementally, by addition of elements;
• we will jointly discover the best possible scope within the budget.

We’ll come back to that. Let’s address another of Steve’s points:

No, we don’t have to go off the rails

In the base text of his article, Steve offers a new scenario where the project iterates along for $30,000 and somehow at the end the customer first notices that she’s out of money and the kitchen isn’t as good as it could have been.

This is simply a red herring. It’s not how an agile project works. But it does drive out an assumption that has not been made clear:

• The Customer is responsible for their own satisfaction. Agile methods like Scrum and XP have the customer making every single decision as to what to do next and what to defer. Scrum puts it this way: “The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.”

You don’t have to like this, but I suggest you’ve got to accept it. When the Scrum Guide and an author of the Stupid Old Manifesto tell you that the customer owns the responsibility to build the best possible product within the budget, I think you’ve got to do your future modeling based on that assumption.

A big question, of course, is “How is that even possible? How can a customer possibly manage such a hard problem, especially without a lot of planning and estimation up front?”

Good question. Maybe we’ll dig into that. But recognize for present purposes that Agile projects all over are doing that quite successfully. Do all of them do it? No. Probably not even a majority. Is it possible? Yes. Would I bet that I could do it? I sure as hell would. Can I point to other people I’d bet on? I sure as hell can. Can your team do it? With coaching, probably yes. I’d have to meet them first, and their management as well.

Anyway, Agile projects do not have to go off the rails as Steve suggests. Would estimation help them not go off the rails? Sometimes yes, sometimes no. Are there other things a project could do, other than estimation, to help them not go off the rails? Certainly.

For now, I’m leaving that without further support. If someone wants to dig into how we can do it, we can have a new article. Or maybe I’ll add an Appendix to this one: I happen to have it written.

Now the rest of Steve’s summary:

Yes, in some ways we nearly agree

Ron closes with encouragement to get better at working within budgets (I agree!), collaborating with customers to identify budgets and similar constraints (I agree!). He also closes with the encouragement to get better at “giving an idea what we can do with that slice, for a slice of the budget”–I agree again, and we can only provide “giving an idea of what we can do with that slice” through estimation!

Here, Steve says that we can only provide an idea of what what a slice can do by estimation. That’s one way. It’s not the only way. If Agile projects are doing what I recommend, they have agreed acceptance tests for every slice before they take it on. See the classic article on this.

Acceptance tests give us a very concrete idea what we can do with that slice. Do they tell us how long the slice will take? No. That’s why we slice down to one acceptance test, à la Neil Killick, because that makes them small enough that we can use observed cycle time to project progress, if we care to.¹

Steve says we can only know what a slice will do (or cost?) with estimation. We do it all the time without the #ProEstimates kind of estimation, and that’s good enough for me.

Steve goes on:

None of this should be taken as a knock against decomposing into parts or building incrementally. Estimation by decomposition is a fundamental estimation approach. And I like the incremental emphasis in Ron’s examples. It’s just that, while building incrementally is good, building incrementally with predictability is even better.

Yes, we totally agree here. Except for one thing. I suspect Steve thinks “and we can only get predictability via estimation”. And I, and the real #NoEstimates proponents say “we’re getting all the predictability we need without estimation”.

Bottom line response to Steve

My bottom line here is that no, there is no estimation of the kind we’re really trying to explore in our conversation. The #ProEstimates guys can win the conversation by saying “that’s estimation too”, and that’ll be fine, because we still won’t be doing the kind of estimation they seem to really be supporting, the kind where you figure out what things are going to cost in advance, and then tell someone, and then get held to building the thing mostly that way.

We really don’t do that. We really do build the thing incrementally, and by and large, without the #ProEstimates kind of estimates. I think the #ProEstimates folk should be doing what the #NoEstimates people are doing among themselves: asking “how do you do that” and “how could I do that too”.

But now I want to try a little re-framing.

Working with mostly unknown requirements

I suggest that the following are true:

• Estimating the unknown. If we know what the requirements are, and have other information such as history, we can in principle estimate the project. If we don’t know what the requirements are, we really can’t estimate the project, even in principle.

• Building the unknown. If we do know the requirements, some non-iterative approach might work. If we don’t know the requirements, our only hope is to develop in an incremental and iterative fashion.

I suggest further that the #NoEstimates people are working mostly on the “unknown requirements” end of the line, and the #ProEstimates people are working mostly on the “known requirements” end of the line.

It is conventional to behave as if all decent projects have mostly known requirements, low volatility, understood technology, …, and are therefore capable of being more or less readily estimated by following your favorite book.

All the other projects are just “research” projects and you deal with those in other ways, mostly by setting a very finite time and money budget and killing the project if it doesn’t seem to be working out. If it does work out, you convert it to the other kind as soon as you can.

This model appears to me to be left over from waterfall thinking. And it appears to me not to apply to any new product development, ever, at least not as done in small rapidly advancing organizations.

Be that as it may, the key point is that the #NoEstimates proponents are working in a world where no one knows just what the product should be, no one knows just how to build it, requirements are going to change, and we need to get something to market as soon as we can.

I’m not bringing this up to open a new debate on whether you can waterfall a research project. I’m bringing it up to highlight two very different underlying assumptions that are in play here, because those assumptions color our thinking.

Agile people tend to be thinking of ill-defined open-ended projects. That’s where Agile thrives. In ill-defined open-ended projects, project-level estimates are pretty much dead in the water, so these people tend not to value them much if at all. In this world, the Agile sweet spot, we work with budgeting, very short cycles, low commitment, and iteration, not with conventional estimates.

People who are strongly #ProEstimates, I expect, will be found looking at projects that are much like past projects, so that their history works. They’ll be looking at projects where you know most of what you’re going to do, so you can add up some estimates and apply a reasonable contingency factor. They value estimates because in their world, they work fairly well.

The two parties are living in different worlds, and that colors everything they think and say. It’s therefore very difficult not to be at cross purposes, even when we think we’re working the same examples.

So let’s summarize the #NoEstimates assumptions as I see them, including the ones from the first part of the article:

• We don’t know, and cannot know, precisely what we have to do;
• we are going to go ahead;
• we have too much to do;
• we can find a satisfactory result by scope management;
• we’re working incrementally, by addition of elements;
• we will jointly discover the best possible scope within the budget.

This is the prime turf of the Agile project. We live there, and those of us who are good at it thrive there. We do so, primarily because we can slice our experiments so thinly that we can perform hundreds, even thousands of them within our budget.

We perform those experiments in short time cycles of a week or two, or often only a day or two. We do them in an order selected to identify quickly whether we’re on the wrong path. We build things cleanly, so that what we create from these tiny experiments builds up into a growing sustainable always shippable product.

It may sound like magic. Fifteen years ago, anyway. In 2015, it’s time to get over doubting that truly Agile teams can do what they are in fact doing. Some Agile teams find estimation to be helpful. More and more of them are finding estimation not to be as helpful as one might expect. Those teams are moving closer and closer to doing no estimates, and are flying the #NoEstimates banner.

It makes sense to explore what these people are doing, how, and why. I suggest that it’s pointless to say that these bumblebees can’t fly. They’re flying.