| IMO the problem with most of these approaches is that it's incredibly hard to measure certain important things, and making decisions purely based on what you can measure is risky if you're not aware of what you're leaving out of those decisions. Consider the team that spends 2 months implementing a feature twice or more because one product person specs out one thing, their VP boss sees it a month later and says "no, redo it this other way," and then a month after that another VP sees the result and says "no, you have to go back to the first version!" But maybe they hit their sprint velocity targets every sprint along the way. Consider the team working on the "elegant," "clever" codebase that solved yesterday's problem extremely neatly but wasn't extensible at all to the new feature, requiring a ton of effort to work around the old assumptions in the code. This team could similarly be "crushing it" according to their story points and burndown." Consider the team with high SLAs and a lot of old domain knowledge that now gets a critical new project while still having 70% of their time sucked up by being the experts on the old system, and never given priority to operationalize/automate some of that old work. How often do you get those wasted hours measured in a way that convinces someone to give the team the help they need? This isn't just a non-technical thing. I've seen (and been guilty of) devs lobby for rewrites of messy legacy systems, only to end up months later with a system no more extensible than the one before, without any improvement in the ability to delivery business results rapidly. I think it comes down the company environment in the end - if you are in a place where you get good results from trusting each other, you can find beneficial trade-offs and good-faith "here's how refactoring this is gonna help you out later, product person; and in exchange for prioritizing it we'll squeeze in this extra high-priority short-term thing too" dealings. But if not, it's a prisoner's dilemma sort of situation. |