My coverage of the panel discussion on how to get beyond project estimates at Agile2013 Nashville garnered a great deal of positive feedback. There was one recurring question, though \u2014 Where do we start? \u2014 and another common refrain \u2014 "My boss would never go for that.\nThis article will answer the question and provide at least a few hints for conquering the boss' lament.\nNoEstimates Means Estimates Aren't Bad, Just Not Essential\nWoody Zuill, a development manager at Hunter Industries, introduced the #NoEstimates Twitter hashtag and addressed the concept in blog posts such as If you found estimates have no value, what would you do? Zuill is quick to point out that, while he has experienced some success with the ideas at Hunter, they represent his own opinion. That might be wise, considering the large public pushback on the idea.\nThat pushback may be due to a misunderstanding. Zuill didn't claim that estimates are "bad" in all cases; rather, they're not always essential to the software development process. Alternative decision-making approaches are possible. In other words, while estimates solve a problem, what problem do they solve, exactly? What other ways are there to solve the problem? That's the discussion Zuill wanted to start.\nInstead of arguing can\/cannot, let's define estimates and look at some examples of where #NoEstimates is working, in the field, right now.\nFor the purpose of this article, an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques.\nWe'll define #NoEstimates as running a software project without any human estimation process. If customers asks, "How long will it take?" that's estimating. If they never have to ask, that's #NoEstimates.\nNotice that this means we can still estimate the budget for the department, or the rate of customer adoption to do financial projects. The term #NoEstimates is specifically tied to humans using their judgment to predict development effort for a solution that have not yet fully developed.\nHere are five ways to do just that.\n1. Make Starting Amount of Money Small; Deliver Working Software Often\nJ.B. Rainsberger, the author of jUnit Recipes, points out that his first solo software project was just like this. Rainsberger made no promises up front, offering instead to show working software every two weeks \u2014 and also allowing the client to fire him with as little as two weeks' notice.\nThis technique may work best for outsourced projects. It also represents a significant amount of risk for the outsourced company, and minimizes risk for the customer. The team turns over working software \u2014 not designs, specifications or in-process code \u2014 that may have little or no value to the economic buyer.\nFor internal projects with an existing team, a larger organization might want to look at another approach to #NoEstimates.\n2. Fund a Pilot That Delivers Working Software; Then Use Modeling to Forecast Schedule\nImagine a high-functioning software team pulling pieces of work from a queue. If the effort involved for each piece of work averages within some reasonable deviation, the team can count the pieces of work accomplished per week and predict, in a sense, when the project will be done. (Management can also change which pieces of work are "required" to change the date.)\nThat may not be as easy as it sounds. To work, the amount of effort per feature needs to normalize, or approach a bell curve, and there can't be any "black swan" events lurking in the weeds. For example, bugs discovered late in the cycle may create extra work that's not modeled.\nThe team also needs a fair amount of data to do this kind of modeling. This typically requires a funded pilot with no defined scope. It might, however, be possible to pull the data from previous projects that were delivered with estimates \u2014 by throwing away the estimates and assembling predictions from data.\nTroy Magennis, a former executive at Sabre Holdings and Travelocity, now with Focused Objective, has done some of the most prominent work in this space. Magennis has also developed predictive models that include complex elements like deviation, cycle time, defects\/time for repair and so on.\nEven without a complex model, most agile teams are capable of producing a burn-down chart that can answer the question, "Is this date and this scope possible?" Someone just has to ask.\n3. Move From Contract Negotiation to Partnership\nThe Dynamic Systems Development Method, or DSDM, predates the agile movement. It recognized that, on most projects, people, money and time remain fixed. Quality is something that probably should be fixed, too, as non-working software doesn't actually work. The one thing most flexible is actually scope.\nMost planning work is eliminated here in favor of developing high-level goals in collaboration with the customer. The team promises to deliver something on week 30, and the two groups meet every week or two to show progress and design the next step.\nIf that sounds a bit like a fairy tale, I understand. At the same time, that's essentially the business model of Menlo Innovations. Based in Ann Arbor, Mich. and founded by Richard Sheridan, former VP of product development at Interface Systems, the Menlo team may establish scope at the outset of a project, but it lets the customer adjust and plan specifics each week.\nBy the end of a budget period, the customer could steer to a place very different that the original goal. The customer gets what it needs in the moment \u2014 not what it thought it needed six months ago.\nIn May 2003, Sheridan made the cover of Forbes for his successful gamble to found Menlo. In the 10 years since, the company has continued to grow. Sheridan's current project is a new book, Joy Inc.: How We Built a Workplace People Love. Menlo is doing something right.\n4. Employ Stop-and-Start Heuristics\nA great deal of portfolio management efforts consist of trying to figure out what projects will be done in what time, how many contractors or new hires are needed to make the timelines line up and that sort of work. Matt Barcomb, vice president of product development at Taxware, suggests that might be overthinking it.\nAccording to Barcomb, most IT organizations can usually figure out what they should be working on right now. If the team can develop rules of thumb, or heuristics, around when to stop and when to adjust, it doesn't need that kind of heavyweight scheduling. Just work on projects until they don't make sense, then change gears. This might make long-term predictions challenging \u2014 but if you look back over your team's last five-year plan, how accurate was it, anyway?\n5. Drop Estimation From Your Development Process Entirely\nIf your organization makes enough money to run itself, and if you view time spent estimating as time not developing, then you might abandon estimates and just write code. This approach is extremely tempting for products that charge a per-user, per-month fee that are already cash-flow positive. (We used this method for some time when I belonged to the technical staff at Socialtext.)\nThe approach isn't limited to profitable Web startups. John Carmack, CEO of Id Software, is famous for the expression "it's done when it's done," so much so that the phrase appears under Carmack's name on WikiQuote. Id created the wildly popular games Quake, Doom, and Duke Nukem.\nThe common objection to this is governance \u2014 that Carmack owns the company and can therefore do what he wants \u2014 but publicly traded organizations need to give advice to shareholders and the board on projects.\nIt's worth noting that Apple, one of the largest publicly traded organizations in the world, stays secretive about upcoming products. Meanwhile, Intel refuses to make quarterly earnings estimates for shareholders or Wall Street. It doesn't seem to be hurting them.\nNoEstimates Really About Solving Problems a Different Way\n"My boss would never go for that" may sound like an invitation for dialogue, but it's actually a fiat. Any further conversation boils down to "would not, would too" \u2014 and that's not a helpful. Clearly, many software customers want estimates. In many cases, those are reasonable.\nTurning the conversation a bit, here's the next logical question: What problems do estimates solve, and can we solve them a different way?\nHow-to: 14 Proven Ways to Connect With Customers\nThis has been done before; it reminds of Henry Ford's famous claim that if he'd asked his customers what they wanted, they would've told him faster horses.\nThe line is usually used to dismiss customer concerns, but let me suggest a different idea. Ford's customers were telling him exactly what he needed. If Ford had applied the 5 whys technique to that request for faster horses \u2014 driving in to what the customer really needed \u2014 he may just have found the automobile.\nIt's the same with estimates. If we apply "Why?" for estimates, we can drive down into needs such as planning and funding decisions. All the examples above are innovative environments where the technical staff found a way to provide for those needs in a different way.\nThat conversation can lead to answers such as "It's a lot of money to us" and "We want to reduce our risk." These are things the team can work on. Estimates might not go away, but the focus on estimates, and the amount of time and effort involved, might decrease. This means more time and energy can be spent actually building and testing software.\nWouldn't that be nice?\nMatthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.