4 ms·

Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at

Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. - It's possible to estimate how long those tasks will take to complete. Any team I've ever seen who claims to do well with both of the above points either had massive sandbagging problems, sometimes openly acknowledged by everyone, and often failed to deliver the best solution they could due to the rigidity of their project plan and the political consequences of straying from it. Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else.

bitwize 9y ago
> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: > - It's possible to know what tasks are required to complete a project at the outset of a project. Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. > - It's possible to estimate how long those tasks will take to complete. This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time.
- ryanbrunner 9y ago
  > Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. Fair enough on the level of a sprint. In my experience, management and stakeholders rarely care about a sprint, they care about the project as a whole. And again, in my experience, the accuracy of estimates falls off precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad estimates or lock down your plans to a degree that will hurt the success of your project (by not taking into account learnings as you build). > This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time. This would be true if estimates had high precision, but low accuracy (i.e. developer A consistently overestimates, and developer B consistently underestimates). In my experience, the opposite is more true than not - developers have relatively well tuned accuracy, but horrible precision. If everything goes according to plan, developers can estimate that fairly well. It's the amount of times things don't go according to plan that's the problem.
fmihaila 9y ago
> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. At some point though, once you've decided what tasks to work on, how much they cost (in time, dollars, risk, etc.) is a very important question. The answers will always be guesses, but tracking what actually happens over time helps to improve future guesses. > - It's possible to estimate how long those tasks will take to complete. One cannot eliminate all uncertainty, but it is possible to decrease it over time. A way to do this that I found works well is to look for past tasks that are sufficiently similar in size and complexity to the one being estimated and use the tracked data to anchor the new guess. You track as you go in order to build this log. I should emphasize that I think this data should be there to help developers improve their estimating abilities, and not for the management to judge developer performance. > Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else. Very true. However, never measuring or logging anything out of a desire to avoid the things you've enumerated can deprive a team of valuable information and lead to missed learning opportunities. The trick is to find the right balance.

bitwize 9y ago

> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: > - It's possible to know what tasks are required to complete a project at the outset of a project. Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. > - It's possible to estimate how long those tasks will take to complete. This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time.

ryanbrunner 9y ago
> Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. Fair enough on the level of a sprint. In my experience, management and stakeholders rarely care about a sprint, they care about the project as a whole. And again, in my experience, the accuracy of estimates falls off precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad estimates or lock down your plans to a degree that will hurt the success of your project (by not taking into account learnings as you build). > This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time. This would be true if estimates had high precision, but low accuracy (i.e. developer A consistently overestimates, and developer B consistently underestimates). In my experience, the opposite is more true than not - developers have relatively well tuned accuracy, but horrible precision. If everything goes according to plan, developers can estimate that fairly well. It's the amount of times things don't go according to plan that's the problem.

fmihaila 9y ago

> Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. At some point though, once you've decided what tasks to work on, how much they cost (in time, dollars, risk, etc.) is a very important question. The answers will always be guesses, but tracking what actually happens over time helps to improve future guesses. > - It's possible to estimate how long those tasks will take to complete. One cannot eliminate all uncertainty, but it is possible to decrease it over time. A way to do this that I found works well is to look for past tasks that are sufficiently similar in size and complexity to the one being estimated and use the tracked data to anchor the new guess. You track as you go in order to build this log. I should emphasize that I think this data should be there to help developers improve their estimating abilities, and not for the management to judge developer performance. > Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else. Very true. However, never measuring or logging anything out of a desire to avoid the things you've enumerated can deprive a team of valuable information and lead to missed learning opportunities. The trick is to find the right balance.