This 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 - not designs, specifications or in-process code - that may have little or no value to the economic buyer.
This is essentially what happened with Chrysler's Comprehensive Compensation System (C3). The car maker dropped the existing project, already in progress, in order to "reboot" it as a project that would deliver working software every two or three iterations, each of which was two weeks long. For Chrysler, in 1999, that was a fast deployment process.
For internal projects with an existing team, a larger organization might want to look at another approach to #NoEstimates.
2. Fund a Pilot That Delivers Working Software; Then Use Modeling to Forecast Schedule
Imagine 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.)
That 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.
The 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 - by throwing away the estimates and assembling predictions from data.
Troy 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.
Even 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.
3. Move From Contract Negotiation to Partnership
The 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.
Sign up for CIO Asia eNewsletters.