4 ms·

Depends how you measure "reaching", i.e. all refactorings and optimisations all reach the customer technically "reach" the customer as soon as they're deployed

Depends how you measure "reaching", i.e. all refactorings and optimisations all reach the customer technically "reach" the customer as soon as they're deployed (essentially, anything that meets its definition-of-done is "delivered). I think the wider idea is to measure work being interrupted and abandoned, or being abandoned due to not being necessary, both of which could be dubbed signs of inefficiency.

marcosdumay 4y ago
Hum, no. I'm talking exactly about abandoned work. If you don't abandon work, you either don't take any risky task, or you create a really shitty environment and will lose effectiveness soon because of it anyway. And yes, for some software you don't actually need to take any risky task. At least for a while. But if you are in a position to set that policy, you are very likely not in a position to have a clear enough view to know if your software is such one.
- yodon 4y ago
  In practice I generally see the abandoned work fraction dominated by much less interesting and much less valuable poor planning decisions, false starts, and misalignment between teams. Genuine high-value risk taking is typically already so rare in most organizations that it doesn't even show up significantly in a count like this. Equally importantly, when those genuine risk taking activities are terminated they typically happen in the form of an experiment that reached a customer at some level as part of the decision to terminate the effort. If it reached a customer in some manner like that it's not in the bucket of tasks started that never reached a customer.
- jrockway 4y ago
  This is worth a read: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 Specifically, look at the "PM can't make up their mind" graphs (https://apenwarr.ca/log/20171213#slide13 https://apenwarr.ca/log/20171213#slide13). That's the state that you're trying to avoid. I think it's fine to have tasks like "investigate the feasibility of X" and finding it infeasible. To me, that outcome is similar to delivering a feature (your customers will pay less for that than an actual feature, though, probably). What you want to avoid is "do X at any cost", and then the first steps are "integrate with third party service Y" "get a support contract for service Y" "do a giant refactoring to better use service Y", and then finding that X is actually infeasible. Now you have complexity, cost, and wasted months without having anything to give to the user. (Conflict of interest note: go ahead and do that. More work that never ships = more developers needed = higher pay for developers!)

marcosdumay 4y ago

Hum, no. I'm talking exactly about abandoned work. If you don't abandon work, you either don't take any risky task, or you create a really shitty environment and will lose effectiveness soon because of it anyway. And yes, for some software you don't actually need to take any risky task. At least for a while. But if you are in a position to set that policy, you are very likely not in a position to have a clear enough view to know if your software is such one.

yodon 4y ago
In practice I generally see the abandoned work fraction dominated by much less interesting and much less valuable poor planning decisions, false starts, and misalignment between teams. Genuine high-value risk taking is typically already so rare in most organizations that it doesn't even show up significantly in a count like this. Equally importantly, when those genuine risk taking activities are terminated they typically happen in the form of an experiment that reached a customer at some level as part of the decision to terminate the effort. If it reached a customer in some manner like that it's not in the bucket of tasks started that never reached a customer.
jrockway 4y ago
This is worth a read: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 Specifically, look at the "PM can't make up their mind" graphs (https://apenwarr.ca/log/20171213#slide13 https://apenwarr.ca/log/20171213#slide13). That's the state that you're trying to avoid. I think it's fine to have tasks like "investigate the feasibility of X" and finding it infeasible. To me, that outcome is similar to delivering a feature (your customers will pay less for that than an actual feature, though, probably). What you want to avoid is "do X at any cost", and then the first steps are "integrate with third party service Y" "get a support contract for service Y" "do a giant refactoring to better use service Y", and then finding that X is actually infeasible. Now you have complexity, cost, and wasted months without having anything to give to the user. (Conflict of interest note: go ahead and do that. More work that never ships = more developers needed = higher pay for developers!)