I joined a Twitter conversation involving Peter Kretzman and [Glen Alleman], regarding the complex and continuing “#NoEstimates” ideas. You might want to review their thoughts at Peter’s summary, (be sure to read the earlier articles linked to by his summary), and Glen.
I think it’s fair to say that both Peter and Glen are adamant that estimates are a good thing, that they are the professional thing to do, and so on. It seems to me that they think one can’t do without them, at least not without harm. Peter, in a tweet, characterized his writings as arguing for “balance and reason and open consideration of pros and cons”. I note that his summary article is entitled “The Case Against NoEstimates”, and begins:
I’ve now methodically presented the case against #NoEstimates in three different lights: from a common sense standpoint, from the perspective of the solid reasons why estimates are useful, and by examining the various frequent talking points used by NoEstimates advocates. Looked at from any of these angles, NoEstimates comes up way short on both its core ideas and business practicality.
His material is quite clear, though I see in it more criticism than I do open consideration. One might think I’m overly defensive, but since I’m at best a part-time supporter of #NoEstimates, I think that unlikely.
It’s also worth noting that a fair number of other practitioners are reporting reducing estimates, or skipping some kinds of estimates entirely, and getting good results.
The arguments from Peter and Glen seem to me to have these main components:
- We use estimates and use them well.
- Our customers require estimates.
- The principles of our SDLCs require them.
That’s all good stuff. All the #NoEstimates people I know say explicitly that if you have to provide estimates, provide them. (It would be pretty silly not to.) Most would also go on to suggest that one explore whether estimation could be reduced. Far from being a mortal sin against SDLC, this seems to me to be a question one would ask continually about every element of one’s process: Is this bit right here bearing its weight? Is it strong enough? Could we do as well, or better, with some other process element?
What is surprising to me from these two gentlemen, and a very few others, is the intensity of their reaction, as if they, or the fabric of the universe, are somehow threatened by people who are trying reduced estimation and reporting good results. If I were in the large-scale software business, where estimation is essentially required, I might be glad if my competition were bad at it.
Naturally, like everyone else, Peter and Glen are trying to help, and giving the best advice that they have. What is striking is the form of the arguments on both sides. On the one hand, we mostly have “We’re trying this and having good results, you might want to try it as well,” and on the other we have “We’re not trying it, it would be unprofessional not to do estimates, and besides, we’re good at it,” together with what reads to me as denigration and condemnation of those who are trying it.
If I recall the Agile Manifesto, and I do, we said “We are uncovering better ways of developing software by doing it and helping others do it.” I’m rather delighted to hear the different and potentially better ways of doing things that continue to come from the community. I find some of the things people report to be frankly incredible. My practice, as well as I can manage, is to try to explore with them what they’re doing, what they observe, and to try to figure out how, why, and when, their idea might work.
I’m not perfect at that, but I do try. I ask probing questions that often turn out to be difficult. Sometimes they are even interpreted as opposition. But I’ve been seeking better ways to do software since I started over half a century ago, and I don’t plan to stop.
I recommend that you keep seeking as well.