Steve McConnell recently published 17 theses regarding estimation. Pay no attention to the fact that the last guy who posted 17 theses was a heretic. Go ahead and read his thoughts. I’ll wait.

Quick replies

Let’s quickly review some of those to assess the extent to which we may agree. Because this is a quick scan, it may seem a bit harsh. On the contrary (as Thomas used to say), I’m merely trying to delineate areas where we may differ. I’m not saying we disagree radically. But see the Digression below.

1. Estimation is often done badly and ineffectively and in an overly time-consuming way.

Yes, definitely.

2. The root cause of poor estimation is usually lack of estimation skills.

I do not agree, if I am allowed to rephrase the thesis this way: “The root cause of estimation problems is usually lack of estimation skills.”

The most common problem I see with estimates is that they are misused, in two very important ways. First, they are used as a bludgeon by management, who push downward on them to try to drive out more work, and who then use them to hold developers’ feet to the fire. Second, a focus on cost is exactly the wrong thing to do on any Agile project, which should be looking at value, not cost.

The results of this misuse of estimates is lower quality, due to developers trying to meet aggressive estimates that they never made, and slower delivery of value, due to the business trying to drive the project by cost rather than steering by value.

3. Many comments in support of #NoEstimates demonstrate a lack of basic software estimation knowledge.

This is at best questionable. Let’s observe that most comments regarding #NoEstimates are tweets, and it’s not entirely easy to express one’s entire resume in a tweet. This statement is at best condescending and quite likely incorrect.

4. Being able to estimate effectively is a skill that any true software professional needs to develop, even if they don’t need it on every project.

It seems to me that this is an expression of belief, not an expression of fact, despite some following remarks about all this not being religion.

Certainly, it’s one of the best “No True Scotsman” setups one could imagine. With #3 and #4 in hand, we can now accuse #NoEstimates people of lacking basic estimation knowledge and therefore not being true software professionals. Argumentum ad hominem seems not far off.

Now, as it happens, I believe that software professionals should have some skill at estimation, and that if they find themselves in a real situation where their actual skill is letting them down, they’d be wise to improve their skill. This is quite different from blanket accusing “many” who are working #NoEstimates of not being true software developers.

As to the truth of the assertion that estimation is a critical skill, this is clearly true in situations where estimation is needed, and clearly not true in situations where estimation is not needed. It’s also a very wide brush: what kind of estimation are we talking about? (Steve kindly sent me a Construx Quick Reference sheet listing no fewer than 35 estimation techniques. Surely some of these are more valuable than others, depending on the organization and one’s place in it.)

5. Estimates serve numerous legitimate, important business purposes.

They do. They also serve numerous less important, less legitimate purposes. Since estimates are always waste, although sometimes necessary waste, it is important to be careful with a blanket statement like this.

6. Part of being an effective estimator is understanding that different estimation techniques should be used for different kinds of estimates.

Sure. What Steve may not want to recognize is that “not estimating” is a soft of null estimation technique and it’s often a valid choice.

7. Estimation and planning are not the same thing, and you can estimate things that you can’t plan.

Steve asserts that he can estimate chess games, because he can in principle have statistics on how long they take, and so on. He points out that this isn’t much use in estimating a particular chess game.

Similarly, knowing how long every project ever done, or any subset of them, isn’t much use in estimating how long the next project will take, unless a lot of things are true that often are not.

What Steve misses here is that Agile projects are not about estimation, nor are they about planning. Let me emphasize that: Agile projects are not about planning. Agile projects are about steering, choosing the next valuable things to do based on everything that has gone before, right up until yesterday.

This is really a different way of doing software, and it turns all the things we thought we knew on their heads. In particular, Agile projects make conventional estimation, and conventional planning, far less valuable.

8. You can estimate what you don’t know, up to a point.

Sure, you can, up to a point. The question is why would you? The Agile #NoEstimates approach is to do the thing incrementally and have useful facts, and valuable software, in hand, instead of estimating and having, well, estimates in hand, which are neither true nor particularly valuable.

9. Both estimation and control are needed to achieve predictability.

I might be willing to posit this for purposes of discussion, though I would also bet that I can demonstrate predictability without any discernible form of the kind of estimation people are offering as substitutes for #NoEstimates.

Now we need to ask whether predictability is something that we always want. Perhaps it is, but when you have a real, working product in hand every two weeks, the kind of estimation you need is again quite different from the kind estimation supporters typically offer.

10. People use the word “estimate” sloppily.

Yes. That has happened in the theses we’re reading here, as well as in all that has gone before. Despite calling for clearer definitions in an earlier article in this series, crisp definitions have not been forthcoming, even in these exchanges, much less in the world at large.

That’s how language works. Even if we wish words all had nice neat definitions, in practice they do not. We have to learn to deal with it.

11. Good project-level estimation depends on good requirements, and average requirements skills are about as bad as average estimation skills.

Yes, certainly if you don’t know what you want you can’t estimate it. I would leave out the judgmental assessment of the skills of people we don’t know. Unless I were selling skills training. Except that I am, and I prefer even then to sell a different way.

12. The typical estimation context involves moderate volatility and a moderate levels of unknowns.

Unless this is the definition of “typical”, it begs the question, as well as making us wonder just what “moderate” means. I’m not sure how this is helping us.

13. Responding to change over following a plan does not imply not having a plan.

Sure. Steve now educates us on what the Agile Manifesto means, specifically telling us that because it says “over following a plan”, it means we have to value planning. Perhaps. I’m inclined to think, having been there and all, that we did not have an irreducible minimum of planning in mind.

A very interesting question is how little planning one can do and thereby improve. There’s clearly a curve of some kind. How close to zero is the optimum? What kinds of projects work best with very little planning, or with only short-range planning, or other forms of limited planning.

14. Scrum provides better support for estimation than waterfall ever did, and there does not have to be a trade off between agility and predictability.

Maybe Scrum does that, in the sense that it provides real software to look at. There is little else in Scrum that helps with estimation.

As for a trade-off between agility and predictability, Steve is begging the question by assuming that predictability — whatever that means here — is something important, and that someone here is arguing that there should be a trade-off.

15. There are contexts where estimates provide little value.

Indeed.

16. This is not religion. We need to get more technical and economic about software discussions.

Objection: pejorative. Discussions do benefit from technical and economic aspects. There is no line whereby reducing those concerns below the line results in “religion”. It’s not clear here just which “technical” and “economic” aspect are key and which ones are not.

In addition, a case can be made that value should be much greater than cost, or the effort’s not worth doing. Once we have high value items relative to cost, and approximately same-sized items (which can be produced without estimation), this changes both the need for technical and economic thinking, and the types of thinking that are needed.

See “Digression” below.

17. Agility plus predictability is better than agility alone.

Assumes that agility, whatever Steve means by that, is not in opposition to predictability, whatever is meant by that. Depending what we mean by words like “estimation” and “predictability”, it’s quite possible — I believe likely — that agility and predictability are in fact in at least partial conflict.

Digression

In his article, Steve makes the following assertions:

My company and I can train software professionals to become proficient in both requirements and estimation in about a week. In my experience most businesses place enough value on predictability that investing a week to make that option available provides a good ROI to the business. Note: this is about making the option available, not necessarily exercising the option on every project.

My company and I can also train software professionals to become proficient in a full complement of Scrum and other Agile technical practices in about a week. That produces a good ROI too. In any given case, I would recommend both sets of training. If I had to recommend only one or the other, sometimes I would recommend starting with the Agile practices. But I wouldn’t recommend stopping with them.

I’m at a loss for a polite introductory phrase for calling this claim into question, so I’ll move on to make my own points.

First of all, if all the ignorant people Steve mentions above could have been made proficient in “both requirements and estimation” in only a week, then I’d have expected that over their many years of working in software, they’d have picked up enough to be pretty good, unless they weren’t paying attention.

And they are paying attention: the #NoEstimates supporters are all long-time very competent developers, not some kind of mewling and puking infants.

When it comes to becoming proficient in “a full complement of Scrum and other Agile technical practices in about a week”, I’m pretty sure I know something about that. People need to be proficient in at least these techniques: Test-Driven Development, Acceptance Testing or ATDD, Refactoring, Continuous Integration. For real proficiency, they need to embrace simple design, which is mostly about letting go of fear.

Proficiency does not happen in a week.

No one becomes proficient in TDD in a week. No one becomes proficient in Acceptance Testing / ATDD in a week. No one becomes proficient in Refactoring in a week. No one becomes proficient in Continuous Integration in a week. Proficiency in any aspect of software development requires long periods of practice, learning and relearning, honing one’s skills. It is possible to gain rudimentary familiarity with the technical practices in about a week. It is flat impossible to gain proficiency.

Now what about proficiency in “both requirements and estimation”? Given the 35 items on Steve’s “Quick Reference”, I really think not.

Are these courses good, and valuable? I absolutely believe that they are, as strongly as I could until I take them. After taking them, I would fully expect to be even more certain that they are good and valuable.

Do they provide what would reasonably be called “proficiency”? I very much doubt it. Should you take those courses? If they seem interesting, you surely should. You should not expect to strut out of the classroom on Friday being all proficient.

Just marketing?

I was initially inclined to chalk this up to “just marketing”, but I have a larger concern that this kind of statement raises for me.

What if would-be Scrum/Agile educators truly believe that Agile and Scrum are just like regular good old software development that we’ve been doing for decades, except with some ScrumMasters and iterations and user stories added in? That would induce them to brush off their old training and courses, add in a few modules about Scrum or Agile, and teach something that’s mostly the same old stuff.

And what if Agile and Scrum are really different, really truly different from the way software used to be done? Then are these training and coaching offerings really leading teams forward into Agile and Scrum, or are they in fact holding them back, by deemphasizing the essential sea changes that Agile brings? That would be bad.

I’ve been in software development for over a half-century, and in Agile for just short of two decades. I studied software hard over that whole half century, learning and applying the then-current published approaches.

I’m here to tell you that Agile, done at all well, is different. It’s not old wine in new bottles.

This may be at the base of some of the objections and concerns raised about #NoEstimates. Possibly many of those objecting have not yet experienced what Agile is really all about. Possibly these people have a fundamental misunderstanding of what Agile Software Development really is.

Note Well: I am not saying that these people are bad. They’re good, competent, well-meaning people, as honest as they know how to be. They just don’t get it.

That’s what I’d bet. I don’t know what to do about it.