Eh, not really scrum/agile. These are IMO bad ways to build software, especially when taken to the dictionary-definition extreme of the process, but they're not

Eh, not really scrum/agile. These are IMO bad ways to build software, especially when taken to the dictionary-definition extreme of the process, but they're not what I'm talking about. I'm more-so referencing e.g. Amazonian Data-Driven Decision Making. That the nature of this kind of process puts taste behind data, even erroneous interpretations of data or incomplete data, data is data and data is king; organizations quickly lose any sense of taste they may have had as decision making is predominated by data analysis. This process looks down on someone finding data to support a conclusion they want to reach, but in reality this is the only way to build great software: Starting with good taste, and supporting that taste with data, metrics, and experimentation. Cherry-picking is fantastic; instead we larp scientists. To a similar degree, I'm also referencing over-specialization in enterprise companies. The classic Office Space bit: "We don't let the engineers talk to customers". Computers give us an effectively-infinite second-brain and effectively-infinite automation capability, if used correctly. This idea that we need a multi-disciplinary team of a dozen people to build anything, each person holding one small piece of the puzzle like a precious gem, is antiquated; it predictably leads to the vast, vast majority of all billable person-hours being spent on self-inflicted problems and context transfer. At minimum, many extremely successful companies organize themselves around multi-disciplinary individuals & vertical teams, instead of specialized individuals and horizontal teams; this is great. But, as we live through the birth of AI rather quickly gaining many of the capabilities of these specialized individuals, I think we'll inevitably see the most profitable and productive companies and teams get smaller and smaller.