5 ms·

I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is

by crocal 9y ago

I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is not the goal nor the means in itself, though. In my view, entropic organization and management make this mistake constantly of confusing the metric with the job, like driving a car looking at the speed meter and not at the road (sounds absurd, I know, but is really what happens).

marcosdumay 9y ago
I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure. Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.
yoyar 9y ago
For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.
- imiric 9y ago
  Right. I wish more managers/coaches/masters understood this. Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down. Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term. Anyway, that's my pessimistic, armchair interpretation of it.
- GordonS 9y ago
  I seem to recall a quote about "works expands to full available time". I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.
troels 9y ago
Agree. Dates are good for limiting scope. Without that constraint, it is usually very hard to set boundaries as to what should and what shouldn't go into a project. There is also validity to the notion that time is money. Eventually, we'll all be lying in our graves. But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.

by crocal 9y ago

marcosdumay 9y ago

I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure. Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.

yoyar 9y ago

For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.

imiric 9y ago
Right. I wish more managers/coaches/masters understood this. Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down. Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term. Anyway, that's my pessimistic, armchair interpretation of it.
GordonS 9y ago
I seem to recall a quote about "works expands to full available time". I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.

troels 9y ago

Agree. Dates are good for limiting scope. Without that constraint, it is usually very hard to set boundaries as to what should and what shouldn't go into a project. There is also validity to the notion that time is money. Eventually, we'll all be lying in our graves. But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.