I came across the following article by Tom DeMarco via the Coding Horror blog:
The paragraph that stands out for me is as follows:
To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?
As I interpret it, the core message from the article is that if you have a recurring strong need for cost control and accurate estimation on software development activities, then a more pragmatic approach is to question the choice of software development projects. Software Development estimation is notoriously difficult to get right. Anyone who disagrees with that statement is likely to be in a position where either they don’t have to live with the results of their software estimates or is in a cushy position where they can afford to over-estimate consistently.
Have a read of the DeMarco article. In particular, the comparison of Project A and Project B provides the core message for me. One of the aspects of “controlling” a software development project is to establish an estimate up front so you have a baseline to guide the control activities. As the Chief Developer at Torq Software, the question of software development estimates comes up regularly. I’m leaning more and more towards reducing the need for estimation from the process where-ever practical.
Yes this may sound like crazy talk, but the emphasis is on the “where-ever practical”. Businesses still need to estimates to be able to plan, but the message of the DeMarco article is to focus on high return software development activities so that the variability inherent in the software development process is less of an issue. If you accept that a process is highly variable by its very nature, you’re more likely to be able to “control” it using methods appropriate to the context. We can reduce the need for Estimation by moving to a more “pull” oriented approach to planning and concentrating on high value activities. High value in this context is whatever is valued to the business in question.
This focus on the reducing the need for estimation is based on the view that the Estimation is a form of “waste” in the context of software development. Estimation work doesn’t directly help getting valued software at the hands of the user. The Estimation process can be viewed as a form of waste when taking a Lean Software Development perspective. In their book on Lean Software Development, Mary and Tom Poppendieck reinterpret the “Seven Wastes” of Lean Manufacturing in the context of Software Development. Estimation work fits in the category of “Extra Processes”.
| Manufacturing Waste | Software Development Waste |
|---|---|
| Inventory | Partially Done Work |
| Extra Processing | Extra Processes |
| Overproduction | Extra Features |
| Transportation | Handoffs |
| Waiting | Delays/Waiting |
| Motion | Task Switching |
| Defects | Defects |