Surely all twitter conversations go well …

A few days ago, I engaged in a long Twitter exchange with Clarke Ching. The exchange began when Clarke tweeted a long sequence outlining a case where he felt that estimates had caused a team to achieve great results:

We started a 60 man project by estimating the many features requested. Too many. Customers prioritized 3 times. Scope shrunk. Scope shrunk enormously. Only the most valuable stuff was left. Productivity boosted enormously because value of OUTPUT was very high.

Clarke went on to report via Twitter that he had quite a few examples of using estimates to create an environment of “scarcity”, resulting in the team prioritizing the work for good results.

I did not believe — and do not believe — that estimation was essential to those good results. I did not believe — and do not believe — that a feeling of scarcity was essential to those good results.

I believe that there was something more essential going on.

I wanted Clarke to discover that more essential thing for himself.

Yes well that didn’t go so well did it?

I felt that Clarke had observed a complex series of events that began with an estimation session and ended with a de-scoped project plan, and that he had incorrectly concluded that estimation had caused the good results. I believed he had fallen into the post hoc ergo propter hoc trap.

Then followed a long and mutually frustrating exchange on Twitter. Clicking the picture below should take you to that exchange if you feel you want to watch an unproductive conversation in detail.

R: Do you actually believe that estimation caused all that stuff? C: Absolutely. Estimation caused scarcity caused slicing and dicing.

I have a different view of what was essential to the situation. Let’s freely grant how arrogant that is: I wasn’t even there. How could I possibly know better than Clarke what caused the success? Well, read on. Soon you’ll get to my thoughts on what really happened.

I didn’t want to convince Clarke that he was wrong: that would make me win and him lose. But it was clear to both of us that we didn’t agree. Clarke wanted me to tell him what I thought he should think. I didn’t want to do that: I wanted him to discover within himself a deeper, more rich grasp of what went on and what role estimation happened to play in it.

Well, that didn’t work. It was just frustrating for both of us. My thought was that Clarke was looking at the surface flow, something like this, my words not his: Estimates caused Scarcity Thinking caused Scope Reduction caused Success. I think the essence of what happened is likely quite different.

Suffice to say that all my attempts to get him to dive deeper into his experience did not work. They served only to tick him off. So much for the Ron Jeffries as Cryptic Socrates trope.

Next time maybe I’ll try something else.

Is there any basis for agreement?

The simple chain of causality “Estimation caused scarcity caused slicing and dicing” simply cannot be true. It is over-simplified to the point where it has abstracted away everything that really happened.

I think Clarke and I would agree that “slicing and dicing” was essential to the success of the projects he spoke about. In each case he mentioned, after starting with a huge number of things to do, the teams reduced scope and prioritized it, resulting in a slimmed-down product that could be done with the time and money available. I think we’d agree that the slimmer product was probably better and more elegant than the original bloated plan.

I think we would agree that scope reduction and prioritizing was essential to this result. I think we would agree that slicing big ideas down to thinner ones allows us to get more value from the team’s work, producing value faster.

In The Nature of Software Development I have this picture:

value growth

The point of this picture, and a major point of the book, is that if you do high value things first, and low value things later or never, you’ll build value sooner. Building value sooner, you’ll get a cleaner more elegant product before you run out of time and money.

That’s what Clarke’s teams did. They found the high value bits in their giant plan, prioritized them, and built them, resulting in a superior product within the constraints of time and money.

That, I feel sure, is what we agree on.

Estimation did not “cause” that

Did estimation cause that to happen in some essential way? I don’t think so. Certainly they did estimation and it only took a few days from a huge project. Clarke admonished me at some point that the estimation was so cheap that I couldn’t object to it on the basis of cost or waste.

Well, I don’t object to the estimation on the basis of cost or waste. I don’t object to it at all. I’m just pointing out that estimation, though it was going on, was not an essential cause of the good outcome.

Similarly, “scarcity thinking” was not an essential cause of the good outcome.

Reducing scope to the highest value items and doing those first — very likely doing those only — was essential. Nothing else was.

Clarke and the teams on those projects got to reduced, prioritized scope, using estimates to create an understanding that there wasn’t enough time and money to do everything in the world, and the group responded by buckling down and doing the necessary scope reduction and prioritizing. That’s good!

Scope reduction and prioritizing were necessary to that success. Estimating and feeling scarcity were not.

The result was great. What likely “caused” that good result was a complex interaction of people of good will, coached by Clarke, and surely coached by lots of other people in the room, coming together and doing the essential thing we call here “slicing and dicing”.

Estimation won’t always work that way

Estimation won’t always cause scarcity thinking. Sometimes people will be so optimistic with their estimates that they’ll not feel any limits. Other times, someone in the room will be so focused on having it all by the deadline that estimates will be forced low enough to fit, resulting in everyone leaving the room with a schedule that perhaps no one really believes, but with none of the necessary slicing and dicing.

Scarcity thinking won’t always cause slicing and dicing. Sometimes it’ll just lead to an impossible schedule. Other times it’ll just lead to concluding that “we’ll have to work harder and smarter”. How nice.

Sometimes estimation and scarcity thinking lead to good results. Often — far too often — they do not.

The essential element is focus on value

Clarke and other people coaching these teams happened to use estimation and scarcity thinking, to do the essential thing that actually works: slicing and dicing.

There may be other ways of getting getting the right work elements into the project when our wishes are large and our pocketbook is small. They all look to me like de-scoping and prioritizing. They all look to me like examining each “requirement” and pulling out the most valuable bits, letting the less valuable bits go.

Estimation and scarcity thinking are not essential tools in this endeavor. They may be useful. I find that, often, they are not even useful. I think Clarke wielded a very dangerous set of tools quite well: I would not recommend that others blithely run off and try those tools. Estimation and scarcity thinking were going on when the good result happened. They didn’t cause that result. They were proximate to a good result, but not essential.

Clarke and his team brought about a focus on value. That’s what you can make happen: that’s what you must make happen. You may be able to make use of estimation and scarcity thinking to get there. I’d advise being open to, and preferring, other approaches. In particular, I’d advise focusing directly on value, not on cost.

The essential practice looks to me to be Slicing and Dicing.

The essential focus looks to me to be Value.