According to Ron Jeffries, estimation—as it is usually practiced—is "evil."a After making allowance for the hyperbole in the title (which does encourage people to read one’s article) Jeffries makes the case that agile teams are often "excessively concerned" with estimating the work they need to do. More correctly, these are the "undistinguished" agile teams that may have achieved some improvement in performance due the adoption of agile, but have not fully achieved their potential, whatever that is. And estimating their work is getting in the way of this progress. But is this true?
The record of the business of software living up its promises, or promises made on its behalf, is generally considered to be poor. Software development has been accused of being too slow, too error-prone, and too costly. Though as Tom DeMarco observed in Why Does Software Cost So Much?2 we might reasonably ask: compared to what? If software were truly too expensive wouldn’t market forces have replaced it with something else?
Of course, everyone wants software development to be quicker, less expensive, and higher quality while requiring fewer people. Such expectations of improvement are quite reasonable. But expectations of accountability of software developers are also reasonable and, like it or not, companies will require it.
Some proponents of agile take the view that the approach is so radically different from other development methods that certain practices, including estimation, no longer apply or are pernicious. I think that underlying this view are some misunderstandings about the nature of software, estimation, and the approaches themselves.
Requirements vs. Estimation
The classic "Waterfall" life cycle approach tends to be an object of ridicule these days. This is usually coupled with distaste for Big Process Up-Front where Process is requirements, design or, well, process. This approach is considered old and it is. However, even in the ancient waterfall days, very few projects could or did legitimately predefine 100% of their requirements and design prior to building something. Projects that did not flex with changing requirements were not successful as much then as now. That said, the waterfall model was never really a way of working. It was not so much a development model as a management model that allowed a simplified basis on which to track projects. Work was rarely if ever finished on an unambiguous date, while most requirements might have been defined up front others were identified in later phases, and necessary reworking occurred throughout the life cycle all of which contradict the naive model assumptions.
Estimates are always uncertain; uncertainty is baked into the very definition of the word.
While 100% defining requirements up front would be nice, it is not necessary either to build a system or to estimate it. Some agilists’ negative reaction to the practice of estimation might be simply a misplaced allergy to fixed-requirements-up-front, as if both estimates and requirements act as constraints. Estimates are always uncertain; uncertainty is baked into the very definition of the word. Estimates are not values—they are ranges of uncertainty. The extent to which requirements are uncertain is about the same extent to which an estimate is uncertain. This is pretty intuitive: If we do not know what we want to do we cannot expect to figure out precisely how long it will take or what it will cost. But if we do not have a baseline of some expectations we will not even know where we are or where we are going. In addition, there is a disconnect between the business and the development activity.
Workflow vs. Resourcing
This is a major source of misunderstanding between agile practitioners and management. Much of the agile approach really concerns detailed workflow planning: how to decide what to do over the next few increments of time and how to generate the most value in that time. This is very good. But the resources allocated to the project to be used over these increments of time come from somewhere. Someone is in charge of them and is accountable to the company for them. And this person wants to know how many resources will be required and what the return will be. One of the jobs of estimation is to generate the information that will allow this calculation. Companies will not and should not relinquish this accountability requirement. When the budgetary cycles for capitalized projects extend over a year or many years this calculation will be, and must be, done up front. It will not be precise simply because it is an estimate, but it must be done.
Note that I referenced capitalized projects. Many system maintenance organizations operate on an expensed basis. These organizations typically use a workflow throttling approach—they collect all of the system changes that are required and requested, they prioritize them according to urgency or value and they accept and tackle only as much work as they can do. When priorities and urgency change, what they choose to work on changes too. They are agile and they have been that way forever. But they are allowed to be because their budgetary cycle is continuous and expensed. Much of the conflict between resource management expectations and agile developer desires comes from this difference in the budgetary resourcing cycle. Another conflict comes simply from misunderstanding the nature of estimates and commitments.
Estimation vs. Commitment
These are not the same, though in many organizations the difference is not recognized. An estimate is an uncertainty range, but we cannot commit to an uncertainty. We must tell the customer some date and we must budget some amount. So we need to turn an uncertain estimate range into a certain value. This value is the commitment.1
The commitment is the estimate PLUS a calculated reserve needed to pay for the risk inherent in the situation. Projects that have poorly defined requirements, whether due to market forces, customer uncertainty, or even low project skills, take on more risk and require more resources. A key diagnostic that risk is not being considered is when I hear people being instructed to "take out the fat" from an estimate. The word is loaded. It implies surplus unnecessary resources have been added (as indeed they might have been if people expect to be unjustly punished for the inherent risk). If we reframed the command to "take out the resources needed to deal with risk" we would be closer to reality. Projects that do this are fine—as long as the risk does not actually happen. When it does, and the project cannot recover because it does not have the necessary resources, it means we did not accurately calculate the commitment.
We do not need an accurate estimate as much as we need an accurate commitment.
Return and Cost Plus Risk
The commitment is (should be) the risk-weighted cost of the project. That is, the cost of the project plus the cost of risk. Both values are estimates and both values are uncertain, but they are essential to making good business decisions. On the other side of the equation, we should also calculate the risk-weighted value from this project and calculate the risk-weighted return, but that is topic for another time.
Any Road Will Do
Agile projects, like all projects, need to have some target end state toward which they can work and estimation is one of the business management elements of that. This does not mean that some work cannot go ahead—funding and building a prototype is an entirely appropriate way of both defining requirements and creating an estimate (though usually not a system). Without an up-front estimation process of some sort we would not have a clue about whether we should run a project at all, irrespective of whether we choose to run it as an agile project or something else. True, we may not be able to completely define the requirements up-front and in most cases we probably should not try. But without the guidance given by a well-managed estimation process and the explicit risk resourcing that produces a feasible commitment, companies would need to stock up on their supply of blank checks. We still need to estimate. Estimation is not evil. When done properly estimation is good.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment