The reason time planning doesn't work for most teams is not neatly broken down into two points as in TFA. There are way more than two points. Consider confounding factors like computer/power outages, windows updates, bugs in upstream, developers' personal lives, etc etc etc. One hung over developer day, poorly timed, can add weeks to your project. To accurately predict a team development process you would need Chaos Theory level of mathematics (and foreknowledge of variables). Asking developers to guess time values for tickets and adding them up does not cut it.
OR you handle it the way casinos do, using the law of large numbers[1] to make extremely accurate predictions over many consistently-produced values. There's a good reason why every single formal study on estimation, and every single agile framework has come up with abstracted estimation units and the same velocity calculations. A mature estimation process, run for a month or two, will give you medium- and long-term estimates that are at least within 5% of reality - that's perfectly useful for long-range planning. So the first half of the article is simply showing off that the author has never learned about professional estimation processes. Fair enough, most developers haven't.
Others have already pointed out in this thread that the purpose of long range planning is to indicate what we expect comes next. TFA acknowledges this as a good use of long-range planning.
There is one good remark in there, however:
> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget; it doesn’t matter how useless or broken those features are.
As an organizational principle this is exactly correct. By all means use long-range plans, and adapt them as the situation changes. But don't build a rewards scheme around them!
OR you handle it the way casinos do, using the law of large numbers[1] to make extremely accurate predictions over many consistently-produced values. There's a good reason why every single formal study on estimation, and every single agile framework has come up with abstracted estimation units and the same velocity calculations. A mature estimation process, run for a month or two, will give you medium- and long-term estimates that are at least within 5% of reality - that's perfectly useful for long-range planning. So the first half of the article is simply showing off that the author has never learned about professional estimation processes. Fair enough, most developers haven't.
Others have already pointed out in this thread that the purpose of long range planning is to indicate what we expect comes next. TFA acknowledges this as a good use of long-range planning.
There is one good remark in there, however:
> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget; it doesn’t matter how useless or broken those features are.
As an organizational principle this is exactly correct. By all means use long-range plans, and adapt them as the situation changes. But don't build a rewards scheme around them!
[1] https://en.wikipedia.org/wiki/Law_of_large_numbers