Myself when young did eagerly frequent
Doctor and Saint, and heard great argument
About it and about: but evermore
Came out by the same door where in I went.
– The Rubaiyat of Omar Khayyam
Steve McConnell and I have exchanged quite a few long emails as well as the web pages linked to in this series of articles. Our intention was to find agreement and mutual understanding around the #NoEstimates topic. We surely each desired to help the other to understand our own positions, and, I suspect, each had a bit of desire to convince the other that our positions were valid.
We did find places where we agree, and possibly each took on a bit of the other’s view, or at least understood it better and found it not entirely repugnant.
In the end, as the poem says, we each came out where we went in.
In the first version of this article, I combined discussion of where Steve and I agree or disagree with some arguments and conclusions supporting my side. In aid of brevity, clarity, and all things good, I’m dividing up that material.
Here, we’ll talk about our points of agreement and disagreement, with as little material supporting my side as I can manage. That will not be zero, I fear. My further conclusions can be found here.
I’ll try to characterize both positions accurately. If I get Steve’s wrong, I invite him to let me know and I’ll revise.1
✓ Sprint-Level estimates are unnecessary
I think we actually agreed that story-point estimates at the Sprint level could generally be replaced with story count, given small slicing. We seem to agree that estimating stories every Sprint is unnecessary.
✓ Scrum is good
Steve is perfectly happy having teams using Scrum, and even leans a bit that way. He’s comfortable if they don’t, as well.
✓ “Agile” practices are good
We have a general agreement that Scrum and “Agile” practices are good. We didn’t dig deeply into which ones, when, or just how they’d be done.
☒ Improve estimation or avoid it?
The core of our actual disagreement here is that Steve says repeatedly that if the customer wants estimates, they usually have legitimate reasons for estimates, and therefore we should give them estimates.
My view is, sure, they have reasons. Let’s dig closer to the root problem, and try to address the reasons directly, when we can, rather than reflexively assume the problem is poor estimates.
We’re pretty much stuck on these positions. We totally agree that customers have valid reasons for wanting estimates. He says “so give them estimates”. I find that we can often address those reasons more directly and productively than by providing estimates. Therefore I think a #NoEstimates person would do more exploring into what’s trying to be decided before offering estimates, and might often find something that more directly served the customer’s decisions.
☒ Change their approach, or get things done.
An important difference between Steve and me is in how we try to help people. Steve put it this way:
My business focus is to help my customers meet their business goals as they understand them. Lots of agile practices support goals in addition to agility, especially quality and – surprisingly – predictability. So I focus on the practices that help our customers achieve their goals. Sometimes our customers want agility per se, and a lot of times they don’t. It doesn’t really matter to me one way or the other. Like I’ve said, what I find interesting is fitness for purpose, so that’s what I focus on.
I have chosen, or accidentally fallen into, another line of work. I try to help people who are trying to change their model of work using “Agile” values, principles, practices, and methods. I think people and organizations will both be better off if they’re able to move more toward the values and principles that are the foundation of the “Agile” movement. I show them practices and approaches that are as consistent with those values and principles as I know. I find that when they more in that direction, they tend to perform better and to be happier in their work.
Am I trying to change the world? Sure, Steve and I are both trying to change the world. We both do it by teaching useful things that will improve people’s work lives and improve organizational performance. We simply approach that differently, with a different set of tools.
Steve could argue that he uses the tools of Agile, and other tools, as appropriate to the situation, or at least as appropriate to what the customer wants. Me, on the other hand, I’m a one-trick pony. Just this Agile stuff.2
I suppose I really am about changing the way software work is done. Kent Beck once said that he was just trying to make the world safe for programmers. To make the world safe for programmers, you have to make programming safe for the organization. That’s what I’m trying to do.
☒ Agile is not just the practices
Steve said that he believes “Agile” is defined by its practices, that the benefits come from the practices, and that it’s fine to adopt the practices without the values. I believe this to be a common, and very serious, misapprehension. You’ll get some value, but you’ll leave much more untouched.
Doing the practices without the values is a lot like practicing the piano because your mother tells you to, rather than for the love of playing and the desire to perform music well. Without the values, the practices become rote, and are likely to be dropped when the going gets touch. Without the values, you don’t know whether to improve some practice, or drop it.3 Without the values, dev and customer, or dev and management, are less likely to form a real team. Instead they continue in the Estimate-Commitment loop which Steve observes and rather explicitly supports. They are less likely to reach true collaboration.
Focus on practices but not values results in a style of development that looks a lot like decades before, with some Agile seasoning thrown in.
So a key difference between us is that I push much more strongly to instill the Manifesto’s values, not just the associated practices. Steve seems more inclined to support a more conventional style of development, observing accurately that most organizations don’t really want to change.
Now I’d like to comment on some snippets from my conversation with Steve, because they shine a bit of a light on our differences, and how we perceive things differently. Each of these is headed by a direct quote from Steve, unless I’ve screwed up.4
“Implementing Scrum doesn’t change human nature.”
Steve said this when we were talking about a Product Owner who kept wanting it all, and I was pointing out that Scrum holds the PO accountable for maximizing value by controlling scope. Steve’s point was that just because the PO was held more accountable, they’d still have wanted it all.
I agree that they’ll want it all. Part of their job is to want it all, as I point out in Nature and elsewhere. Their job as Product Owner is also to build a viable product by choosing what to do and what not to do. Slicing the work down is key to that, so that the best possible product can be built up incrementally, balancing all the feature areas.
Steve and I fully agree that clarifying the Product Owner’s accountability for results will not change their nature, and therefore they’ll not automagically change their ways if Scrum were actually being done as prescribed. We agree that the PO, even if in a real PO job instead of a fake one, will still need to learn about scope management. One way to do that is by providing estimates. Steve tends to think it’s the best way: I tend to prefer other ways.
We do agree that human nature, whatever that is, will not change, but I think it’s about behavior, not nature. Faced with personal failure or embarrassment if this product isn’t as good as it could be, every product owner will start seeing and responding to the responsibility, given that they have it. I think Kate Oneal’s work with Susan demonstrates quite well what happens: panic, thrashing, then seeing a way out, with help.
Scrum doesn’t change human nature, that’s true. Scrum does change human behavior.
“Teams don’t get estimates shoved down their throats, they get commitments shoved down their throats.”
We were talking here about the bad effects of estimation. Steve’s point was that the estimate wasn’t the problem, it was what was done with it. And he went on to say that if the estimate were better, and there were a history of better estimates, then managers wouldn’t use commitments to beat down estimates and push impossible expectations onto the team.
I am quite sure that better estimates will not substantially reduce bad behavior around the estimate-commitment axis. “Negotiating” estimates is deeply embedded into most cultures. It probably started in the marketplace in the village in ancient Greece, where the carrot guy tried to get three hemitetartemorions for his carrots, and your great-to-the-nth grandmother talked him down to one.
We assume that a contractor’s estimate has fat in it and we assume that we need tough negotiation to squeeze it out. The better the contractor is at estimating, the more this process hurts him, because he has nothing left to squeeze. And in the end, it hurts the buyer as well: the only way the contractor has to survive is to cut quality.
Seen any high-defect hard-to-maintain code lately? This right here is how you get high-defect hard-to-maintain code.
“Commitments are here to stay: good estimation supports the commitment process.”
Here we continued the discussion about the vicious Estimate-Commitment cycle.
It’s true that better estimation will help, if you’re going to do estimation. As I suggest above, I think better estimation won’t quickly fix the forced over-commitment problem. I’m not sure it will fix it at all.
#NoEstimates seeks to break the vicious cycle of estimation and commitment, leading to a team-based model instead. Learning better ways to estimate supports the Estimate-Commitment model and can actually increase the danger of building tomorrow’s legacy code today, until managers unlearn negative commitment-based approaches. And there’s no incentive to learn that.
By pushing hard against even perfect estimates, managers look tough, they reduce vendor expenditures, and when things go bad they get to blame the vendor. This works whether the vendor is external or your own dev team.
Even good estimation preserves a vicious cycle in the hope that it will heal. #NoEstimates is trying to break the cycle. When it’s possible, breaking a vicious cycle is better.
My follow-up article will address the role of #NoEstimates in breaking that cycle.
Summing up the summing up
Steve and I managed to stay quite civil, even though we have some pretty serious and deep disagreements. I credit him for this, since I am known to be an arrogant irritating jerk.5
Part of civility is in recognizing that the other person is not evil just because they don’t happen to believe in your particular form of magic. Everyone is trying to get good things to happen, using the tools they prefer from the set of tools they have.
It helps, also, that Steve and I both believe that the more you know, the higher your skills, the better you’re likely to do. I’d be happy to have at my fingertips all the knowledge of estimation (and many other topics) that Steve has. And if I knew anything useful that he did not, I’m sure he’d like to know it as well.
This doesn’t mean that I’m going to drill deeply into estimation: I have things to think about that matter more to me. All of us have to decide where to put our effort in learning. If you think better estimation will help you, then look to Steve’s books, or to Mike Cohn’s, or even back at Planning Extreme Programming. These books all take different approaches, but good approaches, to improving estimation and planning.
If you want to take a look at how I think software development should really be done, try The Nature of Software Development. It even has pictures.6 And please buy it through PragProg: I might get a bit of a royalty that way.
The #NoEstimates people are exploring alternatives. They’re asking: “If we didn’t get better at estimation, but instead reduced our reliance on it, what other good things might happen?””
I think that’s a very interesting and powerful question. That’s why I’ve written so many articles about it so far: I’m trying to make sense out of it. I hope you’ve enjoyed reading along.
Got more energy? My follow-up article addresses the role of #NoEstimates in breaking that cycle.
Notes of the Foot:
Done and done. I’ve updated in response to a note from Steve, to better reflect his views. ↩
Well, I think of it as a half-century of experience doing software in nearly every known way, culminating in two decades of learning and doing “Agile”. Or maybe unlearning all that heavy stuff that too often gets in the way. ↩
It would be unwise to rule out this possibility. ↩
I can provide evidence if any is needed. ↩
I was going to say “pretty pictures”, but I drew them. Anyway, they are pictures. ↩