4 ms·

It seems like the measurements used by teams shouldn't be available to management because they will inevitably abuse that information.

pjmorris 7y ago
Your observation is right on target, and it has been predicted and validated [0]. The people who originally developed agile understood this, but it's one of the kinds of things that doesn't really sink in in many cases. [0] 'Measuring and Managing Performance in Organizations', Robert Austin, Dorset House, 1996.
SkyBelow 7y ago
But who ensures it isn't? Management who are the ones inherently attracted to having the metric to use? The ones who are able to withstand that pressure and not touch the information are likely the ones would could see the information without using it as a stick. I guess upper management could enforce the separation on a level lower management could not override, but I would assume such cases are rare.
- apotheon 7y ago
  The solution is to stop blaming the methodology for the failures of management, and just accept that bureaucracy breeds mediocrity. Corporations grow into bureaucracy, inevitably. Choose accordingly when evaluating potential employers. Keep this in mind when running a business.
cjblomqvist 7y ago
I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives). Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
- jamestimmins 7y ago
  Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity. I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
  - ratww 7y ago
    I think it has a lot to do with bargain power. By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker. By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
  - shantly 7y ago
    I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both. It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
    - ryandrake 7y ago
      As a project manager, I hate taking a bug tracker and trying to beat it into being a project management/communication/measurement tool. The only reason I always end up doing so is that bug trackers are already in the engineers’ daily workflow so they are usually the source of truth about the project. I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
hrktb 7y ago
I am not sure it would even save the situation. Most agile methodologies assume a lot of constants to allow measurements to have any sense at all (for instance scrum assumes teams members are stable, of that knowledge over their work perimeter is good, etc.) We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.
- apotheon 7y ago
  Scrum always looked to me like pseudo-waterfall with an Agile™ coat of paint.
LanceH 7y ago
The failing after every step has been when they close the loop. That is, agile is used to score and measure velocity. This velocity is then used to impact future scoring. This nullifies Agile's use for measurement since management is now insisting that x number of points be completed per developer per sprint. The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out. Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked. So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.
- apotheon 7y ago
  That assumes really good (measured against the norm) management. If your management is "normal" (or worse), giving management access to that just destroys the whole value of the scoring system. (Always remember that fifty percent is worse than the centerline, to say nothing of the still-within-a-standard-deviation "better" that isn't enough better to matter.)
  - LanceH 7y ago
    It really sounds like a "not true Scotsman" argument, but I've had Agile fail when the team failed to use Agile. As I wrote above, points inevitably became a proxy for time in one manner or another. Production was pinned to a certain number of points (say 15 per developer per sprint). I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop. Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).

pjmorris 7y ago

Your observation is right on target, and it has been predicted and validated [0]. The people who originally developed agile understood this, but it's one of the kinds of things that doesn't really sink in in many cases. [0] 'Measuring and Managing Performance in Organizations', Robert Austin, Dorset House, 1996.

SkyBelow 7y ago

But who ensures it isn't? Management who are the ones inherently attracted to having the metric to use? The ones who are able to withstand that pressure and not touch the information are likely the ones would could see the information without using it as a stick. I guess upper management could enforce the separation on a level lower management could not override, but I would assume such cases are rare.

apotheon 7y ago
The solution is to stop blaming the methodology for the failures of management, and just accept that bureaucracy breeds mediocrity. Corporations grow into bureaucracy, inevitably. Choose accordingly when evaluating potential employers. Keep this in mind when running a business.

cjblomqvist 7y ago

I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives). Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.

jamestimmins 7y ago
Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity. I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
- ratww 7y ago
  I think it has a lot to do with bargain power. By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker. By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
- shantly 7y ago
  I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both. It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
  - ryandrake 7y ago
    As a project manager, I hate taking a bug tracker and trying to beat it into being a project management/communication/measurement tool. The only reason I always end up doing so is that bug trackers are already in the engineers’ daily workflow so they are usually the source of truth about the project. I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.

hrktb 7y ago

I am not sure it would even save the situation. Most agile methodologies assume a lot of constants to allow measurements to have any sense at all (for instance scrum assumes teams members are stable, of that knowledge over their work perimeter is good, etc.) We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.

apotheon 7y ago
Scrum always looked to me like pseudo-waterfall with an Agile™ coat of paint.

LanceH 7y ago

The failing after every step has been when they close the loop. That is, agile is used to score and measure velocity. This velocity is then used to impact future scoring. This nullifies Agile's use for measurement since management is now insisting that x number of points be completed per developer per sprint. The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out. Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked. So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.

apotheon 7y ago
That assumes really good (measured against the norm) management. If your management is "normal" (or worse), giving management access to that just destroys the whole value of the scoring system. (Always remember that fifty percent is worse than the centerline, to say nothing of the still-within-a-standard-deviation "better" that isn't enough better to matter.)
- LanceH 7y ago
  It really sounds like a "not true Scotsman" argument, but I've had Agile fail when the team failed to use Agile. As I wrote above, points inevitably became a proxy for time in one manner or another. Production was pinned to a certain number of points (say 15 per developer per sprint). I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop. Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).