Alert: 82% chance of pontification.
Canard 1: We desire exponential business growth
Assumptions: It takes about 5 people to produce 1 car; the production of an electric car results in about 30,000 pounds of carbon emissions (see this article).
The electric car company represented in the spreadsheet employs 500 people in its first year of operation to produce 100 vehicles, resulting in 3 million pounds of carbon emissions. In the fourth year of exponential growth, the company employs 10 quadrillion people to produce 50 quadrillion vehicles resulting in 300 sextillion pounds of carbon emissions. Sometime during year 7, the number of vehicles produced surpasses the Eddington Number (the number of protons in the universe).
Exponential growth…really? Really? Please don’t tell me you’re using the word "exponential" as a fancy term for "much." Words don’t mean what they don’t mean.
Canard 2: It’s desirable to maximize productivity
See this blog post for a more-complete rant on the subject. Please don’t tell me your personal definition of "productivity" includes factors such as "value" and so forth. Words don’t mean what they don’t mean.
Canard 3: We need to work faster! Faster! Faster!
Current norms in process cycle efficiency range from about 1% to about 5%, according to Ron Taylor, among others. That means we typically waste as much as 99% of the time we spend in creating a product, whether hard goods, services, or software. In my own consulting work, I usually see PCE of 1% to 2% for software development processes. (Yes, that includes "agile" and "lean" processes.) It’s possible to get this number up to 5% without changing the fundamental laws of nature. "Work faster" while continuing to do non-value-add activities is not the way.
Which do we really need to do: (a) Run faster on the same treadmill we’ve been on for the past X years, or (b) Stop doing things that don’t add value, so that more of our time is available for doing useful things?
Canard 4: We need to do a better job of estimating
What managers are really looking for when they ask for estimates is predictability. They need a way to forecast the likely delivery performance of their teams so that they can tell whether their projects are on track.
With contemporary software development methods, we can develop historical data from empirical observations of delivery performance. This is possible because we deliver results periodically throughout a development initiative, rather than delivering everything at once at the end. The data can be used to forecast future performance, within reasonable limits.
Cycle Time is a useful metric for the purpose. If you’re using a time-box process model in the strict sense, you can use Velocity in a similar way. Such forecasts are more accurate than any estimate.
You need accuracy. You don’t need precision. You don’t need to know which work package John Smith will be working on between 10:00 a.m. and 12:00 noon on Wednesday, 14 June 2286 AD. You do need a realistic idea of whether all 842 work packages in the project plan are likely to be completed by the target delivery date, give or take a bit.
Stop asking for better estimates. Start using better methods.