4 ms·

This comment is so incredibly useless that it’s hard to follow up, but I’ll try. Since you seem to know how to effectively manage an engineering team -- or, at

This comment is so incredibly useless that it’s hard to follow up, but I’ll try. Since you seem to know how to effectively manage an engineering team -- or, at the very least, know how it looks like -- please enlighten us: how would you measure productivity/ROI/whatever useful metric?

ang_cire 2y ago
Not them, but I agree with their point that management is, by definition, where the buck stops when it comes to projects, yet are never held accountable when projects go over budget or behind schedule, and that is instead put on developers. I think that productivity has to be defined by deliverables achieved on-time. If one developer is consistently failing to achieve the time boxes that their peers collectively set, that is a red flag for their productivity. If any meaningful *percentage* of your developers aren't hitting their KPIs, that's a management failure. This distinction is important, because you can't accurately measure productivity if you don't accurately set goals. Unfortunately, this assignment of responsibility rarely actually works out properly, and developers get used as scapegoats by bad managers who are in fact themselves unproductive in their NoSP (number of successful projects) metrics, and who go from job to job and group to group blaming bad developer productivity for project failures. There is a reason we hear about developer productivity and not manager productivity, in an industry where most projects fail to meet project goals (which are a management responsibility to ensure, not a developer responsibility).
- senorrib 2y ago
  Time boxes in software development are a delusion. There's a reason why the entire industry shifted focus from outputs to outcomes when it comes to software engineering.
  - ang_cire 2y ago
    It should be outcome-based at every level, not just engineering. Time boxing as a group (e.g. scrum poker) is useful for preventing a leader from underestimating time required for a task, which is a necessary safeguard on most teams when the engineer will be penalized if they don't meet a deadline, rather than a leader being penalized for setting too short of a deadline - even if this is the n-hundredth missed deadline by a report of theirs.
kmike84 2y ago
I think he/she is reacting mostly to this quote from the article, not to the main article topic: > I have a good answer: my job is to double our value-add capacity over the next three years. Essentially, to double our output without increasing spending. > You know what? With my XP plans and the XP coaches I’ve hired, it’s totally doable. I think I’m being kind of conservative, actually. TBH, this part felt off to me as well.

ang_cire 2y ago

Not them, but I agree with their point that management is, by definition, where the buck stops when it comes to projects, yet are never held accountable when projects go over budget or behind schedule, and that is instead put on developers. I think that productivity has to be defined by deliverables achieved on-time. If one developer is consistently failing to achieve the time boxes that their peers collectively set, that is a red flag for their productivity. If any meaningful *percentage* of your developers aren't hitting their KPIs, that's a management failure. This distinction is important, because you can't accurately measure productivity if you don't accurately set goals. Unfortunately, this assignment of responsibility rarely actually works out properly, and developers get used as scapegoats by bad managers who are in fact themselves unproductive in their NoSP (number of successful projects) metrics, and who go from job to job and group to group blaming bad developer productivity for project failures. There is a reason we hear about developer productivity and not manager productivity, in an industry where most projects fail to meet project goals (which are a management responsibility to ensure, not a developer responsibility).

senorrib 2y ago
Time boxes in software development are a delusion. There's a reason why the entire industry shifted focus from outputs to outcomes when it comes to software engineering.
- ang_cire 2y ago
  It should be outcome-based at every level, not just engineering. Time boxing as a group (e.g. scrum poker) is useful for preventing a leader from underestimating time required for a task, which is a necessary safeguard on most teams when the engineer will be penalized if they don't meet a deadline, rather than a leader being penalized for setting too short of a deadline - even if this is the n-hundredth missed deadline by a report of theirs.

kmike84 2y ago

I think he/she is reacting mostly to this quote from the article, not to the main article topic: > I have a good answer: my job is to double our value-add capacity over the next three years. Essentially, to double our output without increasing spending. > You know what? With my XP plans and the XP coaches I’ve hired, it’s totally doable. I think I’m being kind of conservative, actually. TBH, this part felt off to me as well.