> If it ends up taking 20 hours, oh well - good to know for
> next time!
If a project is adding real productive value to the business there won't be a next time as the tasks should be intrinsically unique. A non-unique task suggests either poor product strategy, poor architecture, or that there's a pre-existing package or product that you should be using instead of recreating the wheel. At best, unavoidable repetition signals deficiencies in the state-of-the-art (e.g. overall Linux or Windows ecosystem), but those are rarely the sorts of tasks where you see trouble communicating or planning.
> The idea is not to bicker over whether something will take
> 3 hours or 5 hours or 7 hours, but to just slap a vague
> label on it as "low-to-moderate difficulty." It's supposed
> to save time in that regard.
The purpose of scoring is to enhance the precision of time management. Theoretically, you should be bickering over details! The point is to reliably track so-called velocity with increasing precision to assist executives with product planning and orchestration of resources. But as I mentioned above, if you're doing anything of real value you're constantly creating unique solutions to unique problems. Those solutions and problems should constitute the bulk of your effort. As you suggest, your scoring necessarily must be uncertain and imprecise to be accurate and reliable, at least when you're attacking worthwhile problems. But that's completely at odds with the function and aim of scoring in Agile, which is to achieve increasing precision.
Agile methodologies come from the world of industrial automation where you're trying to refine the process of building millions of identical widgets with designs that evolve relatively slowly. Increased precision in resource management (e.g. real-time inventory management) allows managers to squeeze more profit out of the product without any additional expenditures. It's one of the rare management tools where they can uniquely add measurable value. But repetition and slow evolution is pretty much the complete opposite of what you should see from an efficient and capable programming team. At best, something like SCRUM routinizes poor value-add. Agile isn't a recipe for success, it's a recipe for making failure more efficient. (Not the experimental, knowledge-building definition of failure.)
In the context of software, Agile tries to achieve the impossible, which is to mechanize innovation. It's fundamentally broken. If you cherry pick aspects of SCRUM (or any particular Agile methodology) it's no longer SCRUM, nor is it novel. At best the Agile fad has introduced more programmers to, e.g., unit testing. But Agile is neither necessary nor sufficient to adopt unit testing; nor is unit testing always the most efficient use of time, especially when formal verification is practical. And while fast iteration is ultimately what you want to achieve, again the point of fast iteration is remove as much repetition and wasted effort (e.g. orchestration latency) as possible. If you're iterating fast, you're spending less time on tasks that are easily articulable, let alone predictable, and thus not amenable to fine-grained, precise time management. This is a consequence of the very purpose of software programming--to shift tasks that exhibit regularity to the domain of computers.
As for me, I left my previous job the moment people started complaining that our velocity was "too fast"; that (I kid you not) we should slow down the pace of work on a big, high-priority project in a futile and misguided attempt to make our time management more predictable (like the more junior teams), oblivious to the tensions between accuracy and precision and to the fact that the inaccuracy of our overly precise scoring was actually evidence (especially in light of other evidence) that we were working particularly efficiently.
As far as I understand, my prediction about when the project would wrap up if my preferred strategy (for which I was effectively the deciding vote) wasn't followed was accurate nearly down to the week, for a project that was supposed to take 3-4 months but ended up taking 9 and which was supposedly the highest priority for the entire (NYSE-listed) company. It easily could have taken 3-4 months if some of the engineers didn't approach time management through the lens of Agile development. They would have been more tolerant of the predictive errors for the easy tasks and more suspicious of the estimates for the more complex tasks, many of which were backloaded in this particular context. The lens of SCRUM in particular and Agile more generally primed them to equivocate tasks; to see similarity and repetition where there wasn't any.
Agile methodologies come from the world of industrial automation where you're trying to refine the process of building millions of identical widgets with designs that evolve relatively slowly. Increased precision in resource management (e.g. real-time inventory management) allows managers to squeeze more profit out of the product without any additional expenditures. It's one of the rare management tools where they can uniquely add measurable value. But repetition and slow evolution is pretty much the complete opposite of what you should see from an efficient and capable programming team. At best, something like SCRUM routinizes poor value-add. Agile isn't a recipe for success, it's a recipe for making failure more efficient. (Not the experimental, knowledge-building definition of failure.)
In the context of software, Agile tries to achieve the impossible, which is to mechanize innovation. It's fundamentally broken. If you cherry pick aspects of SCRUM (or any particular Agile methodology) it's no longer SCRUM, nor is it novel. At best the Agile fad has introduced more programmers to, e.g., unit testing. But Agile is neither necessary nor sufficient to adopt unit testing; nor is unit testing always the most efficient use of time, especially when formal verification is practical. And while fast iteration is ultimately what you want to achieve, again the point of fast iteration is remove as much repetition and wasted effort (e.g. orchestration latency) as possible. If you're iterating fast, you're spending less time on tasks that are easily articulable, let alone predictable, and thus not amenable to fine-grained, precise time management. This is a consequence of the very purpose of software programming--to shift tasks that exhibit regularity to the domain of computers.
As for me, I left my previous job the moment people started complaining that our velocity was "too fast"; that (I kid you not) we should slow down the pace of work on a big, high-priority project in a futile and misguided attempt to make our time management more predictable (like the more junior teams), oblivious to the tensions between accuracy and precision and to the fact that the inaccuracy of our overly precise scoring was actually evidence (especially in light of other evidence) that we were working particularly efficiently.
As far as I understand, my prediction about when the project would wrap up if my preferred strategy (for which I was effectively the deciding vote) wasn't followed was accurate nearly down to the week, for a project that was supposed to take 3-4 months but ended up taking 9 and which was supposedly the highest priority for the entire (NYSE-listed) company. It easily could have taken 3-4 months if some of the engineers didn't approach time management through the lens of Agile development. They would have been more tolerant of the predictive errors for the easy tasks and more suspicious of the estimates for the more complex tasks, many of which were backloaded in this particular context. The lens of SCRUM in particular and Agile more generally primed them to equivocate tasks; to see similarity and repetition where there wasn't any.