6 ms·

Estimates are easy to produce, but management wants commitment. For example, if I estimated a task to be 2w and management confirmed that, then after two weeks

by lisivka 10y ago

Estimates are easy to produce, but management wants commitment. For example, if I estimated a task to be 2w and management confirmed that, then after two weeks management will start to be angry at me if I will report that task will need 3x time to finish. 3x error is not uncommon for estimates. If I will avoid estimates, then manager will talk something like "try this task for 3 days and if it will require more than 3w to finish, then skip it, because we will not meet the deadline", which is better way to communicate.

jon-wood 10y ago
Your second option of trying something for a while and then saying if it will take more than 3 weeks to finish is still estimating. I don't disagree that it'll result in a far more reliable estimate as you've had time to really feel out the problem and get an idea of what's really involved, but at the end of it you're still giving an estimate of less than three weeks. I think many people's aversion to estimates comes from a culture like the one you're describing in your first option, one where developers are asked for estimates but they're taken as hard commitments. The solution to that sort of culture is exactly the opposite of the one being proposed in this manifesto - instead of siloing ourselves away further and avoiding contact, we should communicate more. (Good) managers don't get angry at a 2 week task taking 6 weeks, they get angry at finding out that the 2 week task will take 6 weeks only after we hit the point at which they were expecting everything to be done. With a little intuition we can tell that a task is going to miss its deadline long before that deadline hits - presumably we've broken things down into smaller sub-tasks, if we haven't completed 25% of those when you're about 25% of the way in, we're going to miss our deadline. The typical developer has a tendency to convince themselves they'll catch up later on, I certainly do, but in all likelihood we won't. That 25% point is the time to sit down with the manager and talk things over. Bring options, make it clear that if the deadline matters that much some features might have to be dropped, or released later. Or maybe the deadline doesn't matter, but they'll need to rearrange things so that another person is working on a feature which has a deadline 6 weeks out. I get how appealing the proposal to just do away with deadlines, meetings, and regular updates can be, but that's only practical in an organisation entirely staffed by developers without any outside influences. Those influences will include all sorts of things, from investors to the season (woe betide the retailer who didn't bother estimating how long functionality to handle Christmas orders was going to take and released it on the 26th of December because that's when it was done). In the real world you're not building features in isolation so we need a way to communicate to others what they should expect, and when they should expect it.
MaulingMonkey 10y ago
I'm totally on board with time estimates, totally not on board with several potential 'weaponizations' of those estimates. There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable. There's a similarly fine line between a manager trying to gauge the scope of tasks and help identify unnecessary dead weight that can be cut or delayed, and a manager trying to simply negotiate the estimate down, without cutting anything. The former is reasonable and at times valuable, the latter is either trying to bend the truth to keep their stakeholders 'happy' or pressure games to entice crunch - completely unreasonable - or outright denial (frankly, a failure to do their job right.) Unfortunately, I think the unreasonable folk ruin it for the reasonable folk, to some degree. Even with managers in the former camp, and with devs I'm convinced recognize their managers as being in the former camp, simply trying to even go through the motions of estimating seem to add a lot of stress and heartache. Good signs: They point out stuff that's vague, try and actually try to eliminate some of the blind guesswork, helping to produce reasonable estimates, and try to compensate for your bad estimates while guiding you towards making better ones. Bad signs: They complain about work taking too long, or adjust your estimates down behind your back.
- pdimitar 10y ago
  > There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable. Thank you, thank you, THANK YOU! Why isn't this taught in the MBA courses? Why isn't this common sense? As for the rest of your comment, my personal observations have followed Occam's Razor effect -- it's not that people are in denial or are blind or they can't serve the business well per se; they're simply vengeful immature people put in positions of power. They want to RULE and they hate the idea that their subordinates can dictate the pace and the format of the work, and they want "to get back at the nerds" <-- and this is actual overheard conversation between two managers in one of my former jobs. Being a manager requires a lot of emotional intelligence. Most of them don't have it and never will. That's one of the core problems with who to put in a position of power. Apologies for going on a tangent and generalizing a bit. But these views of mine are intertwined with the OP (and your comment of it).

by lisivka 10y ago

jon-wood 10y ago

Your second option of trying something for a while and then saying if it will take more than 3 weeks to finish is still estimating. I don't disagree that it'll result in a far more reliable estimate as you've had time to really feel out the problem and get an idea of what's really involved, but at the end of it you're still giving an estimate of less than three weeks. I think many people's aversion to estimates comes from a culture like the one you're describing in your first option, one where developers are asked for estimates but they're taken as hard commitments. The solution to that sort of culture is exactly the opposite of the one being proposed in this manifesto - instead of siloing ourselves away further and avoiding contact, we should communicate more. (Good) managers don't get angry at a 2 week task taking 6 weeks, they get angry at finding out that the 2 week task will take 6 weeks only after we hit the point at which they were expecting everything to be done. With a little intuition we can tell that a task is going to miss its deadline long before that deadline hits - presumably we've broken things down into smaller sub-tasks, if we haven't completed 25% of those when you're about 25% of the way in, we're going to miss our deadline. The typical developer has a tendency to convince themselves they'll catch up later on, I certainly do, but in all likelihood we won't. That 25% point is the time to sit down with the manager and talk things over. Bring options, make it clear that if the deadline matters that much some features might have to be dropped, or released later. Or maybe the deadline doesn't matter, but they'll need to rearrange things so that another person is working on a feature which has a deadline 6 weeks out. I get how appealing the proposal to just do away with deadlines, meetings, and regular updates can be, but that's only practical in an organisation entirely staffed by developers without any outside influences. Those influences will include all sorts of things, from investors to the season (woe betide the retailer who didn't bother estimating how long functionality to handle Christmas orders was going to take and released it on the 26th of December because that's when it was done). In the real world you're not building features in isolation so we need a way to communicate to others what they should expect, and when they should expect it.

MaulingMonkey 10y ago

I'm totally on board with time estimates, totally not on board with several potential 'weaponizations' of those estimates. There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable. There's a similarly fine line between a manager trying to gauge the scope of tasks and help identify unnecessary dead weight that can be cut or delayed, and a manager trying to simply negotiate the estimate down, without cutting anything. The former is reasonable and at times valuable, the latter is either trying to bend the truth to keep their stakeholders 'happy' or pressure games to entice crunch - completely unreasonable - or outright denial (frankly, a failure to do their job right.) Unfortunately, I think the unreasonable folk ruin it for the reasonable folk, to some degree. Even with managers in the former camp, and with devs I'm convinced recognize their managers as being in the former camp, simply trying to even go through the motions of estimating seem to add a lot of stress and heartache. Good signs: They point out stuff that's vague, try and actually try to eliminate some of the blind guesswork, helping to produce reasonable estimates, and try to compensate for your bad estimates while guiding you towards making better ones. Bad signs: They complain about work taking too long, or adjust your estimates down behind your back.

pdimitar 10y ago
> There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable. Thank you, thank you, THANK YOU! Why isn't this taught in the MBA courses? Why isn't this common sense? As for the rest of your comment, my personal observations have followed Occam's Razor effect -- it's not that people are in denial or are blind or they can't serve the business well per se; they're simply vengeful immature people put in positions of power. They want to RULE and they hate the idea that their subordinates can dictate the pace and the format of the work, and they want "to get back at the nerds" <-- and this is actual overheard conversation between two managers in one of my former jobs. Being a manager requires a lot of emotional intelligence. Most of them don't have it and never will. That's one of the core problems with who to put in a position of power. Apologies for going on a tangent and generalizing a bit. But these views of mine are intertwined with the OP (and your comment of it).