#NoEstimates
I’ve been reading and writing about #NoEstimates for over a year… Along the way, I’ve found some great people with some great thoughts with opinions and experience both for, and against. I’ve worked on projects which have been estimated and planned up front, projects which have been estimated but no detail plan completed up front, and projects where the work has just started. I’ve had successful projects delivered in all of those contexts (on time, on scope, on budget, to the satisfaction of all stakeholders – NPS > 80, for example).
What strikes me is that throughout all of the discussions, primarily on Twitter (which is possibly the worst place to have a complex discussion of ideas), is that there remains an Us-vs-Them mentality. Both by those in the #NoEstimates camp, and by those in the No #NoEstimates camp.
In my experience which I’m sure won’t apply in every situation, when the business and engineering teams work together — and really mean together — I’ve seen the need for estimates diminish very quickly. The need for up-front planning diminishes. The opportunity to find solutions to problems is amplified, and the solutions are beyond what was asked for, or imagined, when the project started and there was minimal knowledge.
One of the arguments that bothers me the most is when I hear “you’re being irresponsible with other people’s money”. Or something along those lines. I don’t view it that way. It’s not us and them. It’s all our money, and we need to figure out how to spend it together. We need to be working together, with a shared understanding from all perspectives, instead of being responsible for simply implementing what someone else decides we’re going to do. My point is that it’s not your money and we deliver something. We’re all in it together. The developers, testers, release engineers, DevOps, BAs, CIOs. And everyone else.
When teams eliminate the Us & Them way of thinking, collaboration happens, trust develops, and new ways of thinking about projects, products, and problem solving can emerge. The way we’ve done things for decades no longer applies.
If, ten years ago, I told you that we could release to production on an hourly, daily, weekly basis, there are those who would have screamed bloody murder! How could you possibly release without a month of hardening? Where’s the smoke testing? What about time for UAT – how could we be sure the business would accept what had been developed? How irresponsible would this be? How could you be such a cowboy with other people’s money, putting that code into production? Hell, it used to take days or weeks, if not months in some cases, just to get the hardware up and running. That’s no longer the case. In ten years from now, I wonder if we’ll look back on estimates the same way.
I’m not sure if estimates can be eliminated entirely. But either way, I’m not going to stop exploring options and discussing alternatives.
Just as an aside, one of the projects I’d say was my most successful, personally, was a small ~$450K fixed-price, variable-scope project. We delivered it with significantly more functionality that had originally been discussed, about 20% under budget, and about 22% ahead of schedule. The client who paid for it was beyond thrilled. We worked our asses off, but never really put in any overtime – yeah, an hour here or there, but then we also took time off along the way. We understood the objective. We worked together to achieve that objective. And, we estimated nothing.