In a recent blog post, Woody Zuill – fellow blogger, fellow middle-aged software guy, and fellow banjo picker – gave his personal definition of the #NoEstimates Twitter hash tag that has been the venue for a lot of online discussion lately.

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development.  That is, ways to make decisions with “No Estimates”.

Woody and several others in the Twitterverse and Blogosphere have been advocating for making decisions (more accurately, applying constraints) that don’t require estimates, in order to eliminate the need to make other decisions that would require estimates.  Neil Killick recently posted an explanation of how to do Scrum without estimates, including this example:

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint).

Implicit in the example is that once time and schedule are fixed, only the scope is flexible.  While this would certainly make things easier for the software developers, it adds complexity for everyone else.  To explore Neil’s example, let’s assume that the Australian Open app is a public-facing, self-service web site where the general public can buy tickets, see the daily results, read and comment on the news coverage of the event, and possibly follow links to the personal web sites of the players.  But what else is involved in serving the public audience interested in the Open?  I ask because, in the real world, not all members of the public are going to use that web site.

Presumably, the Open will have a call center to handle inquiries and purchases from those who don’t find or can’t access the web site.  They may also have an interactive voice response (IVR) system to support certain kinds of queries and possibly even ticket purchases.  So the Decision Makers will want to make the Australian Open app fit into this operational framework, providing capabilities and services for the public that supplement or complement each other.  To do this, they need to have a firm list of capabilities (or scope) defined for each of the three projects – Call Center, IVR system, and web app.  That way, the can staff the Call Center appropriately, work with the marketers to provide instructions to people in directing them to the IVR or app, and otherwise direct user traffic.  But if the Call Center folks and IVR configuration team don’t know until three days before the Open starts what functionality the web app will have, that doesn’t leave them much time to react, do they?

Of course, it might be wise for the Decision Makers to conduct a “buy or build” analysis, since large events are quite common and have spawned a number of service offerings, including Software as a Service.  But in order to conduct that analysis, they would need a firm feature / capabilities list and cost estimate for the internal development effort, to compare it with the vendor offerings.  And if all the internal developers can commit to is cost and schedule, it makes comparisons impossible.

A group of frogs who live at the bottom of a well are enjoying their nightly chorus of croaking, when one of them announces that he is studying astronomy.  When he gets a quizzical look from one of his comrades, he explains that it is the study of the sky.  “You know: that little round thing at the top of the well.”

Complexity will persist in the face of all attempts to reduce it through simplifying assumptions.  Few modern business problems are simple enough to reduce to a small number of decisions, which then drive all other activity.  Apples falling out of trees are fine for explaining gravity to school children, but celestial mechanics has to contemplate multiple bodies.  Similarly, modern business problems are not simply about software.  And that is why we should devote our energies to improving the quality of our software development estimating methodologies, rather than advocating adoption of simplifying assumptions that don’t reflect a holistic view of the operating environment.