5 ms·

But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and

But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and worse performers? I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.

kyuudou 7y ago
Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
jiggawatts 7y ago
Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.
- freshhawk 7y ago
  This is a good breakdown of this really common dynamic. It is recognizable to many people, some of whom use it for their benefit, which can be very effective. When I learned that last fact a lot of things made more sense.
- parasubvert 7y ago
  Part of the reason that DevOps culture became a professional movement was to treat both as an end-to-end problem. Which stops misunderstandings like throwing the code to “Ops” and expecting the VMware admin to understand how an app behaves. User response time is a fairly simple metric to measure if you’re a developer. They should expose that, and other metrics, that the customer values. This is one of the reason I’ve enjoyed some “true” agile teams with a strong product owner: they encourage an end-to-end focus on outcomes.
  - stainforth 7y ago
    I feel like Jonathan Blow's jai language looks to do things like this as part of the language, at least to the developer.
- nine_k 7y ago
  This makes important points. But time and money are the things by which companies live and die. Not keeping tabs on them is suicidal. OTOH measuring time and money consumption of some technical internal steps is just uninformative.
- brians 7y ago
  As a manager, I want to measure leading indicators of success and failure. Absolutely, feedback control based on the real output is important. I must measure that! But I’m always looking for ways to predict that, so I can steer more gently. What’s a leading indicator of a crisis? A late team struggling to make a deadline. What’s a leading indicator of that? Mismatch between estimates and performance. I need to know about bad point estimates because if I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team into something dangerous.
closeparen 7y ago
By assigning problems to specific responsible individuals, and noticing the existence / quality of the solutions they produce? If anything, Agile obscures individual performance, in that it treats everyone as fungible and every part of the system a commons.

kyuudou 7y ago

Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.

jiggawatts 7y ago

Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.

freshhawk 7y ago
This is a good breakdown of this really common dynamic. It is recognizable to many people, some of whom use it for their benefit, which can be very effective. When I learned that last fact a lot of things made more sense.
parasubvert 7y ago
Part of the reason that DevOps culture became a professional movement was to treat both as an end-to-end problem. Which stops misunderstandings like throwing the code to “Ops” and expecting the VMware admin to understand how an app behaves. User response time is a fairly simple metric to measure if you’re a developer. They should expose that, and other metrics, that the customer values. This is one of the reason I’ve enjoyed some “true” agile teams with a strong product owner: they encourage an end-to-end focus on outcomes.
- stainforth 7y ago
  I feel like Jonathan Blow's jai language looks to do things like this as part of the language, at least to the developer.
nine_k 7y ago
This makes important points. But time and money are the things by which companies live and die. Not keeping tabs on them is suicidal. OTOH measuring time and money consumption of some technical internal steps is just uninformative.
brians 7y ago
As a manager, I want to measure leading indicators of success and failure. Absolutely, feedback control based on the real output is important. I must measure that! But I’m always looking for ways to predict that, so I can steer more gently. What’s a leading indicator of a crisis? A late team struggling to make a deadline. What’s a leading indicator of that? Mismatch between estimates and performance. I need to know about bad point estimates because if I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team into something dangerous.

closeparen 7y ago

By assigning problems to specific responsible individuals, and noticing the existence / quality of the solutions they produce? If anything, Agile obscures individual performance, in that it treats everyone as fungible and every part of the system a commons.