Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. These clients often couldn't really specify in enough detail what they needed from the software that was to be built. In that scenario, the structures of Agile make a lot more sense. These days, when a company decides to start using some form of Agile methodology (usually scrum) they need to do something with the people who were previously managing the team and so they often assign them the Product Owner role or something similar.

Obviously, the power balance between such a manager (who often retains power over raises and promotions as well) and a line employee team member is completely different than the power balance between a Product Owner as representative of a company and a team of consultants who together own their own consultancy business. Doubly so if the consultants have many more clients and don't exclusively depend on this one Product Owner to pay their bills.

> Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients.

This is a huge point that people who weren't in the industry back then completely miss: The people behind the Agile manifesto weren't trying to figure out how to improve software development as a whole...they were looking for ways to improve their consulting business. What works for them as consultants selling consulting services doesn't make any sense for a company dev team trying to develop software.

Also, virtually all of them had primarily worked in enterprise software. What works for consultants on internally developed software, with a captive user base and key stakeholders who write all the checks, is not necessarily what's going to work on customer-facing products, embedded, etc.

> In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process".

Except those are roles and processes, not people.

Putting people before processes and tools means treating people like adults and letting them work how they’re more comfortable.

"The team" is not a living entity that can manage things. The team self managing means the most dominant person becomes dictator, until there is revolution or power struggle with another wanna be dominant. And occasionally mixed with "no one want to dominate" leading to incoherent direction.